OpenVPN over SOCKS5: tilpas version, transport og DNS

En SOCKS-kæde fejler, når proxyversionen, transporten eller DNS-stien ikke stemmer. Vælg SOCKS5, kør TCP, og hold kæden inde i et namespace.

Én rute ud af denne arbejdsstation er en SOCKS-proxy, og OpenVPN bag den rapporterer en forbindelsestimeout uden noget brugbart vedhæftet. En browser på samme maskine fungerer gennem den proxy, legitimationsoplysningerne er korrekte, og porten svarer. Tre ting afviger ofte nok til at blive tjekket først: den SOCKS-version proxyen taler, den transport klienten valgte, og hvor navneopløsningen finder sted. Bekræft hver af dem, før du beslutter, at firewalling er skylden.

Tilpas SOCKS-versionen før firewallen

Community OpenVPN taler SOCKS5 til socks-proxy. Peg den på en proxy, der kun tilbyder SOCKS4, og TCP-forbindelsen åbner, hvorefter den går i stå, fordi klienten venter på svar på en hilsen, som den anden ende aldrig parser. Udefra ligner det stop præcis en filtreret port, og derfor kommer versionsspørgsmålet før enhver firewallregel. Et SOCKS-opslag afgør det med én kommando.

curl --socks5-hostname 127.0.0.1:9050 gw.lab.example

En fuldført anmodning beviser to ting på én gang: proxyen accepterede SOCKS-anmodningen, og den opløste navnet. Der kræves ingen URL-skema, fordi curl behandler en bar vært som HTTP, hvilket er nok til denne test.

Det opslag udelukker også den fejl, klientloggen skjuler. En proxy kan tillade browseren og alligevel afvise VPN-destinationen, og i så fald sker afvisningen ved CONNECT, før nogen VPN-godkendelse. OpenVPN rapporterer kun en timeout, så proxyens eget svar er det bevis, du har brug for.

Transporten skal være TCP i begge ender

SOCKS5 bærer her en TCP-strøm, så tunnelen selv skal bruge proto tcp-client. En profil, der stadig er sat til UDP, virker ikke ad denne vej, fordi klienten ikke bruger protokollens UDP-associeringstilstand. At skifte profilen er en reel ændring og ikke en formalitet: den fjerne ende skal lytte på TCP på samme port. Nyttelasten bliver derefter TCP inde i TCP, hvor et tabt segment gensendes to gange, og tempoet forringes, hvilket interaktive sessioner bemærker langt mere end store overførsler.

proto tcp-client
remote gw.lab.example 8443
socks-proxy 127.0.0.1 9050

Direktivet tager proxyværten, en valgfri port og en valgfri legitimationsfil. Sæt dem i selve profilen, så en kopi opfører sig identisk andre steder.

Begræns hele kæden til én container

At køre kæden på værten betyder at overtage dens standardrute og efterlade resolveren i en tilstand, som ingen senere kan forklare. Et namespace eller en container afgrænser det i stedet, så værten beholder sin egen vej, mens SOCKS-hoppet og tunnelen lever sammen. Intet kommer op derinde uden en tunenhed, rettighederne til at konfigurere den og en tilgængelig proxy. En Compose-tjeneste får det med cap_add: NET_ADMIN og en bind-monteret /dev/net/tun.

cap_add:
  - NET_ADMIN
devices:
  - /dev/net/tun:/dev/net/tun

Det par er snævrere end at køre containeren privilegeret, og det er hele den nødvendige enhedsadgang. En Tor-klient eller en separat proxycontainer kan levere lytteren. Bind den under alle omstændigheder til loopback, og nå den fra namespacet gennem værten i stedet for at eksponere proxyen for netværket.

Navneopløsning er stedet, hvor isoleringen svigter

En tunnel, der bærer pakker, mens den spørger værtens resolver, har ikke isoleret noget. To ting gør isoleringen reel: namespacet har sin egen resolver, og dets forespørgsler rejser gennem proxyen eller tunnelen, aldrig over den fysiske grænseflade. Brug to navne til testen: et, der kun findes bag tunnelen, og et offentligt, som bør følge samme vej.

docker compose exec vpn cat /etc/resolv.conf
docker compose exec vpn getent hosts internal.lab.example

Hvis navnet på den fjerne side opløses, og det offentlige ikke gør, er kæden selektiv snarere end brudt, og forskellen fortæller dig, hvilken vej hver forespørgsel tog. Hvis begge opløses fra værten, men ingen inde i containeren, låner containeren stadig værtens resolver. Notér den resolverfil, du fandt, for det er den indstilling, der skal ændres.

Bevis hvert hop i rækkefølge

Listen er kort. En SOCKS5-anmodning får svar, tunnelen når sin lytter gennem proxyen, og pakker, der forlader namespacet, bærer den adresse, den fjerne side forventer. Bekræft hvert enkelt ad gangen i stedet for at lægge mere konfiguration ovenpå. Når klienten siger forbundet, og intet bevæger sig, sidder bruddet næsten altid i den anden eller tredje kendsgerning.

curl --socks5-hostname 127.0.0.1:9050 gw.lab.example
docker compose exec vpn ip route get 203.0.113.10
docker compose exec vpn getent hosts internal.lab.example

Skriv kombinationen ned, som virkede: SOCKS-version, transport, resolver og namespace-indstillinger. At løse denne kæde en gang til fra hukommelsen koster mere end notatet. Opbevar de fire kendsgerninger i sagen frem for i en chat-tråd.

En kæde, der rapporterer forbindelse og ikke sender noget igennem, er som regel fejlet ved det hop, du endnu ikke har bevist. Test det hop, før du tilføjer endnu et lag.

Relaterede artikler