Docker: rut ein container gjennom ein VPN og hald ein annan direkte

Éin vert, to arbeidslaster og eit krav som skil dei: ein nedlastingsklient som må ut gjennom ein kommersiell VPN, og eit administrasjonsgrensesnitt som må halde fram med å bruke tilkoplinga til verten. Å installere VPN-klienten på verten bryt kravet med ein gong, fordi begge arbeidslastene då deler éin utgang. Mønsteret som faktisk fungerer, er å flytte tunnelen inn i sin eigen container og la berre arbeidslastene som treng han bli med i nettverksnamnerommet til den containeren. Alt anna held den vanlege Docker-vegen, og detaljane som følgjer er konsekvensar av kven som eig namnerommet.

Kvifor eit delt namnerom endrar reglane

Ein container som blir med i namnerommet til ein annan, får ikkje sin eigen nettverksstakk. Han ser dei same grensesnitta, den same rutetabellen og den same loopbacken som containeren han blei med i, og det er nettopp difor mønsteret er nyttig: arbeidslasta slår opp og koplar til som normalt, og tunnelen under fangar trafikken utan at applikasjonen veit det. Prisen er at kvar nettverksinnstilling no har éin eigar, og containeren som blir med er ikkje den eigaren.

Den eigarregelen svarer på dei fleste konfigurasjonsspørsmåla før dei blir stilte. Viss ei innstilling lever i nettverksstakken, høyrer ho til sidecar-containeren. Viss ho skildrar prosessen, blir ho hjå arbeidslasta.

Loopback er den delen som overraskar folk. Inne i containeren som blir med, blir localhost slått opp til loopbacken til sidecar-containeren, ikkje til ein privat ein av sin eigen, så ei teneste som bind til 127.0.0.1 og ventar isolasjon, deler no den adressa med tunnelcontaineren.

Publiser portar på containeren som eig namnerommet

Porttilordninga høyrer til eigaren av namnerommet, sjølv når den lyttande prosessen køyrer i den andre containeren. Erklær tilordninga på sidecar-containeren, og lat arbeidslasta halde si eiga prosesskonfigurasjon urørt. Ei tilordning på tenesta som blir med, kan ikkje tre i kraft, anten motoren avviser ho eller stille ignorerer ho avhengig av korleis containeren blir starta, og difor forsvinn eit grensesnitt som var tilgjengeleg for eit augeblikk sidan, så snart mønsteret blir brukt.

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 blokka som tre avgjerder i staden for tre tenester. Sidecar-containeren eig tunnelen og den publiserte porten; klienten som blir med, erklærer ingen nettverk i det heile; den direkte klienten held ei eiga tilordning på standardnettverket. Evna NET_ADMIN er det som lèt sidecar-containeren opprette grensesnitt og endre ruter, og det er grunnen til at denne containeren treng fleire rettar enn arbeidslastene han tenar.

Tenesta som blir verande direkte, held sitt eige nettverk

Arbeidslasta som ikkje skal gå gjennom tunnelen, held standardbrua eller eit eige brukardefinert nettverk, med sin eigen publiserte port og sin eigen utgang. Det er freistande å kopie ho til nettverket til sidecar-containeren slik at dei to containerane kan snakke saman ved namn, men det eine trinnet flyttar stille trafikken hennar inn i tunnelen. Viss dei må nå kvarandre, bygg eit eige brukardefinert nettverk, kopie begge til det, og lat sidecar-containeren vere den einaste vegen ut.

Hald dei to spørsmåla frå kvarandre: kva containerar som kan nå kvarandre, og kven som går ut kvar. Å slå dei saman er den vanlegaste måten dette designet blir ein VPN for heile verten igjen.

Ein feilmatrise for den første timen

Dei fleste første forsøk feilar på ein av fire måtar, og kvar har ei ulik årsak. Kontroller dei i denne rekkjefølgja, fordi dei to første forklarer nesten kvar rapport.

Den fjerde rada er den folk feildiagnostiserer som ein programfeil. Ein sjekk skriven mot eigen loopback til arbeidslasta testar no tunnelcontaineren, så han feilar anten eller rapporterer ei heilt feil teneste.

Når eitt enkelt vertsnamn treng tunnelen

Nokre gonger er ein full tunnel for mykje: eitt internt namn må gå gjennom ein bedrifts-VPN medan ein lokal socket eller displaytilkopling held fram med å verke. Ein full tunnel inne i containeren bryt den vegen og alt som er adressert til verten, så rut berre prefikset som treng det. Ei split-routing-innpakning rundt klienten gjer det, sender det namngjevne vertsnamnet gjennom tunnelen og lèt den førre ruta vere urørt for alt anna.

Vel dette når du berre treng å nå éi teneste og ikkje prøver å flytte all trafikken i containeren. Det er eit anna verktøy enn sidecar-containeren, og det svarer på eit anna spørsmål.

Verifiser, og gjer det så motstandsdyktig mot omstart

Spør kvar container kva adresse han ser ut til å kome frå. Den tunnelierte bør skrive ut adressa til leverandøren, og den direkte bør skrive ut utgangen til verten. Identiske svar betyr at den direkte tenesta arva feil namnerom, eller at ein VPN på vertsnivå framleis fangar alt, og dei to rettingane er ulike. Køyr kontrollen igjen etter kvar compose-endring, fordi éin kopiert tenesteblokk er nok til å føre problemet tilbake.

Tre ting pleier å gå i stykke seinare. DNS følgjer eigaren av namnerommet, så innstillingar for resolver og søkedomene høyrer til sidecar-containeren og ikkje verten. Ein VPN med portvideresending endrar den lyttande porten sin ved gjenoppkopling, så den videresende porten til leverandøren og den lyttande porten på containersida må skrivast tilbake i klientkonfigurasjonen eller porttilordninga, vanlegvis av ein liten oppdaterar som les API-et til leverandøren. Og ein kvar sjekk som er skriven mot localhost, spør no tunnelcontaineren i staden for arbeidslasta.

Skriv ned mønsteret, inkludert kven container som eig namnerommet og kva portar som høyrer til det. Den neste personen vil leggje til ei teneste, kopiere feil blokk og gjenskape den første feilen i denne artikkelen.