SOCKS5 puhverserver OpenVPN-ile: TCP tunnel või rakenduste puhverdamine?

Võrgud, mis lubavad väljuvat liiklust ainult puhverserveri kaudu, on kohad, kus töötav profiil äkki sureb. Puhverserveri aadress on selles tõrkes kõige vähem huvitav muutuja. Kõik otsustab liikluse kuju, mida puhverserver edastab, sest need puhverserverid saadavad baidivoogu ja UDP tunnel ei ole see. Nii jääb kaks arhitektuuri ja need katkevad eri kohtades.

Üks piirang otsustab lahenduse

SOCKS5 määratleb tõesti UDP assotsiatsiooni režiimi. OpenVPN kliendi puhverserveri tugi on siiski üles ehitatud voogudele: socks-proxy on dokumenteeritud TCP profiilide jaoks ning HTTP CONNECT puhverserveril ei ole datagrammidele üldse teed. Üks dokumentatsioonirida otsustab arhitektuuri enne, kui puudutate konfiguratsioonifaili.

Küsimus pole seega, millist puhverserverit valida. Küsimus on, kas tunnelist saab voog või jääb see datagrammiks ja laseb millelgi muul puhverduse enda kanda võtta.

Valik A: tee tunnelist voog

See nõuab serverit TCP kuulajaga ja kliendiprofiili, mis nimetab puhverserveri. Mõlemad osad on vajalikud ja just serveripool on see, mille inimesed unustavad:

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

Asendage viimane rida http-proxy proxy.internal 8080-ga, kui puhverserver räägib HTTP-d, ja lisage mandaadifail, kui see seda nõuab. Puhverserver peab olema valmis tegema CONNECTi teie VPN pordile ja server peab vastama TCP-l; ainult UDP kuulaja eirab katset. 443 valimine on praktiline käik, sest paljud piiravad võrgud lubavad seda ja vähe muud.

Hind on TCP TCP peal. Üks kadunud välimine segment peatab iga sisemise voo, mis seda ühendust jagab, nii et taastumine, mis tavaliselt oleks sõltumatu, muutub jagatuks. Seadistamine võtab ka kauem aega ning ebakindel välimine tee muutub ebakindlaks tunneliks, mitte aeglaseks.

Valik B: jäta tunnel rahule

Kui tunnel peab jääma UDP peale, ei ole tunnel koht, kus midagi seadistate. Selle asemel suunatakse rakenduste väljuv TCP kohalikule SOCKS kuulajale ja rakendused ei saa kunagi teada, et puhverserver on olemas. Linuxis on see tavaliselt redsocks pluss NAT REDIRECT reegel nat-tabelis.

Jälle ainult TCP. Ainult HTTP puhverserver nagu privoxy ei saa edastada suvalisi protokolle ja see lahendus ei lisa rakendustele ka datagrammitoetust.

Iga rakendusele puhverserverist otse rääkimine on tavaliselt parem seal, kus tarkvara seda toetab. Seda on lihtsam auditeerida ja see katkeb kohas, mida te tõesti näete.

Kus kumbki valik katkeb

Valik A katkeb, kui serveril puudub TCP kuulaja, kui puhverserver keeldub CONNECTi sihtmärgist või kui välimist voogu piiratakse alla selle, mida tunnel vajab. Esimesed kaks jätavad puhverserveri logisse kirje; kolmas jätab ühenduse, mis luuakse ja tundub siis vale. Lugege seda logi enne profiili muutmist, sest see eristab õiguse probleemi mahutavuse probleemist. Lõpetatud CONNECT viib uurimise tunneli sisse.

Valik B katkeb kõige juures, mis vajab datagramme, protokollide juures, mida puhverserver ei mõista, ja vaikselt hostidel, kus ümbersuunamise reegel on olemas, aga marsruutimine saadab liikluse sellest mööda.

Kumbki valik ei muuda seadme nõuet. Paketid vajavad endiselt TUN või TAP sõlme, enne kui kernel need marsruudib, seega vajab protsess endiselt õigust /dev/net/tun-le. Ümbris muudab seda, mis juhtub pärast selle sõlme avamist, mitte seda, kas te seda vajate.

Tõestage, millise tee ehitasite

Vaadake sokleid, mitte salve ikooni. VPN protsess peaks hoidma loodud ühendust puhverserveri aadressiga ja puhverserver peaks olema logi kirjutanud sihtmärgi, kuhu tal paluti jõuda:

ss -tnp | grep openvpn

Seejärel otsige sihtkoht, mida ainult tunnel saab teenindada, ja nimi, millele ainult tunneli resolver saab vastata. Lõpetatud puhverserveri ühendus surnud tunneliga tähendab tavaliselt, et kaugpool ei pakkunud kunagi teie profiilis nimetatud transporti.

Kirjutage transport ja vastuvõttev puhverserver kestvasse kohta. Kui sama profiil ebaõnnestub teises võrgus, välistab või kinnitab see märge puhverserveri sekunditega.