En .NET-socket kræver et SOCKS-håndtryk

At pege Socket.Connect() mod en SOCKS-server åbner en TCP-forbindelse til den server. De næste bytes skal stadig tale SOCKS. Hvis du sender applikationens protokol med det samme, efterlader du serveren ventende på en anden samtale.

Med SOCKS5 omfatter forbindelsesopbygningen metodeforhandling, en eventuel valgt godkendelsesudveksling og en anmodning, der navngiver destinationen. Kun et vellykket svar åbner vejen for applikationens bytes. Disse trin er defineret i RFC 1928.

Hold forhandlingen i forbindelseslaget

En applikation med sin egen TCP-protokol kan bruge et proxybevidst connector, der returnerer en etableret stream. Resten af applikationen læser og skriver derefter gennem den stream. Et connector skal tage højde for delvise læsninger, variabelt lange adresser, godkendelsesfejl og en frist for forhandlingen.

En håndskrevet implementering, der læser én buffer med fast størrelse og antager succes, er skrøbelig. TCP bevarer ikke grænserne for SOCKS-beskeder. Læs det komplette svar, som beskrives af dets adressetype, før applikationsprotokollen starter. En .NET 7+ CONNECT-svarlæser illustrerer det trin.

Hvis et vedligeholdt bibliotek allerede leverer dette forbindelseslag, så kontroller dets understøttede SOCKS-versioner, godkendelsesmetoder og målframework. Et ti år gammelt forumlink er et udgangspunkt for undersøgelse snarere end bevis for aktuel kompatibilitet.

HTTP-klientkonfiguration har sit eget omrade

En HTTP-klients proxyindstilling konfigurerer den HTTP-klient. Den ændrer ikke hver rå socket i processen. Socket-API'et accepterer et netværksendepunkt og overlader forhandlingen på højere niveau til kalderen.

For en krypteret applikationsprotokol skal du udføre dens TLS-håndtryk, efter at proxytunnelen er etableret. Validér den tilsigtede destinations identitet på det trin. Proxygodkendelse og destinationsgodkendelse forbliver adskilte, selvom de bruger den samme underliggende stream.