SOCKS5-proxy voor OpenVPN: TCP-tunnel of de apps proxien?

Netwerken die alleen uitgaand verkeer via een proxy toestaan, zijn de plek waar een werkend profiel plotseling sterft. Het proxyadres is de minst interessante variabele in die storing. Alles wordt bepaald door de vorm van het verkeer dat de proxy doorgeeft, want deze proxies vervoeren een bytestroom en een UDP-tunnel is dat niet. Dat laat twee architecturen over, en ze breken op verschillende plekken.

Eén beperking bepaalt het ontwerp

SOCKS5 specificeert weliswaar een UDP-associatiemodus. De proxyondersteuning van de OpenVPN-client is toch rond stromen gebouwd: socks-proxy is gedocumenteerd voor TCP-profielen, en een HTTP CONNECT-proxy heeft helemaal geen pad voor datagrammen. Eén regel documentatie beslecht de architectuur voordat je een configuratiebestand aanraakt.

De vraag is dus niet welke proxy je kiest. Ze is of de tunnel een stroom wordt, of een datagram blijft en iets anders het proxien laat overnemen.

Optie A: maak van de tunnel een stroom

Dat vereist een server met een TCP-listener en een cliëntprofiel dat de proxy benoemt. Beide onderdelen zijn nodig, en de serverkant is degene die men vergeet:

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

Vervang de laatste regel door http-proxy proxy.internal 8080 wanneer de proxy HTTP spreekt, en voeg een inlogbestand toe als hij dat eist. De proxy moet bereid zijn CONNECT naar je VPN-poort uit te voeren, en de server moet op TCP antwoorden; een listener die alleen UDP is, negeert de poging. 443 kiezen is een praktische zet, omdat veel restrictieve netwerken dat en weinig anders toestaan.

De prijs is TCP gestapeld op TCP. Eén verloren buitenste segment blokkeert elke binnenste stroom die die verbinding deelt, dus herstel dat normaal onafhankelijk zou zijn, wordt gedeeld. Het opzetten duurt ook langer, en een wankel buitenpad wordt een wankele tunnel in plaats van een langzame.

Optie B: laat de tunnel met rust

Als de tunnel op UDP moet blijven, is de tunnel niet de plek waar je iets configureert. In plaats daarvan wordt uitgaand TCP van applicaties omgeleid naar een lokale SOCKS-listener, en de applicaties komen er nooit achter dat er een proxy bestaat. Op Linux is dat meestal redsocks plus een NAT REDIRECT-regel in de nat-tabel.

Weer alleen TCP. Een alleen-HTTP-proxy zoals privoxy kan geen willekeurige protocollen doorgeven, en dit ontwerp voegt ook geen datagramondersteuning voor de applicaties toe.

Elke applicatie rechtstreeks over de proxy vertellen is meestal beter waar de software dat ondersteunt. Het is makkelijker te controleren, en het faalt op een plek die je echt kunt zien.

Waar elke optie faalt

Optie A faalt wanneer de server een TCP-listener mist, wanneer de proxy het CONNECT-doel weigert, of wanneer de buitenste stroom wordt geknepen onder wat de tunnel nodig heeft. De eerste twee laten een regel in het proxylog achter; de derde laat een verbinding achter die tot stand komt en dan verkeerd aanvoelt. Lees dat log voordat je het profiel bewerkt, want het scheidt een rechtenprobleem van een capaciteitsprobleem. Een voltooide CONNECT verplaatst het onderzoek naar binnen in de tunnel.

Optie B faalt voor alles wat datagrammen nodig heeft, voor protocollen die de proxy niet begrijpt, en stilzwijgend op hosts waar de omleidingsregel bestaat maar de routering het verkeer erlangs stuurt.

Geen van beide opties verandert de apparaatvereiste. Pakketten hebben nog steeds een TUN- of TAP-node nodig voordat de kernel ze routeert, dus het proces heeft nog steeds toestemming nodig op /dev/net/tun. Een wrapper verandert wat er gebeurt nadat die node open is, niet of je er een nodig hebt.

Bewijs welk pad je hebt gebouwd

Kijk naar sockets in plaats van het systeemvakpictogram. Het VPN-proces hoort een gevestigde verbinding naar het proxyadres te houden, en de proxy zou het doel hebben gelogd dat hem gevraagd werd te bereiken:

ss -tnp | grep openvpn

Zoek daarna een bestemming die alleen de tunnel kan bedienen, en een naam die alleen de resolver van de tunnel kan beantwoorden. Een voltooide proxyverbinding met een dode tunnel betekent meestal dat de tegenkant de transportmethode die in je profiel staat nooit heeft aangeboden.

Noteer de transportmethode en de accepterende proxy op een blijvende plek. Wanneer hetzelfde profiel op een ander netwerk faalt, sluit dat briefje de proxy binnen seconden uit of bevestigt hem.