Wéi de Host-Trafic duerch en Docker VPN-Container ëmleeden

En VPN-Container ass en Netzwerk-Namespace, keen Proxy. Wielt en gedeelte netns, e richtegen SOCKS-Listener oder en ëmgeleet Gateway, a verifizéiert duerno de Ausgangspad.

Ären Tunnelcontainer funktionéiert, docker compose exec vpn curl -s https://ifconfig.me äntwert mat der Adress vum Provider, an ëmmer nach geet de Browser op Ärem Schreifdësch duerch Ären ISP eraus. Dës Lück ass ze erwaarden. En Container, deen e VPN-Client ausféiert, hält en Netzwerk-Namespace, Routen an eng Tunnelschnittstell, an näischt, wat HTTP oder SOCKS schwätzt; e Port drop publizéieren kann keen Nolauschterer schafen, deen et ni gouf.

Wou de Client leeft, entscheet den Design. En Nopeschcontainer kann an den Namespace vum Tunnel wechseln, eng Desktop-Applikatioun kann dat net, an e Router brauch Routen amplaz vun engem Proxy-Feld. Maacht d'Mapping falsch, ass d'Symptom datselwecht: Verbindung refuséiert oder Trafic, deen onbemierkt den ale Wee hëlt.

Passt d'Arrangement un d'Plaz un, wou de Client leeft

Stellt eng Fro, ier Dir Compose ännert: Kann de Client am Netzwerk-Namespace vum VPN-Container gestart ginn? Alles, wat schonn als Linux-Container leeft, kann dat. E Browser, eng IDE oder eng CLI op Ärem Schreifdësch kann dat net, well seng Proxy-Astellung e Protokollservice erwaart, keen Namespace.

ClientArrangementWhat must already exist
Another Compose serviceShares the vpn namespace via network_mode: service:vpnA working tunnel and correct start order
Host browser, IDE or CLIProxy listener inside the namespace, published to host loopbackA configured SOCKS or HTTP proxy and its access rules
Router, VM or phoneThe container as a layer-3 gatewayForwarding, NAT and a return route

Dës dräi vermëschen sech net. En HTTP-Proxy-Feld, dat op d'Bréckenadress vum Container weist, erreecht näischt, ausser e Proxy lauschtert do, an en Proxy-Nolauschterer leet de Trafic vun engem Router net ëm. Entscheet fir d'éischt a follegt dann dem passenden Abschnitt.

Deelt den Tunnel-Namespace mat engem Nopeschcontainer

Dëst ass déi bëllegst Optioun, well kee Proxy-Protokoll bedeelegt ass. D'App trëtt dem Namespace vum vpn-Service bäi an ierft seng Schnittstellen, Routen a Portraum:

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

Dräi Restriktioune folgen doraus, datt den Namespace zu engem aneren Service gehéiert. D'App kritt keen eegene networks-Schlëssel, well se keen Namespace huet, un deen se sech hänke kann. D'Portpublikatioun gehéiert zu vpn, well do den Namespace lieft. An d'Neierschafe vun vpn zerstéiert den Namespace, dem d'App bäigetrueden ass, dofir léisst docker compose up -d --force-recreate vpn Iech och app neierschafen; en einfachen Neistart ass net ëmmer genuch. D'Compose-Servicereferenz deckt dëst Arrangement an seng Restriktioun bei der Portpublikatioun of.

Helt net, datt de Resolver matkënnt. /etc/resolv.conf ass eng Datei pro Container an net Deel vum Netzwerk-Namespace, dofir kann d'App nach de Resolver vum Host froen, während seng Pakete duerch den Tunnel erausgoen. Liest se am Container a setzt dns: op der App, wann privat Nimm duerch den Tunnel missen opgeléist ginn.

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

Wann d'Routelëscht d'Tunnelschnittstell enthält an d'Adress vum Provider ass, ass d'App am Tunnel. Feelt d'Schnittstell, ass app gestart, ier vpn en Tunnel hat, also erschaaft app nei, soubal vpn als gesond mëldet.

Setzt en echte Proxy-Nolauschterer an den Namespace fir Host-Clienten

En Desktop-Browser kann engem Namespace net bäitrieden, dofir muss den Tunnel als Service exponéiert ginn. Féiert en echte SOCKS- oder HTTP-Proxy am vpn-Namespace aus a publizéiert nëmmen säi Port:

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

D'Adress op der Hostsäit ass déi wichteg Halschent vun deem Mapping. 127.0.0.1:1080 lénks hält den Nolauschterer aus Ärem LAN eraus; en nackten "1080:1080" publizéiert en oppene Proxy fir all Apparat, deen Är Maschinn erreeche kann.

D'Containersäit huet hir eege Falle. Publizéiert Porte ginn un d'Adress vum Container op der Bréck geliwwert, net un säi Loopback, dofir akzeptéiert en Proxy, dee mat --socks 127.0.0.1:1080 am Namespace gestart gouf, Verbindungen vun Noperen a refuséiert alles, wat iwwer de publizéierte Port kënnt. Bind en un 0.0.0.0 a verlooss Iech op d'Loopback-Bindung op der Hostsäit fir Isolatioun. Déi selwecht Regel gëllt fir d'Lauschadress an enger Proxy-Konfiguratiounsdatei.

Dann entscheet, wou Nimm opgeléist ginn. An curl léist --socks5 den Hostnumm lokal op an --socks5-hostname schéckt den Numm un de Proxy; Browser weisen deeselwechte Schalter ënner engem anere Label. Lokal Opléisung verréit d'Ufro, och wann d'Säit duerch den Tunnel lued.

Behandelt den Container nëmme mat enger Réckrout als Gateway

Routeren, VMen an Telefone wäerten en HTTP-Proxy-Feld net benotzen, an e puer Applikatioune ignoréieren Proxy-Variabelen komplett. Hire Trafic ëmzeleet bedeit Schicht 3: den Container weiderleet Pakete a setzt Adressen op der Tunnelschnittstell ëm.

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

Zwou Saachen ginn einfach vergiess. De Client brauch eng Route, déi säin Standardgateway op dësen Host weist, an Äntwerten mussen de Wee zréck fannen, entweder iwwer eng statesch Route um Upstream-Router oder iwwer NAT op der Schnittstell zu de Clienten. Ouni eng vun deenen zwee dréit den Tunnel d'Ufro eraus an d'Äntwert verschwënnt.

Et huet och de breetsten Impakt. En Host, deen als Gateway fir de ganzen LAN déngt, schéckt all falsch konfiguréierte Client duerch Äre VPN-Konto, an en Tunnelfall blockéiert entweder de LAN oder fällt op den ISP zréck, jee no Kill Switch.

Verifizéiert den Ausgangspad a rufft duerno an der Rei zréck

Préift an dëser Rei a stoppt beim éischten Feeler: Ausgangsadress am Namespace, Ausgangsadress vum Host duerch de Proxy, dann Nummopléisung fir en private Host.

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

Déi éischt zwou Adresse sollen zum Provider passen, an déi drëtt soll duerch de Proxy opgeléist ginn, amplaz mat engem Nummfeeler ze scheiteren. Eng passend éischt Linn an eng feelend zweet Linn bedeiten, datt den Nolauschterer oder de publizéierte Port falsch ass, net den Tunnel.

Zréckrollen ass d'Géigendeel vum Opbau. Huelt d'Proxy-Ëmweltvariabelen aus dem Shell-Profil an aus all systemd-Eenheet eraus, a fuert dann de Stack erof, sou datt de gedeelten Namespace mat sengem Besëtzer verschwënnt. Läscht de publizéierte Port, ier Dir de Proxy-Service läscht, soss behält den Host en Loopback-Nolauschterer, deen keen lies.

Ier Dir weidergitt, bestätegt véier Saachen: de Client, deen Iech wichteg ass, erreecht tatsächlech den Tunnel, nëmmen de Besëtzer vum Namespace publizéiert Porten, privat Nimm ginn do opgeléist, wou Dir et wëllt, an näischt lauschtert op enger Hostadress, déi net Loopback ass. Jiddereen dovun feelt stëll an der Produktioun, a jiddereen ass eng eenzeilëg Kontroll uewen.

Ähnlech Artikelen