SOCKS5-proxy for OpenVPN: TCP-tunnel eller proxy for appane?

Nettverk som berre lèt utgåande trafikk gå via ein proxy, er der ein fungerande profil plutseleg døyr. Proxyadressa er den minst interessante variabelen i den feilen. Alt blir avgjort av forma på trafikken som proxyen skal videresende, fordi desse proxyane sender ein bytestraun, og ein UDP-tunnel er ikkje det. Det lèt att to arkitekturer, og dei bryt saman på ulike stader.

Éi avgrensing avgjer designet

SOCKS5 spesifiserer riktig nok ein UDP-tilknytningsmodus. Proxy-støtta i OpenVPN-klienten er likevel bygd rundt straumar: socks-proxy er dokumentert for TCP-profilar, og ein HTTP CONNECT-proxy har ingen veg for datagram i det heile. Éi linje dokumentasjon avgjer arkitekturen før du rører ei konfigurasjonsfil.

Spørsmålet er difor ikkje kva proxy du skal velje. Det er om tunnelen blir ein straum, eller blir verande eit datagram og lèt noko anna ta seg av proxyinga.

Alternativ A: gjer tunnelen til ein straum

Dette krev ein server med ein TCP-lyttar og ein klientprofil som namngir proxyen. Begge delar er nødvendige, og serversida er den folk gløymer:

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

Byt ut den siste linja med http-proxy proxy.internal 8080 når proxyen snakkar HTTP, og legg til ei påloggingsfil om han krev det. Proxyen må vere villig til å utføre CONNECT til VPN-porten din, og serveren må svare på TCP; ein lyttar som berre er UDP, ignorerer forsøket. Å velje 443 er eit praktisk trekk, fordi mange restriktive nettverk tillèt det og lite anna.

Prisen er TCP stabla på TCP. Eitt tapt ytre segment stoppar kvar indre straum som deler den sambandet, så attoppretting som vanlegvis ville vore sjølvstendig, blir delt. Oppsettet tek også lengre tid, og ein ustabil ytre veg blir ein ustabil tunnel i staden for ein treg.

Alternativ B: lat tunnelen vere i fred

Når tunnelen må bli på UDP, er ikkje tunnelen staden der du konfigurerer noko. I staden blir utgåande TCP frå applikasjonar omdirigert til ein lokal SOCKS-lyttar, og applikasjonane får aldri vite at ein proxy finst. På Linux er det vanlegvis redsocks pluss ein NAT REDIRECT-regel i nat-tabellen.

Igjen berre TCP. Ein HTTP-berre-proxy som privoxy kan ikkje videresende vilkårlege protokollar, og dette designet legg heller ikkje til datagramstøtte for applikasjonane.

Å fortelje kvar applikasjon om proxyen direkte er vanlegvis betre der programvara støttar det. Det er lettare å revidere, og det sviktar på ein stad du faktisk kan sjå.

Kvar kvart alternativ sviktar

Alternativ A sviktar når serveren manglar ein TCP-lyttar, når proxyen avviser CONNECT-målet, eller når den ytre straumen blir strupt under det tunnelen treng. Dei to første lèt att ei oppføring i proxy-loggen; det tredje lèt att ei samband som blir etablert og deretter kjennest feil. Les den loggen før du redigerer profilen, fordi han skil eit løyveproblem frå eit kapasitetsproblem. Ein fullført CONNECT flyttar granskinga inn i tunnelen.

Alternativ B sviktar for alt som treng datagram, for protokollar proxyen ikkje forstår, og stille på vertar der omdirigeringsregelen finst, men ruttinga sender trafikken forbi han.

Ingen av alternativa endrar einingkravet. Pakkar treng framleis ein TUN- eller TAP-node før kjernen vil rute dei, så prosessen treng framleis løyve på /dev/net/tun. Ei innpakking endrar kva som skjer etter at noden er open, ikkje om du treng ein.

Prov kva veg du bygde

Sjå på soklar i staden for skuffikonet. VPN-prosessen skal halde ei etablert samband til proxyadressa, og proxyen skal ha logga målet han blei beden om å nå:

ss -tnp | grep openvpn

Nå deretter ut etter eit mål som berre tunnelen kan tena, og eit namn som berre resolvaren til tunnelen kan svare på. Ei fullført proxyforbindelse med ein død tunnel betyr vanlegvis at den andre enden aldri tilbaud transporten som er namngitt i profilen din.

Noter transporten og proxyen som godtek, på ein varig stad. Når same profil sviktar på eit anna nettverk, utelukkar eller stadfester notatet proxyen i løpet av sekund.