Docker-containeres trafikk omgår verts-VPN-en: slik sjekker du det

Nettleseren på verten viser VPN-ens utgangsadresse, containeren rapporterer hjemmeforbindelsen din, og noen kaller det en lekkasje. Ingenting lakk. En vertstunnel er en samling grensesnitt, ruter og regler som hører til vertens nettverksnavnerom, og en container på en bro er et annet navnerom med sin egen standardrute. Jeg har sittet på en Compose-stack der VPN-klienten hadde vært tilkoblet i ukevis og ikke én containerpakke noen gang hadde kommet inn i den.

Sjekk navnerommet før ikonet i systemkurven

Navnerom er hele argumentet. Når Docker starter en container på et bronettverk, oppretter det et nettverksnavnerom, fester den ene enden av et veth-par inni det og gir navnerommet en adresse og en standardrute. Tunnelgrensesnittet, hva det enn heter, lever i vertens navnerom. Trafikk inne i containeren kan ikke se det, og ingen klientinnstilling endrer det utenfra.

To støttede grep får deg ut av isolasjonen. --network host plasserer containeren i vertens navnerom, slik at den arver vertens ruter og dermed tunnelen. --network container:vpn deler et annet navnerom, og slik sender de fleste sidecar-design en arbeidsbelastning gjennom en VPN-container. Begge er eksplisitte valg; som regel er bare ett av dem det personen som ruller ut mente.

Vertmodus er ikke en gratis oppgradering. Containeren slutter å ha sin egen adresse, portpublisering slutter å gjelde, og en prosess som holder NET_ADMIN der kan skrive om vertens ruting. Å akseptere det kan være riktig. Å anta at det allerede er på, er hvordan folk bruker en kveld på å feilsøke en tunnel som aldri var i banen.

Følg pakken ut av broen

En brocontainer sender pakken sin til standardgatewayen, som er brogrensesnittet på verten. Verten videresender deretter pakken og oversetter i standardoppsettet kildeadressen til sin egen før pakken forlater maskinen. Det er dette oversettelsestrinnet som stille undergraver policyen.

Når pakken når tunnelens endepunkt, bærer den vertens adresse. Enhver regel, policyrute eller beslutning om delt tunnel som er basert på containerens opprinnelige adresse, slutter å matche, og to containere som skal ut gjennom ulike utganger, kan ikke skilles bare på kilden. Hvis du trenger ruting per container, må beslutningen tas før oversettelsen eller inne i et navnerom du kontrollerer.

Docker vedlikeholder disse reglene selv, gjennom hvilken som helst brannmur-backend daemonen ble konfigurert med. Håndskrevne regler utenfor den støttede kroken for videresendt trafikk, DOCKER-USER, kan bli omorganisert eller droppet når daemonen starter på nytt eller verten oppgraderes. Dockers dokumentasjon om pakkefiltrering viser rekkefølgen på kjedene; det praktiske poenget er at hver regel trenger en eier og en omlastingsvei du faktisk har testet.

Test de to systemene hver for seg

Bevis fra det ene navnerommet sier ingenting om det andre. En forespørsel som kjøres inne i VPN-containeren, beviser at tunnelen virker for den containeren. Det er ikke bevis om verten, og samme kommando kjø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'

Gjenta så testen inne i den virkelige applikasjonscontaineren i stedet for et lignende image. Appen kan bære en ekstra rute, en proxy-miljøvariabel eller en annen resolver, og hver av disse endrer svaret. Sjekk navneoppslag og den andre adressefamilien hver gang: containere på brukerdefinerte broer løses gjennom Dockers innebygde resolver på 127.0.0.11, og en IPv6-standardrute på broen kan føre trafikk ut mens du er opptatt med å teste en tunnel som bare er IPv4.

Les mønsteret før du rører ved påloggingsinformasjon

Når verten virker og containeren ikke, er årsaken nesten alltid strukturell, og å rotere nøkler eller installere klienten på nytt koster en ettermiddag. Sorter symptomet først, og rettelsen navngir seg vanligvis selv.

Overlappsraden fortjener sin egen setning. En VPN-profil som skyver en rute for 172.17.0.0/16, eller for et 10.0.0.0/8 som tilfeldigvis inneholder broens prefiks, får tunnelen til å kreve containersubnettet, og svar til oversatte adresser går i feil retning eller forsvinner. Å nummerere Docker-nettet på nytt er vanligvis renere enn å samle unntak.

Gjør dekningen eksplisitt, og bryt den så med vilje

To design holder gjennom en gjennomgang. Del VPN-containerens navnerom, og hver dekket arbeidsbelastning bruker én tunnel med én omstartgrense, noe som er enkelt helt til én tjeneste trenger en annen utgang eller sin egen DNS-vei. Eller rut containernettet til en VPN-gateway på verten: videresending slått på, broens prefiks pekt mot tunnelen, returtrafikk håndtert eksplisitt. Det kjøper kontroll per nett og koster deg et regelsett du må vedlikeholde gjennom daemon- og klientoppgraderinger.

Uansett er testen som betyr noe feiltilfellet. Stopp tunnelen med en containerforespørsel underveis og se hvor pakken går. Hvis den faller tilbake til den direkte veien, ble dekningen aldri håndhevet, fordi en klients kill switch styrer klientens egen trafikk og ikke videresendte pakker fra en bro. Start deretter daemonen og verten på nytt og bekreft resultatet en gang til; det er øyeblikket de håndskrevne reglene forsvinner.

Før du kaller det ferdig, bekreft fire ting: tunnelgrensesnittet ligger i samme navnerom som trafikken, containertesten gikk inne i den virkelige containeren, navneoppslag og begge adressefamiliene ble sjekket, og tunnelfeiltesten feiler fortsatt lukket. Skriv så ned brannmur-backenden, klientversjonen og eieren av hver regel. Den registreringen er det som hindrer den neste oppgraderingen i å etterlate en udokumentert blanding av gamle antakelser.