Firwat en Docker-Container Hosten hannert dem VPN net erreecht

En Container, deen hannert dem Firmen-VPN näischt erreecht, lieft normalerweis an engem aneren Netzwierk-Namespace wéi den Tunnel. D’Routen, DNS-Server an d’Firewall-Marken vum Host-Client gehéieren zum Stack vum Host; e Bridge-Container huet säin eegenen. Dës eenzeg Tatsaach erkläert déi meescht Meldungen, déi bei en Plattformteam kommen, an et ass och de Grond, firwat «de VPN ass futti» an «Docker geet ëm de VPN» allebéid gläichzäiteg falsch kënne sinn. Zwou ganz verschidde Konfiguratiounen verstoppen sech hannert engem Symptom, also bestëmmt wéi eng Dir hutt, ier Dir eng Astellung ännert.

Fannt eraus, wien den Namespace vum Tunnel besëtzt

Op Docker Desktop fir macOS oder Windows lafen d’Container an enger Linux-Vitualmaschinn. En VPN-Client, deen um Desktop installéiert ass, mécht en Tunnel am Betriebssystem vum Desktop, an d’Vitalmaschinn gesäit en ni. Keng Container-Konfiguratioun reparéiert dat, well d’Schnittstell, déi den Container bräicht, an sengem Netzwierk-Namespace guer net existéiert.

Op engem Linux-Host lieft den Tunnel am Namespace vum Host, an d’Bridge-Container erreechen en normalerweis iwwer d’Routingtabell vum Host mat Quell-NAT, dee beim Ausgang ugewannt gëtt. Wann dëse Wee feelt, ass d’Ursaach meeschtens Forwarding-Politik, Ëmgekehrte-Wee-Filterung oder en iwwerlappt Subnetz anstatt enger fehlender Route. Bestätegt a wat fir enger vun den zwou Welten Dir sidd, ier Dir weider liest:

docker info --format '{{.OperatingSystem}}'
docker run --rm --net=host alpine ip route | head -5
docker run --rm alpine ip route | head -5

Den Ënnerscheed tëscht dësen zwou Routingtabellen ass de ganze Problem op engem Bildschierm. Wann d’Host-Vue d’Tunnelschnittstell enthält an d’Bridge-Vue net, kuckt Dir op Namespace-Isolatioun, an alles anescht ass eng Wiel, wéi een se iwwerquiert.

Host-Netzwierk ass en Test, keen Design

En Container mam Host-Netzwierk lafen ze loossen, wat Docker als Deele vum Netzwierk-Namespace vum Host dokumentéiert, léisst en d’Tunnelschnittstell an hir Routen direkt ierwen. Wann déi selwecht Ufro duerno geléngt, ass d’Routentheorie confirméiert an de Feeler ass Namespace-Isolatioun an net Umeldungsdaten, DNS oder eng Zougangsregel.

docker run --rm --net=host curl -sS -o /dev/null -w '%{http_code}\n' https://api.internal/health

Halt en als Diagnos. Host-Netzwierk gëtt d’Portverëffentlechung an de gréissten Deel vun der Isolatioun op, déi Dir vun engem Container wollt, an op Docker Desktop heescht «host» d’Vitalmaschinn, net den Desktop, also kann e Erfolleg oder eng Nidderlag do Iech täuschen, wann Dir vergiesst, wéi en Host Dir ugeschwat hutt.

En tun-Gerät an d’Privilegien, déi domat kommen

En VPN-Client am Container brauch en Tunnelgerät an d’Erlaabnis, et ze konfiguréieren. D’üblech Ofkierzung ass --privileged, dat all Gerät gëtt an d’Sécherheetspolitik am ganze Container lues mécht. Dat ass vill méi wéi dës Aufgab verlaangt, an et ass schwéier an enger Iwwerpréiwung ze justifiéieren.

sudo modprobe tun
docker run --rm -it --device /dev/net/tun --cap-add NET_ADMIN myvpn-client

Déi méi schmuel Form mappt deen eenzegen Apparatknuet a füügt nëmmen d’Netzwierkverwaltungskompetenz derbäi. Luet de Modul fir d’éischt um Host, sou datt de Knuet existéiert. Wann de Container startet an de Client mellt, datt en d’Tunnelgerät net kann opmaachen, préift d’Mapping, ier Dir de Profil verdächtegt, well dëse Feeler ass meeschtens wuertwiertlech.

Dësen Design bedeit och, datt de Client pro Container leeft. Dat ass déi richteg Äntwert, wann all Aarbechtslaascht hire eigenen Tunnel brauch, an déi falsch, wann Dir just dem Host säin Tunnel sichtbar wollt hunn, wat den Plattformteam wahrscheinlech ugeholl huet, datt Dir et maacht.

Bridge-NAT ännert d’Quell, déi de VPN gesäit

Mat der Standard-Bridge gëtt de Container seng ausgehend Trafic op d’Hostadress iwwersat. Hannert engem VPN gesäit d’Firmesäit dann d’Tunneladress vum Host an net déi vum Container, Zougangsregelen pro Quell behuelen sech, wéi wann den Host d’Ufro geschéckt hätt, an zwee Container ginn fir de VPN-Server onënnerscheedbar.

macvlan oder ipvlan gëtt dem Container amplaz eng LAN-Adress, wat bei der LAN-Entdeckung hëlleft an de Container wéi e Gläichgestellten um Segment ausgesäit. Et ëmgeet och den Host-Tunnel komplett, also esou en Container wäert net bis op nëmmen-VPN-Präfixer kommen, ausser de VPN ass och aus deem LAN erreechbar.

Béid Forme si legitim; si beäntwerten ënnerschiddlech Ufuerderungen. Wann d’Ufuerderung ass «dësen Container muss engem nëmmen-VPN-Service erreechen», wielt Dir tëscht Routing iwwer den Host an dem Tunnel um Enn am Container. Schreift déi Wiel virun der Ausrollung op, net no der éischter feelgeschloener Ufro. Wat Dir och wielt, notéiert d’Quelladress, déi deen aneren Enn gesäit, well genau déi weisen seng Zougangsregelen a seng Logbicher. En Design, deen déi Adress net nenne kann, ass net fäerdeg.

DNS follegt dem Daemon, net dem Tunnel

En Container kritt seng Resolver-Konfiguratioun beim Start, kopéiert vum Daemon oder vum Image. Adressen, déi de VPN no der Verbindung dréckt, komme fir déi Kopie ze spéit, an si ginn an den Resolver vum Host gedréckt an net an de Container.

Setzt den Resolver explizit fir de Service, oder weist en op en internen Resolver, deen iwwer den Tunnel erreechbar ass. En Container, deen en privaten Numm op eng ëffentlech Adress opléist, benotzt meeschtens en ëffentleche Resolver, leid net ënner enger kaputter Route, an d’Korrektur gehéiert an d’Compose-Datei oder d’Daemon-Konfiguratioun.

Déi selwecht Iwwerleeung gëllt fir d’Fro vun der Ausgangsadress. Wann all Container vun enger anerer VPN-Adress erschéine muss, kann een Host-Tunnel dat net liwweren, well NAT se zu enger Quell zesummenfaasst. Déi funktionéierend Forme sinn e Client am Namespace vun all Container oder e Sidecar, deen den Tunnel besëtzt an säi Stack deelt, an allebéid änneren, wéi d’Applikatioun adresséiert gëtt.

Checklëscht ier Dir den Ticket zoumaacht: identifizéiert den Namespace, deen den Tunnel besëtzt, beweist de Wee mam Host-Netzwierk, mappt nëmmen dat néideg tun-Gerät, erënnert Iech un d’Quelladress no NAT, setzt den Resolver explizit a behandelt Ausgangsadressen pro Container als Architekturentscheedung an net als Fändel.