סוקט .NET זקוק ללחיצת יד של SOCKS

הפניית Socket.Connect() לשרת SOCKS פותחת חיבור TCP לאותו שרת. הבתים הבאים עדיין חייבים לדבר SOCKS. שליחת פרוטוקול היישום מיד משאירה את השרת ממתין לשיחה אחרת.

ב-SOCKS5, הקמת החיבור כוללת משא ומתן על שיטה, חילופי אימות נבחרים אם יש כאלה, ובקשה שמציינת את היעד. רק תגובה מוצלחת פותחת את הדרך לבתים של היישום. שלבים אלה מוגדרים ב-RFC 1928.

השאירו את המשא ומתן בשכבת החיבור

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

מימוש שנכתב ביד, שקורא מאגר אחד בגודל קבוע ומניח הצלחה, שביר. TCP אינו משמר את גבולות ההודעות של SOCKS. קראו את התגובה המלאה שמתוארת לפי סוג הכתובת שלה לפני שמתחילים את פרוטוקול היישום. קורא תגובות CONNECT ל-.NET 7+ ממחיש את השלב הזה.

אם ספרייה מתוחזקת כבר מספקת את שכבת החיבור הזו, בדקו את גרסאות ה-SOCKS הנתמכות שלה, את שיטות האימות ואת מסגרת היעד. קישור פורום בן עשור הוא נקודת התחלה לבדיקה ולא הוכחה לתאימות נוכחית.

לתצורת לקוח HTTP יש היקף נפרד

הגדרת הפרוקסי של לקוח HTTP מגדירה את אותו לקוח HTTP. היא אינה משנה כל סוקט גולמי בתהליך. ה-API של Socket מקבל נקודת קצה ברשת ומשאיר את המשא ומתן ברמה גבוהה יותר לקורא.

עבור פרוטוקול יישום מוצפן, בצעו את לחיצת היד של TLS לאחר הקמת מנהרת הפרוקסי. אמתו את זהות היעד המיועד בשלב זה. אימות הפרוקסי ואימות היעד נשארים נפרדים למרות שהם משתמשים באותו זרם בסיסי.