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

Nettverk som bare tillater utgående trafikk via en proxy, er der en fungerende profil plutselig dør. Proxyadressen er den minst interessante variabelen i den feilen. Alt avgjøres av formen på trafikken proxyen skal videresende, fordi disse proxyene sender en bytestrøm, og en UDP-tunnel er ikke det. Det etterlater to arkitekturer, og de bryter sammen på forskjellige steder.

Én begrensning avgjør designet

SOCKS5 spesifiserer riktignok en UDP-tilknytningsmodus. Proxy-støtten i OpenVPN-klienten er likevel bygget rundt strømmer: socks-proxy er dokumentert for TCP-profiler, og en HTTP CONNECT-proxy har ingen vei for datagrammer i det hele tatt. Én linje dokumentasjon avgjør arkitekturen før du rører en konfigurasjonsfil.

Spørsmålet er derfor ikke hvilken proxy du skal velge. Det er om tunnelen blir en strøm, eller forblir et datagram og lar noe annet ta seg av proxyingen.

Alternativ A: gjør tunnelen til en strøm

Dette krever en server med en TCP-lytter og en klientprofil som navngir proxyen. Begge deler er nødvendige, og serversiden er den folk glemmer:

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

Bytt ut den siste linjen med http-proxy proxy.internal 8080 når proxyen snakker HTTP, og legg til en påloggingsfil hvis den krever det. Proxyen må være villig til å utføre CONNECT til VPN-porten din, og serveren må svare på TCP; en lytter som bare er UDP, ignorerer forsøket. Å velge 443 er et praktisk trekk, fordi mange restriktive nettverk tillater det og lite annet.

Prisen er TCP stablet på TCP. Ett tapt ytre segment stopper hver indre strøm som deler den forbindelsen, så gjenoppretting som vanligvis ville vært uavhengig, blir delt. Oppsettet tar også lengre tid, og en ustabil ytre vei blir en ustabil tunnel i stedet for en treg.

Alternativ B: la tunnelen være i fred

Når tunnelen må bli på UDP, er ikke tunnelen stedet der du konfigurerer noe. I stedet omdirigeres utgående TCP fra applikasjoner til en lokal SOCKS-lytter, og applikasjonene får aldri vite at en proxy finnes. På Linux er det vanligvis redsocks pluss en NAT REDIRECT-regel i nat-tabellen.

Igjen bare TCP. En HTTP-bare-proxy som privoxy kan ikke videresende vilkårlige protokoller, og dette designet legger heller ikke til datagramstøtte for applikasjonene.

Å fortelle hver applikasjon om proxyen direkte er vanligvis bedre der programvaren støtter det. Det er lettere å revidere, og det svikter et sted du faktisk kan se.

Hvor hvert alternativ svikter

Alternativ A svikter når serveren mangler en TCP-lytter, når proxyen avviser CONNECT-målet, eller når den ytre strømmen strupes under det tunnelen trenger. De to første etterlater en oppføring i proxy-loggen; det tredje etterlater en forbindelse som etableres og deretter føles feil. Les den loggen før du redigerer profilen, fordi den skiller et tillatelsesproblem fra et kapasitetsproblem. En fullført CONNECT flytter undersøkelsen inn i tunnelen.

Alternativ B svikter for alt som trenger datagrammer, for protokoller proxyen ikke forstår, og stille på verter der omdirigeringsregelen finnes, men rutingen sender trafikken forbi den.

Ingen av alternativene endrer enhetskravet. Pakker trenger fortsatt en TUN- eller TAP-node før kjernen vil rute dem, så prosessen trenger fortsatt tillatelse på /dev/net/tun. En innpakning endrer hva som skjer etter at noden er åpen, ikke om du trenger en.

Bevis hvilken vei du bygde

Se på sockets i stedet for skuffikonet. VPN-prosessen skal holde en etablert forbindelse til proxyadressen, og proxyen skal ha logget målet den ble bedt om å nå:

ss -tnp | grep openvpn

Nå deretter ut etter et mål som bare tunnelen kan betjene, og et navn som bare tunnelens resolver kan svare på. En fullført proxyforbindelse med en død tunnel betyr vanligvis at den andre enden aldri tilbød transporten som er navngitt i profilen din.

Noter transporten og proxyen som godtar, på et varig sted. Når samme profil svikter på et annet nettverk, utelukker eller bekrefter notatet proxyen i løpet av sekunder.