En .NET-socket behöver en SOCKS-handskakning

Att rikta Socket.Connect() mot en SOCKS-server öppnar en TCP-anslutning till den servern. Nästa byte måste fortfarande tala SOCKS. Att skicka applikationens protokoll direkt lämnar servern väntande på ett annat samtal.

Med SOCKS5 omfattar anslutningsuppbyggnaden metodförhandling, eventuellt valt autentiseringsutbyte och en begäran som namnger målet. Endast ett lyckat svar öppnar vägen för applikationens byte. Dessa steg definieras i RFC 1928.

Håll förhandlingen i anslutningslagret

En applikation med ett eget TCP-protokoll kan använda en proxy-medveten anslutningskomponent som returnerar en upprättad ström. Resten av applikationen läser och skriver sedan genom den strömmen. En anslutningskomponent måste ta hänsyn till partiella läsningar, adresser med variabel längd, autentiseringsfel och en tidsgräns för förhandlingen.

En handskriven implementering som läser en buffert med fast storlek och antar framgång är ömtålig. TCP bevarar inte gränserna för SOCKS-meddelandena. Läs det fullständiga svaret som beskrivs av dess adresstyp innan applikationsprotokollet startas. En läsare av CONNECT-svar för .NET 7+ illustrerar det steget.

Om ett underhållet bibliotek redan tillhandahåller detta anslutningslager, kontrollera dess SOCKS-versioner, autentiseringsmetoder och målramverk. En forumlänk som är ett decennium gammal är en utgångspunkt för undersökning, inte bevis på aktuell kompatibilitet.

HTTP-klientens konfiguration har ett separat omfång

En proxyinställning i en HTTP-klient konfigurerar den HTTP-klienten. Den ändrar inte varje rå socket i processen. Socket-API:t tar emot en nätverksändpunkt och lämnar förhandlingen på högre nivå till anroparen.

För ett krypterat applikationsprotokoll, utför dess TLS-handskakning efter att proxy-tunneln upprättats. Validera det avsedda målets identitet i det skedet. Proxyautentisering och målautentisering förblir åtskilda även om de använder samma underliggande ström.