SOCKS5 proxy za OpenVPN: TCP tunel ili proxy za aplikacije?

Mreže koje dopuštaju izlaz samo preko proxyja mjesto su gdje radni profil iznenada umre. Adresa proxyja najmanje je zanimljiva varijabla u tom neuspjehu. Sve odlučuje oblik prometa koji će proxy prenijeti, jer ti proxyji prenose tok bajtova, a UDP tunel to nije. Ostaju dvije arhitekture i one padaju na različitim mjestima.

Jedno ograničenje odlučuje dizajn

SOCKS5 doista propisuje način UDP asocijacije. Podrška za proxy u klijentu OpenVPN ipak je građena oko tokova: socks-proxy dokumentiran je za TCP profile, a HTTP CONNECT proxy nema nikakav put za datagrame. Jedan red dokumentacije rješava arhitekturu prije nego što dotaknete konfiguracijsku datoteku.

Pitanje dakle nije koji proxy odabrati. Nego postaje li tunel tok ili ostaje datagram i pušta nešto drugo da preuzme proxyranje.

Opcija A: pretvorite tunel u tok

To traži poslužitelj s TCP osluškivačem i klijentski profil koji imenuje proxy. Oba dijela su obavezna, a serversku stranu ljudi zaboravljaju:

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

Zamijenite zadnji red s http-proxy proxy.internal 8080 kad proxy govori HTTP i dodajte datoteku s vjerodajnicama ako je traži. Proxy mora biti spreman izvršiti CONNECT na vaš VPN port, a poslužitelj mora odgovarati na TCP; osluškivač samo na UDP taj pokušaj ignorira. Odabir 443 praktičan je potez jer mnoge restriktivne mreže dopuštaju njega i malo što drugo.

Cijena je TCP naslagan na TCP. Jedan izgubljeni vanjski segment zaustavlja svaki unutarnji tok koji dijeli tu vezu, pa oporavak koji bi inače bio neovisan postaje zajednički. Postavljanje također traje dulje, a nestabilna vanjska putanja postaje nestabilan tunel, a ne spor.

Opcija B: ostavite tunel na miru

Kad tunel mora ostati na UDP-u, tunel nije mjesto gdje bilo što konfigurirate. Umjesto toga izlazni TCP iz aplikacija preusmjerava se na lokalni SOCKS osluškivač i aplikacije nikad ne saznaju da proxy postoji. Na Linuxu je to obično redsocks uz pravilo NAT REDIRECT u tablici nat.

Opet samo TCP. Proxy samo za HTTP kao privoxy ne može prenositi proizvoljne protokole, a ovaj dizajn ni aplikacijama ne dodaje podršku za datagrame.

Reći svakoj aplikaciji o proxyju izravno obično je bolje tamo gdje softver to podržava. Lakše se revidira i pada negdje što doista možete vidjeti.

Gdje koja opcija pada

Opcija A pada kad poslužitelju nedostaje TCP osluškivač, kad proxy odbije cilj CONNECT ili kad je vanjski tok prigušen ispod onoga što tunelu treba. Prva dva ostavljaju zapis u proxy logu; treći ostavlja vezu koja se uspostavi i zatim izgleda pogrešno. Pročitajte taj log prije uređivanja profila, jer razdvaja problem dopuštenja od problema kapaciteta. Završen CONNECT premješta istragu unutar tunela.

Opcija B pada za sve što treba datagrame, za protokole koje proxy ne razumije i tiho na hostovima gdje pravilo preusmjeravanja postoji, ali usmjeravanje šalje promet pored njega.

Nijedna opcija ne mijenja zahtjev za uređajem. Paketi i dalje trebaju TUN ili TAP čvor prije nego što ih kernel usmjeri, pa postupku i dalje treba dopuštenje na /dev/net/tun. Omotač mijenja što se događa nakon što je taj čvor otvoren, a ne treba li vam on.

Dokažite koju ste putanju izgradili

Gledajte u sockete, a ne u ikonu u traci. VPN postupak treba držati uspostavljenu vezu s adresom proxyja, a proxy je trebao zabilježiti cilj koji je od njega zatražen:

ss -tnp | grep openvpn

Zatim posegnite za odredištem koje samo tunel može poslužiti i imenom na koje samo razrješivač tunela može odgovoriti. Završena proxy veza s mrtvim tunelom obično znači da udaljena strana nikad nije ponudila prijenos naveden u vašem profilu.

Zabilježite prijenos i proxy koji prihvaća na trajno mjesto. Kad isti profil padne na drugoj mreži, ta bilješka isključuje ili potvrđuje proxy u nekoliko sekundi.