גשרי SOCKS של socat: שמירה על שם המארח TLS של האתר

השתמשו במאזין TCP מסוג loopback ליעד SOCKS אחד תוך שמירה על זהות HTTP ו-TLS באפליקציה.

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

עבור בניות socat המספקות SOCKS4A, סידור להמחשה הוא:

socat TCP4-LISTEN:9443,bind=127.0.0.1,reuseaddr,fork \
  SOCKS4A:127.0.0.1:service.example.net:443,socksport=1080

נקודת הקצה של SOCKS היא פורט מקומי 1080. המתאם מאזין בפורט מקומי 9443 ומבקש מנקודת הקצה הזו service.example.net:443. אלה ערכי דוגמה, לא פריסה מלאה של שירות.

למתאם יעד קבוע אחד

כל חיבור TCP שמתקבל מבקש את אותו שירות. אפליקציה המתחברת ל-9443 מספקת את בייטי הפרוטוקול הרגילים שלה; socat מספק את משא ומתן SOCKS4A. שליחת בקשת HTTP CONNECT חדשה ל-9443 לא תבחר יעד אחר—היא תשלח את הבייטים האלה אל השירות הקבוע.

SOCKS4A מספק שם מארח לנקודת הקצה של SOCKS לצורך פתרון מרחוק. זה שונה מצורת SOCKS4 המשתמשת בכתובת שנבחרה על ידי הלקוח. ה-upstream הנבחר—כולל מועמד ציבורי מרשימת פרוקסי SOCKS4—חייב לתמוך בטיפול בשמות מארח של SOCKS4A ובאימות הנדרש; דוגמה זו אינה מתכון להתחברות עם סיסמה ב-SOCKS5.

התחברו locally, זהו את השירות האמיתי

שינוי כתובת HTTPS ל-https://127.0.0.1:9443/ משנה את שם המארח שהלקוח רשאי להשתמש בו עבור TLS ו-HTTP. תעודה עבור service.example.net לא תהפוך לתעודה תקפה עבור loopback.

כאשר הלקוח תומך בניתוב חיבור נפרד, שמרו על זהות הכתובת המקורית. Curl יכול להמחיש את ההבחנה הזו:

curl --noproxy '*' \
  --connect-to service.example.net:443:127.0.0.1:9443 \
  https://service.example.net/

ה-socket הולך למתאם המקומי בעוד אימות TLS ויעד ה-HTTP נשארים service.example.net. אפליקציות אחרות זקוקות לבקרה מקבילה נתמכת משלהן; לא כל לקוח מספק אחת.

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

מאמרים קשורים