גשר לקוחות SOCKS אל הורה HTTP CONNECT עם 3proxy

היישום דורש SOCKS. שירות ה-upstream המאושר שלך מקבל HTTP CONNECT. הצבת נקודת הקצה של HTTP בשדה ה-SOCKS של היישום אינה מתרגמת בין הפרוטוקולים.

שער יכול לקבל SOCKS מהיישום, לקרוא את היעד המבוקש ולבקש מהורה ה-HTTP מנהרת CONNECT ליעד הזה. לאחר מכן הוא מעביר את הזרם של היישום דרך המנהרה.

SOCKS application → SOCKS-facing gateway → HTTP CONNECT parent → destination

הפוך כל ממשק למפורש

עבור שער שתומך בסידור הזה, סוג ההורה חשוב. התיעוד של 3proxy מבחין בין הורה connect לבין הורה שמשמש כפרוקסי העברה HTTP רגיל.

עם משתמש 3proxy ואימות קיימים, מקטע ניתוב מקומי בלבד יכול להיראות כך:

auth strong
allow alex
parent 1000 connect parent.example.net 8080
socks -i127.0.0.1 -p1080

המקטע מניח שהחשבון כבר מוגדר. הוא אינו מוסיף שום אישורים שהורה ה-HTTP עצמו דורש, ואינו מחליף את מדיניות הגישה הקיימת. עבור יעדים ציבוריים בנתיב שמתיר הורה HTTP ציבורי ללא אימות, רשימת פרוקסי ה-HTTP מציעה מועמדים של מארח ופורט. השאר את אישורי ההורה חסרים בענף הזה ואשר הרשאה ליעד בפועל; החשבון של השער עצמו נשאר מקומי. כלל parent משויך לכלל ה-allow הקודם לפי מודל התצורה המתועד של 3proxy.

היישום משתמש בנקודת הקצה המקומית של SOCKS. השער משתמש ב-HTTP CONNECT כלפי ההורה. ההורה עדיין מחליט אם המארח והפורט המבוקשים של היעד מותרים.

ההיקף השימושי כאן הוא מנהרת זרם TCP רגילה. שיוך UDP של SOCKS5 אינו נתמך רק מפני שהמאזין הקדמי מקבל SOCKS5. הורה HTTP CONNECT אינו מספק אוטומטית את ממסר ה-UDP הנדרש.

HTTPS יכול להישאר מקצה לקצה בתוך הנתיב הזה; תרגום בין ממשקי פרוקסי אינו דורש התחזות לאתר היעד. האימות לשער, האימות להורה והאימות לאתר נשארים אישורים והחלפות שונים.