Een .NET-socket heeft een SOCKS-handshake nodig
Legt uit wat een onbewerkte .NET TCP-socket moet doen voordat applicatiebytes via een SOCKS-proxy kunnen reizen.
Socket.Connect() naar een SOCKS-server richten opent een TCP-verbinding met die server. De volgende bytes moeten nog steeds SOCKS spreken. Meteen het protocol van uw applicatie sturen laat de server wachten op een ander gesprek.
Bij SOCKS5 omvat het opzetten van de verbinding methode-onderhandeling, een eventuele gekozen authenticatie-uitwisseling en een verzoek dat de bestemming noemt. Alleen een geslaagd antwoord opent de weg voor de bytes van de applicatie. Deze fasen zijn gedefinieerd in RFC 1928.
Houd de onderhandeling in de verbindingslaag
Een applicatie met een eigen TCP-protocol kan een proxybewuste connector gebruiken die een gevestigde stream teruggeeft. De rest van de applicatie leest en schrijft vervolgens via die stream. Een connector moet rekening houden met gedeeltelijke reads, adressen van variabele lengte, authenticatiefouten en een deadline voor de onderhandeling.
Een handgeschreven implementatie die één buffer van vaste grootte leest en succes aanneemt, is kwetsbaar. TCP bewaart de grenzen van SOCKS-berichten niet. Lees het volledige antwoord zoals beschreven door het adrestype voordat u het applicatieprotocol start. Een .NET 7+ CONNECT-antwoordlezer illustreert die stap.
Als een onderhouden bibliotheek deze verbindingslaag al levert, controleer dan de ondersteunde SOCKS-versies, authenticatiemethoden en het doelframework. Een forumlink van tien jaar oud is een startpunt voor onderzoek, geen bewijs van huidige compatibiliteit.
HTTP-clientconfiguratie heeft een apart bereik
De proxyinstelling van een HTTP-client configureert die HTTP-client. Het wijzigt niet elke onbewerkte socket in het proces. De Socket-API accepteert een netwerkeindpunt en laat onderhandeling op hoger niveau aan de aanroeper.
Voor een versleuteld applicatieprotocol voert u de TLS-handshake uit nadat de proxytunnel is opgezet. Valideer in die fase de identiteit van de beoogde bestemming. Proxyauthenticatie en bestemmingsauthenticatie blijven gescheiden, ook al gebruiken ze dezelfde onderliggende stream.