SOCKS5-proxy för OpenVPN: TCP-tunnel eller proxa apparna?

Nätverk som bara tillåter utgående trafik via en proxy är där en fungerande profil plötsligt dör. Proxyadressen är den minst intressanta variabeln i det felet. Allt avgörs av formen på trafiken som proxyn ska vidarebefordra, eftersom dessa proxys skickar en byteström och en UDP-tunnel är inte det. Det lämnar två arkitekturer, och de brister på olika ställen.

En begränsning avgör designen

SOCKS5 specificerar visserligen ett UDP-associationsläge. Proxy-stödet i OpenVPN-klienten är ändå byggt kring strömmar: socks-proxy är dokumenterad för TCP-profiler, och en HTTP CONNECT-proxy har ingen väg alls för datagram. En rad dokumentation avgör arkitekturen innan du rör en konfigurationsfil.

Frågan är därför inte vilken proxy du ska välja. Den är om tunneln blir en ström, eller förblir ett datagram och låter något annat absorbera proxningen.

Alternativ A: gör tunneln till en ström

Det kräver en server med en TCP-lyssnare och en klientprofil som namnger proxyn. Båda delarna behövs, och serversidan är den folk glömmer:

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

Byt ut den sista raden mot http-proxy proxy.internal 8080 när proxyn talar HTTP, och lägg till en inloggningsfil om den kräver det. Proxyn måste vara villig att utföra CONNECT mot din VPN-port, och servern måste svara på TCP; en lyssnare som bara är UDP ignorerar försöket. Att välja 443 är ett praktiskt drag, eftersom många restriktiva nätverk tillåter det och lite annat.

Priset är TCP staplad på TCP. Ett tappat yttre segment stoppar varje inre ström som delar den anslutningen, så återhämtning som annars skulle vara oberoende blir delad. Uppsättningen tar också längre tid, och en instabil yttre väg blir en instabil tunnel i stället för en långsam.

Alternativ B: låt tunneln vara

När tunneln måste stanna på UDP är tunneln inte platsen där du konfigurerar något. I stället omdirigeras utgående TCP från applikationer till en lokal SOCKS-lyssnare, och applikationerna får aldrig veta att en proxy finns. På Linux är det vanligtvis redsocks plus en NAT REDIRECT-regel i nat-tabellen.

Återigen bara TCP. En HTTP-bara-proxy som privoxy kan inte vidarebefordra godtyckliga protokoll, och den här designen lägger inte heller till datagramstöd för applikationerna.

Att berätta för varje applikation om proxyn direkt är oftast bättre där programvaran stöder det. Det är lättare att granska, och det brister på en plats du faktiskt kan se.

Var varje alternativ brister

Alternativ A brister när servern saknar en TCP-lyssnare, när proxyn avvisar CONNECT-målet, eller när den yttre strömmen stryps under vad tunneln behöver. De två första lämnar en post i proxyloggen; det tredje lämnar en anslutning som etableras och sedan känns fel. Läs den loggen innan du redigerar profilen, eftersom den skiljer ett behörighetsproblem från ett kapacitetsproblem. En slutförd CONNECT flyttar undersökningen in i tunneln.

Alternativ B brister för allt som behöver datagram, för protokoll som proxyn inte förstår, och tyst på värdar där omdirigeringsregeln finns men routningen skickar trafiken förbi den.

Inget av alternativen ändrar enhetskravet. Paket behöver fortfarande en TUN- eller TAP-nod innan kärnan routar dem, så processen behöver fortfarande behörighet på /dev/net/tun. Ett omslag ändrar vad som händer när noden är öppen, inte om du behöver en.

Bevisa vilken väg du byggde

Titta på sockets i stället för fackikonen. VPN-processen ska hålla en etablerad anslutning till proxyadressen, och proxyn ska ha loggat målet den ombads nå:

ss -tnp | grep openvpn

Sök sedan upp ett mål som bara tunneln kan betjäna, och ett namn som bara tunnelns resolver kan svara på. En slutförd proxyanslutning med en död tunnel betyder oftast att den andra änden aldrig erbjöd transporten som anges i din profil.

Anteckna transporten och den accepterande proxyn på en varaktig plats. När samma profil brister i ett annat nätverk utesluter eller bekräftar anteckningen proxyn inom sekunder.