Docker-Container-Traffic geet laanscht de Host-VPN: wéi ee et kontrolléiert
En Host-VPN deckt nëmmen den Netzwierk-Namensraum vum Host. Mat dëse Kontrollen erausfanne sech, ob den Traffic vun de Container op enger Bréck an den Tunnel geet oder direkt eraus.
Äre Browser um Host weist d'VPN-Exitadress, de Container mellt deng Heemverbindung, an een nennt dat en Leck. Et ass näischt ausgelaf. En Host-Tunnel ass e Bündel vun Interfaces, Routen a Regelen, déi zum Netzwierk-Namensraum vum Host gehéieren, an e Container op enger Bréck ass en aneren Namensraum mat senger eegener Standardroute. Ech hunn op engem Compose-Stack gesiess, wou de VPN-Client wochelaang verbonne war an net ee Containerpaket jee dra komm ass.
Kontrolléiert den Namensraum virun der Ikon an der Taskbar
Namensraim sinn dat ganzt Argument. Wann Docker e Container op engem Bréckennetzwierk start, schaaft et en Netzwierk-Namensraum, hänkt ee Enn vun engem veth-Puer dran, an gëtt deem Namensraum eng Adress an eng Standardroute. Den Tunnel-Interface, wéi en och ëmmer heescht, lieft am Namensraum vum Host. Den Traffic am Container kann en net gesinn, an keng Client-Astellung ännert dat vun dobaussen.
Zwou ënnerstëtzt Beweegunge bréngen dech aus der Isolatioun. --network host setzt de Container an den Namensraum vum Host, sou datt en d'Routen vum Host an domat den Tunnel ierft. --network container:vpn deelt den Namensraum vun engem anere Container, an esou schécken déi meescht Sidecar-Designen eng Aarbechtslaascht duerch e VPN-Container. Béides si bewosst Entscheedungen; meeschtens ass just eng dovun dat, wat déi Person, déi et deployéiert, gemengt huet.
Den Hostmodus ass keen gratis Upgrade. De Container huet keng eegen Adress méi, d'Portpublikatioun gëllt net méi, an e Prozess mat NET_ADMIN kann do d'Routéierung vum Host iwwerschreiwen. Dat z'akzeptéieren kann déi richteg Entscheedung sinn. Unzehuelen, et wier schonn un, ass de Grond, firwat Leit en Owend domat verbréngen, en Tunnel ze debuggen, deen ni am Wee war.
Follegt de Paket vun der Bréck ewech
En Container op der Bréck schéckt säi Paket un säi Standard-Gateway, dat ass den Interface vun der Bréck um Host. Den Host leet de Paket dann weider a setzt an der Standardkonfiguratioun d'Quelladress op seng eege ëm, ier de Paket erausgeet. Genee dëse Setzschrëtt hëlt d'Politik roueg aus den Angelen.
Bis de Paket um Tunnel-Endpunkt ukommt, dréit en d'Adress vum Host. All Regel, Politikroute oder Entscheedung iwwer en opgedeilten Tunnel, déi op der Originaladress vum Container baséiert, entsprécht net méi, an zwee Container, déi duerch verschidden Ausgäng erausgoe sollen, kënnen net just un der Quell ënnerscheet ginn. Wann s de Routéierung pro Container brauchs, muss d'Entscheedung virun der Ëmsetzung oder an engem Namensraum falen, deen s de kontrolléiers.
Docker ënnerhält dës Regele selwer, iwwer de Firewall-Backend, mat deem den Daemon konfiguréiert gouf. Handgeschriwwe Regele baussent dem ënnerstëtzten Hook fir weidergeleet Traffic, DOCKER-USER, kënne nei uerdert oder verworf ginn, wann den Daemon nei start oder den Host aktualiséiert gëtt. D'Docker-Dokumentatioun iwwer Paketfilterung weist d'Uerdnung vun de Ketten; de praktesche Punkt ass, datt all Regel en Eegentemer an e Nei-Luedwee brauch, deen s tatsächlech getest hues.
Test déi zwee Systemer getrennt
Beweiser aus engem Namensraum soen näischt iwwer deen aneren. Eng Ufro, déi am VPN-Container leeft, beweist, datt den Tunnel fir deen Container funktionéiert. Et ass kee Beweis iwwer den Host, an dee selwechte Kommando aus engem --network host-Container ass kee Beweis iwwer d'Bréck.
# host namespace
ip route get 1.1.1.1
ip -brief addr show
# a fresh container on the same bridge network
docker run --rm --network appnet alpine sh -c 'ip route; cat /etc/resolv.conf; ip -6 route'Widderhollt dann den Test am richtege Container vun der Applikatioun an net an engem ähnlechen Image. D'App kann eng zousätzlech Route, eng Proxy-Ëmweltvariabel oder en anere Resolver droen, an all dat ännert d'Äntwert. Kontrolléiert all Kéier d'Nimmopklärung an déi zweet Adressfamill: Container op benotzerdefinéierte Brécke ginn iwwer den agebaute Resolver vun Docker op 127.0.0.11 opgekläert, an eng IPv6-Standardroute op der Bréck ka Traffic erausbréngen, während s du domat beschäftegt bass, en Tunnel ze testen, deen nëmmen IPv4 ass.
Liest d'Muster, ier s d'Zougangsdaten ufässt
Wann den Host funktionéiert an de Container net, ass d'Ursaach bal ëmmer strukturell, an d'Schlëssele rotten oder de Client nei installéieren kascht en Nomëtteg. Sortéiert fir d'éischt de Symptom an d'Korrektur nennt sech meeschtens selwer.
| What you see | Usual cause | First check |
|---|---|---|
| Host exits through the VPN, container shows the ISP address | The container never entered the tunnel | Default route inside the container |
| Container works until the daemon restarts, then stops | Rules outside the supported hook, or a changed backend | Daemon's reported firewall backend and DOCKER-USER |
| Container loses internal hosts after the tunnel comes up | VPN prefix overlaps the Docker bridge subnet | ip route on the host, then docker network inspect |
| Small replies arrive, large ones hang | Tunnel MTU or missing MSS clamping | Link MTU on both ends of the tunnel |
| Container falls back to the ISP address when the tunnel drops | Nothing enforces the kill switch for forwarded traffic | Stop the tunnel with a request in flight |
D'Zeile vun der Iwwerlaapung verdéngt hire eigenen Ausso. E VPN-Profil, deen eng Route fir 172.17.0.0/16 dréckt, oder fir eng 10.0.0.0/8, déi zoufälleg däi Brécke-Präfix enthält, mécht, datt den Tunnel d'Containersubnetz behaapt, an d'Äntwerten op ëmgesat Adressen ginn an déi falsch Richtung oder verschwannen. D'Docker-Netzwierk nei ze nummeréieren ass meeschtens méi propper wéi Ausnamen ze sammelen.
Maacht d'Ofdeckung explizit an dann briecht se absichtlech
Zwee Designen halen enger Iwwerpréiwung stand. Deelt den Namensraum vum VPN-Container an all ofgedeckt Aarbechtslaascht benotzt een Tunnel mat enger Neistart-Grenz, wat einfach ass, bis engem Service en aneren Ausgang oder säin eegene DNS-Wee feelt. Oder leede d'Containernetzwierk op en VPN-Gateway um Host: Weiderleedung un, de Brécke-Präfix op den Tunnel geriicht, de Récktraffic explizit behandelt. Dat kaaft Kontroll pro Netzwierk a kascht dech e Reegelset, dee s iwwer Daemon- an Client-Upgraden ewech muss ënnerhalen.
Wéi och ëmmer, den Test, op deen et ukënnt, ass de Fehlerfall. Stoppt den Tunnel, wärend eng Container-Ufro ënnerwee ass, a kuckt wou de Paket higeet. Wann en op de direkte Wee zréckfält, gouf d'Ofdeckung ni duerchgesat, well de Kill Switch vun engem Client dee säin eegenen Traffic regeiert an net weidergeleet Paketen aus enger Bréck. Start duerno den Daemon an den Host nei a bestätegt d'Resultat en zweet Kéier; dat ass de Moment, wou handgeschriwwe Regele verschwannen.
Ier s et fäerdeg nennst, bestätegt véier Saachen: den Tunnel-Interface sëtzt am selwechten Namensraum wéi den Traffic, den Containertest ass am richtege Container gelaf, d'Nimmopklärung an déi zwou Adressfamillje goufen nogekuckt, an den Tunnel-Fehlertest feelt nach ëmmer zou. Schreift dann de Firewall-Backend, d'Client-Versioun an den Eegentemer vun all Regel op. Genee dësen Opzeechnung verhënnert, datt den nächsten Upgrade eng ondocumentéiert Mëschung aus ale Viraussetzungen hannerléisst.