SOCKS5-proxy til OpenVPN: TCP-tunnel eller proxy til appene?

En proxy videresender en strøm, ikke et datagram. Sammenlign en TCP-tunnel bag socks-proxy med en redsocks-omdirigering, og se, hvor hvert design fejler først.

Netværk, der kun tillader udgående trafik via en proxy, er der, hvor en fungerende profil pludselig dør. Proxyadressen er den mindst interessante variabel i den fejl. Alt afgøres af den trafikform, proxyen skal videresende, fordi disse proxyer sender en bytestrøm, og en UDP-tunnel er ikke én. Det efterlader to arkitekturer, og de brækker på forskellige steder.

Én begrænsning afgør designet

SOCKS5 specificerer faktisk en UDP-associeringstilstand. Alligevel er proxyunderstøttelsen i OpenVPN-klienten bygget op omkring strømme: socks-proxy er dokumenteret til TCP-profiler, og en HTTP CONNECT-proxy har slet ingen vej for datagrammer. Én linje dokumentation afgør arkitekturen, før du rører en konfigurationsfil.

Spørgsmålet er derfor ikke, hvilken proxy du skal vælge. Det er, om tunnelen bliver en strøm, eller forbliver et datagram og lader noget andet absorbere proxyarbejdet.

Mulighed A: gør tunnelen til en strøm

Det kræver en server med en TCP-lytter og en klientprofil, der navngiver proxyen. Begge dele er nødvendige, og serversiden er den, folk glemmer:

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

Erstat den sidste linje med http-proxy proxy.internal 8080, når proxyen taler HTTP, og tilføj en legitimationsfil, hvis den kræver en. Proxyen skal være villig til at udføre CONNECT til din VPN-port, og serveren skal svare på TCP; en lytter, der kun er UDP, ignorerer forsøget. At vælge 443 er et praktisk træk, fordi mange restriktive netværk tillader det og næsten intet andet.

Prisen er TCP stablet på TCP. Et tabt ydre segment standser hver indre strøm, der deler den forbindelse, så genopretning, der normalt ville være uafhængig, bliver delt. Opsætningen tager også længere tid, og en ustabil ydre vej bliver en ustabil tunnel i stedet for en langsom.

Mulighed B: lad tunnelen være

Når tunnelen skal blive på UDP, er tunnelen ikke stedet, hvor du konfigurerer noget. I stedet omdirigeres udgående TCP fra programmer til en lokal SOCKS-lytter, og programmerne finder aldrig ud af, at der findes en proxy. På Linux er det typisk redsocks plus en NAT REDIRECT-regel i nat-tabellen.

Igen kun TCP. En HTTP-kun-proxy som privoxy kan ikke videresende vilkårlige protokoller, og dette design tilføjer heller ikke datagramunderstøttelse til programmerne.

At fortælle hvert program om proxyen direkte er normalt bedre, hvor softwaren understøtter det. Det er lettere at revidere, og det fejler et sted, du faktisk kan se.

Hvor hver mulighed fejler

Mulighed A fejler, når serveren mangler en TCP-lytter, når proxyen afviser CONNECT-målet, eller når den ydre strøm begrænses under det, tunnelen har brug for. De to første efterlader en post i proxyloggen; det tredje efterlader en forbindelse, der etableres og derefter føles forkert. Læs den log, før du redigerer profilen, fordi den skelner et tilladelsesproblem fra et kapacitetsproblem. En fuldført CONNECT flytter undersøgelsen ind i tunnelen.

Mulighed B fejler for alt, der har brug for datagrammer, for protokoller som proxyen ikke forstår, og stille på værter, hvor omdirigeringsreglen findes, men routing sender trafikken forbi den.

Ingen af mulighederne ændrer enhedskravet. Pakker har stadig brug for en TUN- eller TAP-node, før kernen vil route dem, så processen har stadig brug for tilladelse på /dev/net/tun. En indpakning ændrer, hvad der sker, når den node er åben, ikke om du har brug for en.

Bevis hvilken vej du byggede

Kig på sockets i stedet for tray-ikonet. VPN-processen skal holde en etableret forbindelse til proxyadressen, og proxyen skal have logget det mål, den blev bedt om at nå:

ss -tnp | grep openvpn

Nå derefter ud efter en destination, som kun tunnelen kan betjene, og et navn, som kun tunnelens resolver kan svare på. En fuldført proxyforbindelse med en død tunnel betyder normalt, at den fjerne ende aldrig tilbød den transport, der er nævnt i din profil.

Notér transporten og den accepterende proxy et varigt sted. Når samme profil fejler på et andet netværk, udelukker eller bekræfter noten proxyen på få sekunder.

Relaterede artikler