.NET socket potřebuje SOCKS handshake
Vysvětlete, co musí surový .NET TCP socket udělat, než bajty aplikace mohou projít přes SOCKS proxy.
Nasměrování Socket.Connect() na server SOCKS otevře TCP spojení s tímto serverem. Následující bajty však stále musí mluvit SOCKS. Pokud okamžitě odešlete protokol své aplikace, server bude čekat na jinou konverzaci.
U SOCKS5 zahrnuje navázání spojení vyjednání metody, případnou zvolenou výměnu autentizace a požadavek pojmenovávající cíl. Cestu pro bajty aplikace otevře pouze úspěšná odpověď. Tyto fáze jsou definovány v RFC 1928.
Ponechte vyjednávání ve vrstvě spojení
Aplikace s vlastním protokolem TCP může použít konektor, který rozumí proxy a vrací navázaný proud. Zbytek aplikace pak čte a zapisuje skrze tento proud. Konektor musí počítat s částečnými čteními, adresami proměnlivé délky, selháními autentizace a termínem pro vyjednávání.
Ručně psaná implementace, která přečte jednu vyrovnávací paměť pevné velikosti a předpokládá úspěch, je křehká. TCP nezachovává hranice zpráv SOCKS. Před zahájením protokolu aplikace přečtěte úplnou odpověď popsanou jejím typem adresy. čtečka odpovědí CONNECT v .NET 7+ tento krok ilustruje.
Pokud udržovaná knihovna už tuto vrstvu spojení poskytuje, zkontrolujte její podporované verze SOCKS, metody autentizace a cílový framework. Deset let starý odkaz na fórum je výchozím bodem pro vyšetřování, nikoli důkazem současné kompatibility.
Konfigurace HTTP klienta má samostatný rozsah
Nastavení proxy HTTP klienta konfiguruje tohoto HTTP klienta. Nemění každý surový socket v procesu. API Socket přijímá síťový koncový bod a ponechává vyjednávání vyšší úrovně volajícímu.
U šifrovaného protokolu aplikace proveďte TLS handshake poté, co je tunel proxy navázán. V této fázi ověřte zamýšlenou identitu cíle. Autentizace proxy a autentizace cíle zůstávají oddělené, i když používají stejný podkladový proud.