Korleis rute vertstrafikk gjennom ein Docker VPN-container

Tunnelcontaineren din fungerer, docker compose exec vpn curl -s https://ifconfig.me svarar med adressa til leverandøren, og likevel går nettlesaren på skrivebordet ditt ut via ISP-en din. Det gapet er venta. Ein container som køyrer ein VPN-klient, held eit nettverksnamnerom, ruter og eit tunellgrensesnitt, og ingenting som snakkar HTTP eller SOCKS; å publisere ein port på han kan ikkje skape ein lyttar som aldri var der.

Kvar klienten køyrer, avgjer designet. Ein syskencontainer kan flytte inn i namnerommet til tunnelen, ein skrivebordsapplikasjon kan ikkje, og ein ruter treng ruter framfor eit proxyfelt. Tek du kartlegginga feil, er symptomet det same: tilkopling nekta, eller trafikk som stille tek den gamle vegen.

Tilpass oppsettet til staden der klienten køyrer

Still eitt spørsmål før du redigerer Compose: kan klienten startast inne i nettverksnamnerommet til VPN-containeren? Alt som alt køyrer som ein Linux-container, kan. Ein nettlesar, ein IDE eller ein CLI på skrivebordet ditt kan ikkje, fordi proxyinnstillinga ventar ei protokollteneste, ikkje eit namnerom.

Desse tre blandar seg ikkje. Eit HTTP-proxyfelt retta mot broadressa til containeren når ingenting med mindre ein proxy lyttar der, og ein proxylyttar ruter ikkje trafikken til ein ruter. Bestem først, og følg deretter den aktuelle delen.

Del tunellnamnerommet med ein syskencontainer

Dette er det billegaste alternativet fordi ingen proxyprotokoll er involvert. Appen koplar seg til namnerommet til vpn-tenesta og arvar grensesnitta, rutene og portrommet:

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

Tre avgrensingar følgjer av at namnerommet høyrer til ei anna teneste. Appen får ingen eigen networks-nøkkel, fordi han ikkje har noko namnerom å feste seg til. Portpublisering høyrer til vpn, sidan det er der namnerommet bur. Og nyoppretting av vpn øydelegg namnerommet appen kopla seg til, så docker compose up -d --force-recreate vpn overlèt til deg å opprette app på nytt òg; ein vanleg omstart er ikkje alltid nok. Compose-tenestereferansen dekkjer dette oppsettet og avgrensinga for portpublisering.

Ikkje gå ut frå at resolvaren følgjer med. /etc/resolv.conf er ei fil per container, ikkje ein del av nettverksnamnerommet, så appen kan framleis spørje resolvaren til verten medan pakkane går ut gjennom tunnelen. Les ho inne i containeren og set dns: på appen når private namn må løysast gjennom tunnelen.

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

Viss rutelista inneheld tunellgrensesnittet og adressa er leverandøren si, er appen inne i tunnelen. Viss grensesnittet manglar, starta app før vpn hadde ein tunnel, så opprett app på nytt når vpn rapporterer at han er frisk.

Set ein ekte proxylyttar i namnerommet for vertsklientar

Ein skrivebordsnettlesar kan ikkje bli med i eit namnerom, så tunnelen må eksponerast som ei teneste. Køyr ein ekte SOCKS- eller HTTP-proxy inne i vpn-namnerommet og publiser berre porten:

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

Adressa på vertssida er den viktige halvdelen av den kartlegginga. 127.0.0.1:1080 til venstre held lyttaren utanfor LAN-et ditt; ein naken "1080:1080" publiserer ein open proxy til kvar eining som kan nå maskina di.

Containersida har si eiga felle. Publiserte portar vert leverte til adressa til containeren på brua, ikkje til loopbacken, så ein proxy starta med --socks 127.0.0.1:1080 inne i namnerommet godtek tilkoplingar frå sysken og avviser alt som kjem gjennom den publiserte porten. Bind han til 0.0.0.0 og stol på loopback-bindinga på vertssida for isolasjon. Same regel gjeld lyttaradressa i ei proxykonfigurasjonsfil.

Deretter avgjer du kvar namn vert løyste. I curl løyser --socks5 vertsnamnet lokalt, og --socks5-hostname sender namnet til proxyen; nettlesarar viser same brytaren under ei anna etikett. Lokal oppløysing lek oppslaget sjølv når sida lastast gjennom tunnelen.

Behandle containeren som gateway berre med ein returrute

Ruterar, VM-ar og telefonar vil ikkje bruke eit HTTP-proxyfelt, og nokre applikasjonar ignorerer proxyvariablar heilt. Å rute trafikken deira betyr lag 3: containeren vidaresender pakkar og omset adresser på tunellgrensesnittet.

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

To ting er lette å oversjå. Klienten treng ei rute som peikar standardgatewayen mot denne verten, og svar må finne vegen tilbake, anten gjennom ei statisk rute på oppstraumsruteren eller gjennom NAT på grensesnittet mot klientane. Utan ein av dei ber tunnelen førespurnaden ut, og svaret forsvinn.

Han har òg den breiaste verknaden. Ein vert som fungerer som gateway for heile LAN-et, sender kvar feilkonfigurert klient gjennom VPN-kontoen din, og eit tunnelfall blokkerer anten LAN-et eller fell tilbake til ISP-en avhengig av kill switch.

Verifiser utgangsstien, og rull deretter tilbake i rekkjefølgje

Kontroller i denne rekkjefølgja og stopp ved første feil: utgangsadresse inne i namnerommet, utgangsadresse frå verten gjennom proxyen, deretter namneoppløysing for ein privat vert.

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

Dei to første adressene skal samsvare med leverandøren, og den tredje skal løysast gjennom proxyen i staden for å feile med ein namnefeil. Ei samsvarande første linje og ei feilande andre linje betyr at lyttaren eller den publiserte porten er feil, ikkje tunnelen.

Tilbakerulling er det motsette av oppsettet. Fjern proxy-miljøvariablane frå skalprofilen og frå kvar systemd-eining, og ta deretter stakken ned slik at det delte namnerommet forsvinn med eigaren sin. Slett den publiserte porten før du slettar proxytentesta, elles held verten ein loopback-lyttar som ingen les.

Før du går vidare, stadfest fire ting: klienten du bryr deg om når faktisk tunnelen, berre eigaren av namnerommet publiserer portar, private namn vert løyste der du hadde tenkt, og ingenting lyttar på ei vertsadresse som ikkje er loopback. Kvar av dei feilar stille i produksjon, og kvar er ein einlinjekontroll ovanfor.