Hoe om gasheerverkeer deur 'n Docker-VPN-houer te lei

Jou tonnelhouer werk, docker compose exec vpn curl -s https://ifconfig.me antwoord met die verskaffer se adres, en die blaaier op jou lessenaar verlaat steeds jou netwerk via jou ISP. Daardie gaping is te verwagte. 'n Houer wat 'n VPN-kliënt laat loop, hou 'n netwerknaamruimte, roetes en 'n tonnelkoppelvlak, en niks wat HTTP of SOCKS praat nie; om 'n poort daarop te publiseer kan nie 'n ontvanger skep wat nooit daar was nie.

Waar die kliënt loop, bepaal die ontwerp. 'n Susterhouer kan in die tonnel se naamruimte intrek, 'n lessenaartoepassing kan nie, en 'n router het roetes nodig eerder as 'n proxyveld. Kry die kartering verkeerd en die simptoom is dieselfde: verbinding geweier, of verkeer wat stilweg die ou pad vat.

Pas die reëling by die plek waar die kliënt loop aan

Vra een vraag voordat jy Compose wysig: kan die kliënt binne die VPN-houer se netwerknaamruimte begin word? Enigiets wat al as 'n Linux-houer loop, kan. 'n Blaaier, 'n IDE of 'n CLI op jou tafel kan nie, want sy proxy-instelling verwag 'n protokoldiens, nie 'n naamruimte nie.

Hierdie drie meng nie. 'n HTTP-proxyveld wat na die houer se brugadres wys, bereik niks tensy 'n proxy daar luister, en 'n proxy-ontvanger roeteer nie 'n router se verkeer nie. Besluit eers, volg dan die passende afdeling.

Deel die tonnelnaamruimte met 'n susterhouer

Dit is die goedkoopste opsie omdat geen proxiprotokol betrokke is nie. Die app sluit by die vpn-diens se naamruimte aan en erf sy koppelvlakke, roetes en poortruimte:

services:
  vpn:
    image: your-vpn-client
    cap_add:
      - NET_ADMIN
    healthcheck:
      test: ["CMD-SHELL", "ip link show tun0 >/dev/null"]
      interval: 10s
      retries: 5
  app:
    image: your-app
    network_mode: service:vpn
    depends_on:
      vpn:
        condition: service_healthy

Drie beperkings volg daaruit dat die naamruimte aan 'n ander diens behoort. Die app kry geen networks sleutel van sy eie nie, want hy het geen naamruimte om aan te heg nie. Poortpublikasie hoort by vpn, want daar woon die naamruimte. En die herskep van vpn vernietig die naamruimte waarby die app aangesluit het, so docker compose up -d --force-recreate vpn laat jou om ook app te herskep; 'n gewone herbegin is nie altyd genoeg nie. Die Compose-diensverwysing dek hierdie reëling en sy beperking op poortpublikasie.

Moenie aanneem die oplosser kom saam nie. /etc/resolv.conf is 'n lêer per houer eerder as deel van die netwerknaamruimte, so die app kan steeds die gasheer se oplosser vra terwyl sy pakkette deur die tonnel vertrek. Lees dit binne die houer en stel dns: op die app wanneer private name deur die tonnel moet oplos.

docker compose exec app ip route
docker compose exec app cat /etc/resolv.conf
docker compose exec app curl -s https://ifconfig.me

As die roetelys die tonnelkoppelvlak bevat en die adres dié van die verskaffer is, is die app binne die tonnel. As die koppelvlak ontbreek, het app begin voordat vpn 'n tonnel gehad het, so herskep app sodra vpn gesond rapporteer.

Plaas 'n werklike proxy-ontvanger in die naamruimte vir gasheerkliënte

'n Lessenaarblaaier kan nie by 'n naamruimte aansluit nie, so die tonnel moet as 'n diens blootgestel word. Laat 'n werklike SOCKS- of HTTP-proxy binne die vpn-naamruimte loop en publiseer net sy poort:

services:
  vpn:
    ports:
      - "127.0.0.1:1080:1080"
  proxy:
    image: your-proxy
    network_mode: service:vpn
    command: ["--socks", "0.0.0.0:1080"]

Die gasheerkant-adres is die belangrike helfte van daardie kartering. 127.0.0.1:1080 aan die linkerkant hou die ontvanger van jou LAN af; 'n kaal "1080:1080" publiseer 'n oop proxy aan elke toestel wat jou masjien kan bereik.

Die houerkant het sy eie strik. Gepubliseerde poorte word by die houer se adres op die brug afgelewer, nie by sy loopback nie, so 'n proxy wat met --socks 127.0.0.1:1080 binne die naamruimte begin is, aanvaar verbindings van susters en weier alles wat deur die gepubliseerde poort aankom. Bind dit aan 0.0.0.0 en vertrou op die gasheerkant se loopback-binding vir isolasie. Dieselfde reël geld vir die luisteradres in 'n proxy-konfigurasielêer.

Besluit dan waar name opgelos word. In curl los --socks5 die gasheernaam plaaslik op en --socks5-hostname stuur die naam na die proxy; blaaiers bied dieselfde skakelaar onder 'n ander etiket. Plaaslike oplossing lek die opsoek selfs wanneer die bladsy deur die tonnel laai.

Behandel die houer as 'n poortwag slegs met 'n terugroete

Routers, VM's en telefone sal nie 'n HTTP-proxyveld gebruik nie, en sommige toepassings ignoreer proxy-veranderlikes heeltemal. Om hulle verkeer te roeteer beteken laag 3: die houer stuur pakkette aan en vertaal adresse op die tonnelkoppelvlak.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Twee dinge word maklik gemis. Die kliënt het 'n roete nodig wat sy verstekpoortwag na hierdie gasheer wys, en antwoorde moet terugkom, hetsy deur 'n statiese roete op die opstroom-router of deur NAT op die koppelvlak na die kliënte. Sonder een daarvan dra die tonnel die versoek uit en die antwoord verdwyn.

Dit het ook die wydste impak. 'n Gasheer wat as poortwag vir die hele LAN dien, stuur elke verkeerd opgestelde kliënt deur jou VPN-rekening, en 'n tonnelonderbreking óf maak die LAN dood óf val terug op die ISP, afhangend van die kill switch.

Verifieer die uitgangspad en rol dan in volgorde terug

Kontroleer in hierdie volgorde en stop by die eerste fout: uitgangadres binne die naamruimte, uitgangadres vanaf die gasheer deur die proxy, dan naamoplossing vir 'n private gasheer.

docker compose exec vpn curl -s https://ifconfig.me
curl -s -x socks5h://127.0.0.1:1080 https://ifconfig.me
curl -s -x socks5h://127.0.0.1:1080 http://internal.example/health

Die eerste twee adresse moet met die verskaffer ooreenstem, en die derde moet deur die proxy oplos in plaas daarvan om met 'n naamfout te misluk. 'n Ooreenstemmende eerste reël en 'n mislukkende tweede reël beteken die ontvanger of die gepubliseerde poort is verkeerd, nie die tonnel nie.

Terugrol is die omgekeerde van die opstelling. Verwyder die proxy-omgewingsveranderlikes uit die dop se profiel en uit enige systemd-eenheid, bring dan die stapel af sodat die gedeelde naamruimte saam met sy eienaar verdwyn. Skrap die gepubliseerde poort voordat jy die proxydiens skrap, anders hou die gasheer 'n loopback-ontvanger wat niks lees nie.

Voordat jy verder gaan, bevestig vier dinge: die kliënt waaraan jy aandag gee bereik werklik die tonnel, net die naamruimte-eienaar publiseer poorte, private name los op waar jy bedoel het, en niks luister op 'n nie-loopback-gasheeradres nie. Elkeen daarvan misluk stil in produksie, en elkeen is 'n eenreël-kontrole hierbo.