Kvifor ein Docker-container ikkje når vertar bak VPN-en

Ein container som ikkje når noko bak bedrifts-VPN-en, bur vanlegvis i eit anna nettverksnamnerom enn tunnelen. Ruter, DNS-tenarar og brannmurmerke til klienten på verten høyrer til stakken til verten; ein brocontainer har sin eigen. Denne eine fakta forklarar dei fleste rapportane som når eit plattformteam, og det er også grunnen til at «VPN-en er øydelagd» og «Docker går utanom VPN-en» kan vere feil samstundes. To svært ulike oppsett ligg bak eitt symptom, så finn ut kva du har før du endrar ei innstilling.

Finn ut kven sitt namnerom som eig tunnelen

På Docker Desktop for macOS eller Windows køyrer containarar inne i ein virtuell Linux-maskin. Ein VPN-klient installert på skrivebordet lagar ein tunnel i operativsystemet på skrivebordet, og den virtuelle maskina ser han aldri. Ingen containerkonfigurasjon rettar det, fordi grensesnittet containeren ville trengt ikkje finst i det heile i nettverksnamnerommet hans.

På ein Linux-vert bur tunnelen i namnerommet til verten, og brocontainerar når han vanlegvis gjennom rutetabellen til verten med kjelde-NAT brukt på veg ut. Når den vegen sviktar, er årsaka vanlegvis videresendingspolicy, omvendt sti-filtrering eller eit overlappande subnett snarare enn ei manglande rute. Stadfest kva av dei to verdene du er i før du les vidare:

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

Skilnaden mellom dei to rutetabellane er heile problemet på éin skjerm. Viss visninga til verten inneheld tunngrensesnittet og visninga til broa ikkje gjer det, ser du namneromsisolering, og alt anna er eit val om korleis ein kryssar henne.

Vertsnettverk er ein test, ikkje eit design

Å køyre ein container med vertsnettverk, som Docker dokumenterer som deling av nettverksnamnerommet til verten, får han til å arve tunngrensesnittet og rutene direkte. Viss den same førespurnaden då lukkast, er ruteteorien stadfesta, og feilen er namneromsisolering framfor legitimasjon, DNS eller ein tilgangsregel.

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

Hald det som diagnostikk. Vertsnettverk gjev avkall på portpublisering og det meste av isolasjonen du ønskte frå ein container, og på Docker Desktop tyder «host» den virtuelle maskina, ikkje skrivebordet, så suksess eller fiasko der kan villede deg viss du gløymer kva vert du vende deg til.

Ei tun-eining og privilegia som følgjer med

Ein VPN-klient inne i containeren treng ei tunneleining og løyve til å konfigurere henne. Den vanlege snarvegen er --privileged, som gjev kvar eining og lempar tryggingspolicyen i heile containeren. Det er langt meir enn denne oppgåva krev, og det er vanskeleg å forsvare i ein gjennomgang.

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

Den smalare forma kartlegg den eine einingsnoden og legg berre til nettverksadministrasjonskompetansen. Last inn modulen på verten først slik at noden finst. Viss containeren startar og klienten rapporterer at han ikkje kan opne tunneleininga, sjekk kartlegginga før du mistenkjer profilen, fordi den feilen vanlegvis er bokstaveleg.

Dette designet tyder også at klienten køyrer per container. Det er det rette svaret når kvar arbeidslast treng sin eigen tunnel, og det gale når du berre ville at tunnelen til verten skulle vere synleg, noko plattformteamet truleg antek at du gjorde.

Bro-NAT endrar kjelda VPN-en ser

Med standardbroa blir utgåande trafikk frå containeren omsett til adressa til verten. Bak ein VPN ser bedriftssida derfor tunneladressa til verten i staden for containeradressa, tilgangsreglar per kjelde oppfører seg som om verten sende førespurnaden, og to containerar blir uskilbare for VPN-tenaren.

macvlan eller ipvlan gjev i staden containeren ei LAN-adresse, noko som hjelper LAN-oppdaging og får containeren til å sjå ut som ein jamlike på segmentet. Det går også heilt utanom tunnelen til verten, så ein slik container når ikkje berre-VPN-prefiks med mindre VPN-en også er tilgjengeleg frå det LAN-et.

Begge formene er legitime; dei svarar på ulike krav. Viss kravet er «denne containeren må nå ei berre-VPN-teneste», vel du mellom ruting gjennom verten og å avslutte tunnelen inne i containeren. Skriv ned det valet før utrullinga, ikkje etter den første mislukka førespurnaden. Uansett kva du vel, registrer kjeldeadressa som den fjerne enden vil sjå, for det er den tilgangsreglane og loggane hans vil vise. Eit design som ikkje kan nemne den adressa, er ikkje ferdig.

DNS følgjer daemonen, ikkje tunnelen

Ein container får resolverkonfigurasjonen sin ved oppstart, kopiert frå daemonen eller frå imaget. Adresser som VPN-en dyttar etter tilkopling, kjem for seint for den kopien, og dei blir dytta til resolveren til verten i staden for inn i containeren.

Set resolveren eksplisitt for tenesta, eller peik han mot ein intern resolver som er tilgjengeleg gjennom tunnelen. Ein container som løyser eit privat namn til ei offentleg adresse, brukar vanlegvis ein offentleg resolver, ikkje ei broten rute, og rettinga høyrer heime i compose-fila eller daemonkonfigurasjonen.

Same resonnementet gjeld spørsmålet om utgangsadressa. Viss kvar container må framstå frå ei anna VPN-adresse, kan éin verknstunnel ikkje levere det fordi NAT slår dei saman til éi kjelde. Dei gangbare formene er ein klient i namnerommet til kvar container eller ein sidecar som eig tunnelen og deler stakken sin, og begge endrar korleis applikasjonen blir adressert.

Sjekkliste før du lukkar saka: identifiser namnerommet som eig tunnelen, prov vegen med vertsnettverk, kartlegg berre den naudsynte tun-eininga, hugs kjeldeadressa etter NAT, set resolveren eksplisitt og handsam utgangsadresser per container som eit arkitekturval framfor eit flagg.