SOCKS5-prokurilo por OpenVPN: TCP-tunelo aŭ prokurigi la programojn?

Prokurilo transdonas fluon, ne datagramon. Komparu TCP-tunelon malantaŭ socks-proxy kun redsocks-alidirektado, kaj vidu, kie ĉiu dezajno unue fiaskas.

Retoj, kiuj permesas eliron nur tra prokurilo, estas la loko, kie funkcianta profilo subite mortas. La prokurila adreso estas la malplej interesa variablo en tiu fiasko. Ĉion decidas la formo de la trafiko, kiun la prokurilo transdonos, ĉar tiuj prokuriloj plusendas bajtan fluon kaj UDP-tunelo ne estas tia. Tio lasas du arkitekturojn, kaj ili rompiĝas en malsamaj lokoj.

Unu limigo decidas la dezajnon

SOCKS5 ja specifas UDP-asocia reĝimo. La prokurila subteno de la OpenVPN-kliento tamen estas konstruita ĉirkaŭ fluoj: socks-proxy estas dokumentita por TCP-profiloj, kaj HTTP CONNECT-prokurilo tute ne havas vojon por datagramoj. Unu linio de dokumentaro decidas la arkitekturon antaŭ ol vi tuŝos agordan dosieron.

La demando do ne estas, kiun prokurilon elekti. Ĝi estas, ĉu la tunelo fariĝas fluo, aŭ restas datagramo kaj lasas ion alian sorbi la prokurigadon.

Opcio A: faru la tunelon fluo

Tio bezonas servilon kun TCP-aŭskultanto kaj klientan profilon, kiu nomas la prokurilon. Ambaŭ partoj necesas, kaj la servila flanko estas tiu, kiun homoj forgesas:

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

Anstataŭigu la lastan linion per http-proxy proxy.internal 8080, kiam la prokurilo parolas HTTP, kaj aldonu akreditan dosieron se ĝi postulas unu. La prokurilo devas preti fari CONNECT al via VPN-pordo, kaj la servilo devas respondi per TCP; aŭskultanto nur UDP ignoras la provon. Elekti 443 estas praktika movo, ĉar multaj restriktaj retoj permesas ĝin kaj malmulton alian.

La kosto estas TCP sur TCP. Unu perdita ekstera segmento haltigas ĉiun internan fluon, kiu dividas tiun konekton, do reakiro, kiu ordinare estus sendependa, fariĝas komuna. La agordo ankaŭ daŭras pli longe, kaj malstabila ekstera vojo fariĝas malstabila tunelo anstataŭ malrapida.

Opcio B: lasu la tunelon trankvila

Kiam la tunelo devas resti sur UDP, la tunelo ne estas la loko, kie vi agordas ion. Anstataŭe, elira TCP de programoj estas alidirektata al loka SOCKS-aŭskultanto, kaj la programoj neniam ekscias, ke prokurilo ekzistas. En Linukso tio estas kutime redsocks plus NAT REDIRECT-regulo en la nat-tabelo.

Nur TCP, denove. Prokurilo nur-HTTP kiel privoxy ne povas transdoni arbitrajn protokolojn, kaj ĉi tiu dezajno ankaŭ ne aldonas datagraman subtenon por la programoj.

Diri al ĉiu programo pri la prokurilo rekte estas kutime pli bone, kie la programaro subtenas tion. Ĝi estas pli facile aŭdebla, kaj ĝi fiaskas ie, kion vi povas efektive vidi.

Kie ĉiu opcio fiaskas

Opcio A fiaskas, kiam la servilo mankas al TCP-aŭskultanto, kiam la prokurilo rifuzas la CONNECT-celon, aŭ kiam la ekstera fluo estas limigita sub tio, kion la tunelo bezonas. La unuaj du lasas rikordon en la prokurila protokolo; la tria lasas konekton, kiu establiĝas kaj poste ŝajnas malĝusta. Legu tiun protokolon antaŭ ol redakti la profilon, ĉar ĝi apartigas permesan problemon de kapacita problemo. Kompletigita CONNECT movas la esploradon en la tunelon.

Opcio B fiaskas por io ajn bezonanta datagramojn, por protokoloj, kiujn la prokurilo ne komprenas, kaj silente sur gastigantoj, kie la alidirekta regulo ekzistas sed enkursigo sendas la trafikon preter ĝi.

Neniu opcio ŝanĝas la postulon pri aparato. Pakoj ankoraŭ bezonas TUN- aŭ TAP-nodon antaŭ ol la kerno enkursigos ilin, do la procezo ankoraŭ bezonas permeson sur /dev/net/tun. Ĉirkaŭaĵo ŝanĝas, kio okazas post kiam tiu nodo estas malfermita, ne ĉu vi bezonas unu.

Pruvu, kiun vojon vi konstruis

Rigardu ingojn anstataŭ la pleto-ikono. La VPN-procezo devus teni establigitan konekton al la prokurila adreso, kaj la prokurilo devus esti protokolinta la celon, kiun oni petis ĝin atingi:

ss -tnp | grep openvpn

Poste serĉu celon, kiun nur la tunelo povas servi, kaj nomon, kiun nur la tunela solvilo povas respondi. Kompletigita prokurila konekto kun morta tunelo kutime signifas, ke la malproksima flanko neniam proponis la transporton nomitan en via profilo.

Notu la transporton kaj la akceptantan prokurilon en daŭra loko. Kiam la sama profilo fiaskas en alia reto, tiu noto ekskludas aŭ konfirmas la prokurilon en sekundoj.

Rilataj artikoloj