Trafikken til Docker-containerar omgår verts-VPN-en: slik sjekkar du det

Nettlesaren på verten viser utgangsadressa til VPN-en, containeren rapporterer heimekoplinga di, og nokon kallar det ein lekkasje. Ingenting lakk. Ein vertstunnel er ei samling grensesnitt, ruter og reglar som høyrer til nettverksnamnerommet til verten, og ein container på ei bru er eit anna namnerom med si eiga standardrute. Eg har sete på ein Compose-stack der VPN-klienten hadde vore tilkopla i veker og ikkje éin containerpakke nokon gong hadde kome inn i han.

Sjekk namnerommet før ikonet i systemkurven

Namnerom er heile argumentet. Når Docker startar ein container på eit brunettverk, lagar det eit nettverksnamnerom, festar den eine enden av eit veth-par inni det og gjev namnerommet ei adresse og ei standardrute. Tunnelgrensesnittet, kva det no heiter, lever i namnerommet til verten. Trafikk inne i containeren kan ikkje sjå det, og inga klientinnstilling endrar det utanfrå.

To støtta grep får deg ut av isolasjonen. --network host plasserer containeren i namnerommet til verten, slik at han arvar rutene til verten og dermed tunnelen. --network container:vpn deler eit anna namnerom, og slik sender dei fleste sidecar-design ei arbeidslast gjennom ein VPN-container. Begge er eksplisitte val; som regel er berre eitt av dei det personen som rullar ut meinte.

Vertmodus er ikkje ein gratis oppgradering. Containeren sluttar å ha si eiga adresse, portpublisering sluttar å gjelde, og ein prosess som held NET_ADMIN der kan skrive om rutinga til verten. Å godta det kan vere rett. Å gå ut frå at det alt er på, er korleis folk brukar ein kveld på å feilsøkje ein tunnel som aldri var i banen.

Følg pakken ut av brua

Ein brucontainer sender pakken sin til standardgatewayen, som er bruegrensesnittet på verten. Verten videresender så pakken og set i standardoppsettet kjeldeadressa om til si eiga før pakken forlèt maskina. Det er dette omsetjingstrinnet som stille undergrev policyen.

Når pakken når endepunktet til tunnelen, ber han adressa til verten. Kvar regel, policyrute eller avgjerd om delt tunnel som byggjer på den opphavlege adressa til containeren, sluttar å passe, og to containerar som skal ut gjennom ulike utgangar, kan ikkje skiljast berre på kjelda. Viss du treng ruting per container, må avgjerda takast før omsetjinga eller inne i eit namnerom du kontrollerer.

Docker vedlikeheld desse reglane sjølv, gjennom kva som helst brannmur-backend daemonen vart konfigurert med. Handskrivne reglar utanfor den støtta kroken for videresend trafikk, DOCKER-USER, kan bli omorganiserte eller droppa når daemonen startar på nytt eller verten vert oppgradert. Dokumentasjonen til Docker om pakkefiltrering viser rekkjefølgja på kjedene; det praktiske poenget er at kvar regel treng ein eigar og ein omlastingsveg du faktisk har testa.

Test dei to systema kvar for seg

Bevis frå det eine namnerommet seier ingenting om det andre. Ein førespurnad som køyrer inne i VPN-containeren, beviser at tunnelen verkar for den containeren. Det er ikkje bevis om verten, og same kommandoen køyrd frå ein --network host-container er ikkje bevis om brua.

# 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 verkelege applikasjonscontaineren i staden for eit liknande image. Appen kan bere ei ekstra rute, ein proxy-miljøvariabel eller ein annan resolver, og kvar av desse endrar svaret. Sjekk namneoppslag og den andre adressefamilien kvar gong: containerar på bruardefinerte bruer vert løyste gjennom den innebygde resolveren til Docker på 127.0.0.11, og ei IPv6-standardrute på brua kan føre trafikk ut medan du er oppteken med å teste ein tunnel som berre er IPv4.

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

Når verten verkar og containeren ikkje, er årsaka nesten alltid strukturell, og å rotere nøklar eller installere klienten på nytt kostar ein ettermiddag. Sorter symptomet først, og rettinga namngjev seg vanlegvis sjølv.

Overlappsrada fortener si eiga setning. Ein VPN-profil som skyt ei rute for 172.17.0.0/16, eller for eit 10.0.0.0/8 som tilfeldigvis inneheld prefikset til brua, får tunnelen til å krevje containersubnettet, og svar til omsette adresser går i feil retning eller forsvinn. Å nummerere Docker-nettet på nytt er vanlegvis reinare enn å samle unntak.

Gjer dekninga eksplisitt, og bryt ho så med vilje

To design held gjennom ein gjennomgang. Del namnerommet til VPN-containeren, og kvar dekt arbeidslast brukar éin tunnel med éin omstartgrense, noko som er enkelt heilt til éin teneste treng ein annan utgang eller sin eigen DNS-veg. Eller rut containernettet til ein VPN-gateway på verten: videresending slått på, prefikset til brua peika mot tunnelen, returtrafikk handtert eksplisitt. Det kjøper kontroll per nett og kostar deg eit regelsett du må vedlikehalde gjennom daemon- og klientoppgraderingar.

Uansett er testen som betyr noko feiltilfellet. Stopp tunnelen med ein containerførespurnad undervegs og sjå kvar pakken går. Viss han fell tilbake til den direkte vegen, vart dekninga aldri handheva, fordi ein kill switch hjå klienten styrer klienten sin eigen trafikk og ikkje videresende pakkar frå ei bru. Start så daemonen og verten på nytt og stadfest resultatet ein gong til; det er augneblinken dei handskrivne reglane forsvinn.

Før du kallar det ferdig, stadfest fire ting: tunnelgrensesnittet ligg i same namnerom som trafikken, containertesten gjekk inne i den verkelege containeren, namneoppslag og begge adressefamiliane vart sjekka, og tunnelfeiltesten feilar framleis lukka. Skriv så ned brannmur-backenden, klientversjonen og eigaren av kvar regel. Den registreringa er det som hindrar den neste oppgraderinga i å etterlate ei udokumentert blanding av gamle føresetnader.