Docker-containeres trafik omgår din vært-VPN: sådan tjekker du det

Din browser på værten viser VPN-udgangsadressen, containeren rapporterer din hjemmeforbindelse, og nogen kalder det en lækage. Intet er lækket. En værtstunnel er en samling af interfaces, ruter og regler, der hører til værtens netværksnavnerum, og en container på en bro er et andet navnerum med sin egen standardrute. Jeg har siddet på et Compose-stack, hvor VPN-klienten havde været forbundet i uger, og ikke én containerpakke var nogensinde kommet ind i den.

Tjek navnerummet før ikonet i proceslinjen

Navnerum er hele argumentet. Når Docker starter en container på et bro-netværk, opretter det et netværksnavnerum, sætter den ene ende af et veth-par ind i det og giver navnerummet en adresse og en standardrute. Tunnelinterfacet, hvad det så end hedder, lever i værtens navnerum. Trafik inde i containeren kan ikke se det, og ingen klientindstilling ændrer det udefra.

To understøttede træk får dig ud af isoleringen. --network host placerer containeren inde i værtens navnerum, så den arver værtens ruter og dermed tunnelen. --network container:vpn deler et andet containers navnerum, og det er sådan de fleste sidecar-design sender en arbejdsbyrde gennem en VPN-container. Begge er eksplicitte valg; normalt er kun det ene af dem det, personen der udruller, mente.

Værtstilstand er ikke en gratis opgradering. Containeren holder op med at have sin egen adresse, portudgivelse holder op med at gælde, og en proces, der holder NET_ADMIN der, kan overskrive værtens routing. At acceptere det kan være det rigtige valg. At antage, at det allerede er slået til, er hvordan folk bruger en aften på at fejlfinde en tunnel, der aldrig var i stien.

Følg pakken af broen

En bro-container sender sin pakke til sin standardgateway, som er brointerfacet på værten. Værten videresender derefter pakken og oversætter i standardkonfigurationen kildeadressen til sin egen, før pakken forlader systemet. Det oversættelsestrin er det, der stille og roligt undergraver politikken.

Når pakken når tunnelens endepunkt, bærer den værtens adresse. Enhver regel, politikrute eller beslutning om delt tunnel, der er baseret på containerens oprindelige adresse, holder op med at matche, og to containere, der skal forlade systemet gennem forskellige udgange, kan ikke skelnes alene på kilden. Hvis du har brug for routing pr. container, skal beslutningen træffes før oversættelsen eller inde i et navnerum, du kontrollerer.

Docker vedligeholder selv disse regler gennem det firewall-backend, som daemonen blev konfigureret med. Håndskrevne regler uden for den understøttede hook til videresendt trafik, DOCKER-USER, kan blive omordnet eller droppet, når daemonen genstarter, eller værten opgraderes. Dockers dokumentation om pakkefiltrering viser kæderækkefølgen; den praktiske pointe er, at hver regel har brug for en ejer og en genindlæsningsvej, som du faktisk har testet.

Test de to systemer hver for sig

Bevis fra det ene navnerum siger intet om det andet. En anmodning, der køres inde i VPN-containeren, beviser, at tunnelen virker for den container. Det er ikke bevis om værten, og den samme kommando kørt fra en --network host-container er ikke bevis om broen.

# 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'

Gentag derefter testen inde i den rigtige applikationscontainer i stedet for et lignende image. Appen kan bære en ekstra rute, en proxy-miljøvariabel eller en anden resolver, og hver af dem ændrer svaret. Tjek navneopløsning og den anden adressefamilie hver gang: containere på brugerdefinerede broer opløses gennem Dockers indbyggede resolver på 127.0.0.11, og en IPv6-standardrute på broen kan føre trafik ud, mens du er travlt optaget af at teste en tunnel, der kun er IPv4.

Læs mønsteret, før du rører ved legitimationsoplysninger

Når værten virker, og containeren ikke gør, er årsagen næsten altid strukturel, og rotation af nøgler eller geninstallation af klienten spilder en eftermiddag. Sortér først symptomet, og rettelsen navngiver sig normalt selv.

Overlapningsrækken fortjener sin egen sætning. En VPN-profil, der skubber en rute til 172.17.0.0/16 eller til et 10.0.0.0/8, der tilfældigvis indeholder dit bro-præfiks, får tunnelen til at gøre krav på containersubnettet, og svar til oversatte adresser vil gå i den forkerte retning eller forsvinde. At omnummerere Docker-netværket er normalt renere end at samle undtagelser.

Gør dækningen eksplicit, og bryd den så med vilje

To designs holder ved gennemgang. Del VPN-containerens navnerum, og hver dækket arbejdsbyrde bruger én tunnel med én genstartsgrænse, hvilket er enkelt, indtil en tjeneste har brug for en anden udgang eller sin egen DNS-vej. Eller rut containerens netværk til en VPN-gateway på værten: videresendelse aktiveret, bro-præfikset peget mod tunnelen, returtrafik håndteret eksplicit. Det køber kontrol pr. netværk og koster dig et regelsæt, du skal vedligeholde gennem daemon- og klientopgraderinger.

Uanset hvad er den test, der betyder noget, fejlscenariet. Stop tunnelen med en containeranmodning undervejs, og se, hvor pakken går hen. Hvis den falder tilbage til den direkte vej, blev dækningen aldrig håndhævet, fordi en klients kill switch styrer klientens egen trafik og ikke videresendte pakker fra en bro. Genstart daemonen og værten bagefter, og bekræft resultatet en anden gang; det er det øjeblik, hvor håndskrevne regler forsvinder.

Før du kalder det færdigt, skal du bekræfte fire ting: tunnelinterfacet ligger i samme navnerum som trafikken, containertesten kørte inde i den rigtige container, navneopløsning og begge adressefamilier blev tjekket, og tunnel-fejltesten fejler stadig lukket. Skriv derefter firewall-backendet, klientversionen og ejeren af hver regel ned. Den registrering er det, der forhindrer den næste opgradering i at efterlade en udokumenteret blanding af gamle antagelser.