En .NET-socket trenger en SOCKS-håndtrykk

Å peke Socket.Connect() mot en SOCKS-server åpner en TCP-tilkobling til den serveren. De neste bytene må fortsatt snakke SOCKS. Å sende applikasjonens protokoll umiddelbart lar serveren vente på en annen samtale.

Med SOCKS5 inkluderer tilkoblingsoppsett metodeforhandling, eventuell valgt autentiseringsutveksling og en forespørsel som navngir destinasjonen. Bare et vellykket svar åpner veien for applikasjonens bytes. Disse trinnene er definert i RFC 1928.

Hold forhandlingen i tilkoblingslaget

En applikasjon med sin egen TCP-protokoll kan bruke en proxybevisst kobling som returnerer en etablert strøm. Resten av applikasjonen leser og skriver deretter gjennom den strømmen. En kobling må ta høyde for delvise lesinger, adresser med variabel lengde, autentiseringsfeil og en frist for forhandlingen.

En håndskrevet implementering som leser én buffer med fast størrelse og antar suksess, er skjør. TCP bevarer ikke grensene mellom SOCKS-meldinger. Les det fullstendige svaret som er beskrevet av adressetypen, før du starter applikasjonsprotokollen. En .NET 7+ CONNECT-svarlser illustrerer det trinnet.

Hvis et vedlikeholdt bibliotek allerede leverer dette tilkoblingslaget, kontroller de støttede SOCKS-versjonene, autentiseringsmetodene og målrammeverket. En ti år gammel forumlenke er et utgangspunkt for undersøkelse, ikke bevis på gjeldende kompatibilitet.

HTTP-klientkonfigurasjon har et eget omfang

Proxyinnstillingen til en HTTP-klient konfigurerer den HTTP-klienten. Den endrer ikke hver rå socket i prosessen. Socket-API-et godtar et nettverksendepunkt og overlater forhandling på høyere nivå til den som kaller.

For en kryptert applikasjonsprotokoll, utfør TLS-håndtrykket etter at proxy-tunnelen er etablert. Valider den tiltenkte destinasjonsidentiteten på det stadiet. Proxyautentisering og destinasjonsautentisering forblir separate selv om de bruker den samme underliggende strømmen.