Docker: ruter én container gjennom en VPN og holder en annen direkte

Én vert, to arbeidslaster og et krav som skiller dem: en nedlastingsklient som må ut gjennom en kommersiell VPN, og et administrasjonsgrensesnitt som må fortsette å bruke vertens tilkobling. Å installere VPN-klienten på verten bryter kravet med en gang, fordi begge arbeidslastene da deler én utgang. Mønsteret som faktisk fungerer, er å flytte tunnelen inn i sin egen container og la bare arbeidslastene som trenger den bli med i den containerens nettverksnavnerom. Alt annet beholder den vanlige Docker-veien, og detaljene som følger er konsekvenser av hvem som eier navnerommet.

Hvorfor et delt navnerom endrer reglene

En container som blir med i en annens navnerom, får ikke sin egen nettverksstakk. Den ser de samme grensesnittene, den samme rutetabellen og den samme loopbacken som containeren den ble med i, og det er nettopp derfor mønsteret er nyttig: arbeidslasten slår opp og kobler til som normalt, og tunnelen under fanger trafikken uten at applikasjonen vet det. Prisen er at hver nettverksinnstilling nå har én eier, og containeren som blir med er ikke den eieren.

Den eierregelen svarer på de fleste konfigurasjonsspørsmål før de stilles. Hvis en innstilling lever i nettverksstakken, hører den til sidecar-containeren. Hvis den beskriver prosessen, blir den hos arbeidslasten.

Loopback er den delen som overrasker folk. Inne i containeren som blir med, blir localhost slått opp til sidecar-containerens loopback, ikke til en privat en av sin egen, så en tjeneste som binder til 127.0.0.1 og forventer isolasjon, deler nå den adressen med tunnelcontaineren.

Publiser porter på containeren som eier navnerommet

Porttilordningen tilhører eieren av navnerommet, selv når den lyttende prosessen kjører i den andre containeren. Erklær tilordningen på sidecar-containeren, og la arbeidslasten beholde sin egen prosesskonfigurasjon urørt. En tilordning på tjenesten som blir med, kan ikke tre i kraft, enten motoren avviser den eller stille ignorerer den avhengig av hvordan containeren startes, og derfor forsvinner et grensesnitt som var tilgjengelig for et øyeblikk siden, så snart mønsteret brukes.

services:
  gluetun:
    image: qmcgaw/gluetun
    cap_add: [NET_ADMIN]
    ports: ["8080:8080"]
  client-vpn:
    image: example/client
    network_mode: "service:gluetun"
  client-direct:
    image: example/client
    ports: ["8081:8080"]

Les den blokken som tre beslutninger i stedet for tre tjenester. Sidecar-containeren eier tunnelen og den publiserte porten; klienten som blir med, erklærer ingen nettverk i det hele tatt; den direkte klienten beholder en egen tilordning på standardnettverket. Evnen NET_ADMIN er det som lar sidecar-containeren opprette grensesnitt og endre ruter, og det er grunnen til at denne containeren trenger flere rettigheter enn arbeidslastene den betjener.

Tjenesten som forblir direkte, beholder sitt eget nettverk

Arbeidslasten som ikke skal gå gjennom tunnelen, beholder standardbroen eller et eget brukerdefinert nettverk, med sin egen publiserte port og sin egen utgang. Det er fristende å koble den til sidecar-containerens nettverk slik at de to containerne kan snakke sammen ved navn, men det ene trinnet flytter stille trafikken dens inn i tunnelen. Hvis de må nå hverandre, bygg et eget brukerdefinert nettverk, koble begge til det, og la sidecar-containeren være den eneste veien ut.

Hold de to spørsmålene fra hverandre: hvilke containere som kan nå hverandre, og hvilken som går ut hvor. Å slå dem sammen er den vanligste måten dette designet blir en VPN for hele verten igjen.

En feilmatrise for den første timen

De fleste første forsøk feiler på en av fire måter, og hver har en ulik årsak. Kontroller dem i denne rekkefølgen, fordi de to første forklarer nesten hver rapport.

Den fjerde raden er den folk feildiagnostiserer som en programfeil. En sjekk skrevet mot arbeidslastens egen loopback tester nå tunnelcontaineren, så den feiler enten eller rapporterer en helt feil tjeneste.

Når ett enkelt vertsnavn trenger tunnelen

Noen ganger er en full tunnel for mye: ett internt navn må gå gjennom en bedrifts-VPN mens en lokal socket eller displaytilkobling fortsetter å virke. En full tunnel inne i containeren bryter den veien og alt som er adressert til verten, så rut bare prefikset som trenger det. En split-routing-innpakning rundt klienten gjør det, sender det navngitte vertsnavnet gjennom tunnelen og lar den forrige ruten være urørt for alt annet.

Velg dette når du bare trenger å nå én tjeneste og ikke prøver å flytte all trafikken i containeren. Det er et annet verktøy enn sidecar-containeren, og det svarer på et annet spørsmål.

Verifiser, og gjør det så motstandsdyktig mot omstart

Spør hver container hvilken adresse den ser ut til å komme fra. Den tunnelierte bør skrive ut leverandørens adresse, og den direkte bør skrive ut vertens utgang. Identiske svar betyr at den direkte tjenesten arvet feil navnerom, eller at en VPN på vertsnivå fortsatt fanger alt, og de to rettelsene er forskjellige. Kjør kontrollen igjen etter hver compose-endring, fordi én kopiert tjenesteblokk er nok til å gjeninnføre problemet.

Tre ting pleier å gå i stykker senere. DNS følger navnerommets eier, så innstillinger for resolver og søkedomene hører til sidecar-containeren og ikke verten. En VPN med portvideresending endrer den lyttende porten sin ved gjenoppkobling, så leverandørens videresendte port og containerens lyttende port må skrives tilbake i klientkonfigurasjonen eller porttilordningen, vanligvis av en liten oppdaterer som leser leverandørens API. Og enhver sjekk som er skrevet mot localhost, spør nå tunnelcontaineren i stedet for arbeidslasten.

Skriv ned mønsteret, inkludert hvilken container som eier navnerommet og hvilke porter som hører til det. Den neste personen vil legge til en tjeneste, kopiere feil blokk og gjenskape den første feilen i denne artikkelen.