Egy .NET socketnek SOCKS kézfogás kell

A Socket.Connect() SOCKS-kiszolgálóra irányítása TCP-kapcsolatot nyit ahhoz a kiszolgálóhoz. A következő bájtoknak mégis SOCKS-t kell beszélniük. Ha azonnal az alkalmazás protokollját küldjük, a kiszolgáló egy másik beszélgetésre vár.

SOCKS5 esetén a kapcsolat létrehozása magában foglalja a metódus egyeztetését, egy esetleg kiválasztott hitelesítési cserét és a célt megnevező kérést. Csak egy sikeres válasz nyitja meg az utat az alkalmazás bájtjai előtt. Ezeket a lépéseket az RFC 1928 határozza meg.

Tartsa az egyeztetést a kapcsolati rétegben

Egy saját TCP-protokollal rendelkező alkalmazás használhat proxy-tudatos csatlakozót, amely létrehozott adatfolyamot ad vissza. Az alkalmazás többi része ezután ezen a folyamon keresztül olvas és ír. A csatlakozónak számolnia kell a részleges olvasásokkal, a változó hosszúságú címekkel, a hitelesítési hibákkal és az egyeztetés határidejével.

Egy kézzel írt megvalósítás, amely egyetlen rögzített méretű puffert olvas és sikert feltételez, törékeny. A TCP nem őrzi meg a SOCKS-üzenetek határait. Olvassa el a címzett típusa által leírt teljes választ, mielőtt elkezdi az alkalmazás protokollját. A .NET 7+ CONNECT-válaszolvasó szemlélteti ezt a lépést.

Ha egy karbantartott könyvtár már biztosítja ezt a kapcsolati réteget, ellenőrizze a támogatott SOCKS-verzióit, a hitelesítési módszereit és a célkeretrendszerét. Egy tízéves fórumhivatkozás a vizsgálat kiindulópontja, nem pedig a jelenlegi kompatibilitás bizonyítéka.

A HTTP-kliens konfigurációjának külön hatóköre van

Egy HTTP-kliens proxybeállítása azt a HTTP-klienst konfigurálja. Nem módosítja a folyamat minden nyers socketjét. A Socket API hálózati végpontot fogad el, és a magasabb szintű egyeztetést a hívóra hagyja.

Titkosított alkalmazásprotokoll esetén a proxy-alagút létrehozása után végezze el annak TLS-kézfogását. Ebben a szakaszban ellenőrizze a szándékolt cél identitását. A proxy hitelesítése és a cél hitelesítése külön marad, bár ugyanazt a mögöttes folyamot használják.