Gniazdo .NET wymaga uzgadniania SOCKS
Wyjaśnia, co musi zrobić surowe gniazdo TCP .NET, zanim bajty aplikacji będą mogły podróżować przez proxy SOCKS.
Skierowanie Socket.Connect() na serwer SOCKS otwiera połączenie TCP z tym serwerem. Kolejne bajty nadal muszą mówić po SOCKS. Natychmiastowe wysłanie protokołu aplikacji pozostawia serwer czekający na inną rozmowę.
W SOCKS5 nawiązanie połączenia obejmuje negocjację metody, ewentualną wybraną wymianę uwierzytelniania oraz żądanie wskazujące cel. Tylko pomyślna odpowiedź otwiera drogę dla bajtów aplikacji. Te etapy są zdefiniowane w RFC 1928.
Utrzymaj negocjację w warstwie połączenia
Aplikacja z własnym protokołem TCP może użyć łącznika świadomego proxy, który zwraca nawiązany strumień. Reszta aplikacji czyta i pisze przez ten strumień. Łącznik musi uwzględniać częściowe odczyty, adresy o zmiennej długości, błędy uwierzytelniania i termin negocjacji.
Napisana ręcznie implementacja, która odczytuje jeden bufor o stałym rozmiarze i zakłada sukces, jest krucha. TCP nie zachowuje granic komunikatów SOCKS. Odczytaj pełną odpowiedź opisaną przez typ adresu, zanim rozpoczniesz protokół aplikacji. Czytnik odpowiedzi CONNECT w .NET 7+ ilustruje ten krok.
Jeśli utrzymywana biblioteka już dostarcza tę warstwę połączenia, sprawdź obsługiwane wersje SOCKS, metody uwierzytelniania i docelową platformę. Dziesięcioletni link do forum to punkt wyjścia do dochodzenia, a nie dowód bieżącej zgodności.
Konfiguracja klienta HTTP ma odrębny zakres
Ustawienie proxy klienta HTTP konfiguruje ten klient HTTP. Nie zmienia każdego surowego gniazda w procesie. API Socket przyjmuje punkt końcowy sieci i pozostawia negocjację wyższego poziomu wywołującemu.
W przypadku szyfrowanego protokołu aplikacji wykonaj jego uzgadnianie TLS po ustanowieniu tunelu proxy. Na tym etapie zweryfikuj zamierzoną tożsamość celu. Uwierzytelnianie proxy i uwierzytelnianie celu pozostają oddzielne, mimo że używają tego samego strumienia bazowego.