OpenVPN over SOCKS5: matche versjon, transport og DNS

SOCKS-kjeden feiler når proxyversjonen, transporten eller DNS-veien ikke stemmer. Match SOCKS5, bær TCP og hold kjeden innenfor ett navnerom.

Én vei ut fra denne arbeidsstasjonen er en SOCKS-proxy, og OpenVPN bak den rapporterer tidsavbrudd på tilkoblingen uten noen nyttig informasjon. Nettleseren på samme maskin virker gjennom den proxyen, påloggingsdataene er riktige og porten svarer. Tre ting skiller seg ofte nok ut til å sjekkes først: SOCKS-versjonen proxyen snakker, transporten klienten valgte, og stedet der navneoppslaget skjer. Bekreft hver av dem før du gir brannmuren skylden.

Match SOCKS-versjonen før brannmuren

Community-OpenVPN snakker SOCKS5 for socks-proxy. Pek den mot en proxy som bare tilbyr SOCKS4, og TCP-tilkoblingen åpnes og stanser, fordi klienten venter på svar på en hilsen den andre siden aldri tolker. Utenfra ser denne stansen nøyaktig ut som en filtrert port, og derfor kommer versjonsspørsmålet før enhver brannmurregel. Ett oppslag med SOCKS-kunnskap avgjør det med én kommando.

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

En fullført forespørsel beviser to ting samtidig: proxyen godtok SOCKS-forespørselen og den slo opp navnet. Det trengs ingen URL-ordning, fordi curl behandler en bar vert som HTTP, og det er nok for denne testen.

Det oppslaget utelukker også feilen klientloggen skjuler. En proxy kan tillate nettleseren og likevel avvise VPN-målet, og da skjer avvisningen ved CONNECT, før enhver VPN-autentisering. OpenVPN rapporterer bare tidsavbrudd, så proxyens eget svar er beviset du trenger.

Transporten må være TCP på begge sider

SOCKS5 bærer en TCP-strøm her, så selve tunnelen trenger proto tcp-client. En profil som fortsatt er satt til UDP virker ikke denne veien, fordi klienten ikke bruker protokollens UDP-tilknytningsmodus. Å snu profilen er en reell endring og ikke en formalitet: fjernsiden må lytte på TCP på samme port. Deretter blir nyttelasten TCP inne i TCP, der et tapt segment sendes på nytt to ganger og takten svekkes, noe interaktive økter merker langt mer enn store overføringer.

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

Direktivet tar proxyverten, en valgfri port og en valgfri påloggingsfil. Legg dem i selve profilen slik at en kopi oppfører seg likt et annet sted.

Lukk hele kjeden inne i én container

Å gjøre kjeden på verten betyr å ta over standardruten og la oppløseren stå i en tilstand ingen kan forklare senere. Et navnerom eller en container avgrenser den i stedet, så verten beholder sin egen vei mens SOCKS-hoppet og tunnelen lever sammen. Ingenting reiser seg inni uten en tunnelinnretning, rettigheter til å konfigurere den og en nåbar proxy. En Compose-tjeneste får det med cap_add: NET_ADMIN og en bind-montert /dev/net/tun.

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

Det paret er smalere enn å kjøre containeren privilegert, og det er hele den nødvendige enhetstilgangen. En Tor-klient eller en egen proxycontainer kan skaffe lytteren. Bind den i begge tilfeller til loopback og nå den fra navnerommet via verten i stedet for å eksponere proxyen mot nettet.

Navneoppslaget er der isolasjonen svikter

En tunnel som bærer pakker men likevel spør vertens oppløser, har ikke isolert noe. To ting gjør isolasjonen virkelig: navnerommet har sin egen oppløser, og spørringene går gjennom proxyen eller tunnelen, aldri over det fysiske grensesnittet. Bruk to navn i testen: ett som bare finnes bak tunnelen, og ett offentlig som bør følge samme vei.

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

Hvis fjernnavnet løses opp men det offentlige ikke, er kjeden selektiv og ikke ødelagt, og forskjellen forteller hvilken vei hver spørring tok. Hvis begge løses opp fra verten men ingen inne i containeren, låner containeren fortsatt vertens oppløser. Noter oppløserfilen du fant, for det er innstillingen som må endres.

Bevis hvert hopp i rekkefølge

Listen er kort. En SOCKS5-forespørsel får svar, tunnelen når lytteren sin gjennom proxyen, og pakker som forlater navnerommet bærer adressen fjernsiden forventer. Bekreft ett om gangen i stedet for å legge på mer konfigurasjon. Når klienten sier tilkoblet og ingenting rører seg, sitter bruddet nesten alltid i det andre eller tredje faktumet.

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 ned kombinasjonen som virket: SOCKS-versjon, transport, oppløser og navneromsinnstillinger. Å løse kjeden en gang til fra hukommelsen koster mer enn notatet. Ha de fire fakta i saken og ikke i chatten.

En kjede som rapporterer tilkoblet og ikke slipper noe gjennom, har som regel sviktet ved hoppet du ennå ikke har bevist. Test det hoppet før du legger til et lag til.

Relaterte artikler