Docker-portudgivelse kontra VPN: hvor svaret går hen

En udgivet container svarer fra sin egen adresse før omvendt NAT. To design kan holde det svar på den offentlige vej, med forskellige omkostninger.

Værten bliver ved med at svare på SSH, efter at en VPN med fuld tunnel er oppe, mens en Docker-udgivet tjeneste på samme maskine bliver tavs. Der er intet i vejen med listeneren: containeren kører, portmappingen findes, og pakken ankommer. Containeren har det godt, og anmodningen når den faktisk. Det, der er forskelligt, er, hvor svaret starter, når Linux vælger sin rute, og den forskel afgør, hvilken af de to designs nedenfor du har brug for.

Følg tuplen gennem destinations-NAT

Tag en vært på 192.0.2.10, der udgiver TCP 2222 til en container på 172.30.240.5:22. En anmodning fra 198.51.100.25 oversættes, før den når containeren, og containeren svarer som sig selv.

WAN request:      198.51.100.25 -> 192.0.2.10:2222
after DNAT:       198.51.100.25 -> 172.30.240.5:22
container reply:  172.30.240.5:22 -> 198.51.100.25

Ved værtens rutevalg bærer svaret stadig containerens kildeadresse. Den omvendte oversættelse gendanner den udgivne tuple senere, og det er derfor, pakken ser forkert ud netop i det øjeblik, ruten vælges.

Hvorfor en regel kun for værten overser det

En regel, der kun vælger WAN-tabellen for pakker fra 192.0.2.10, dækker værtens egne daemoner og overser dette videresendte svar helt. Kildeadressen i svaret er 172.30.240.5, ikke værten.

Overkorrektionen er at rute alt fra containeren gennem WAN, hvilket også fritager containerens urelaterede udgående forbindelser fra VPN'en. Det er en anden politik end den, der blev bedt om, og det overrasker normalt nogen senere.

Post-DNAT-matchning er et andet hook

Dockers dokumentation om firewalls bemærker, at almindelig brugerfiltrering ser destinationen efter DNAT, så at matche den udgivne port 2222 i en normal regel er ikke det samme som at matche containerport 22. Hvis den oprindelige tuple betyder noget, brug den understøttede oprindelige-destination-mekanisme i stedet for at gætte, hvilken port der er synlig.

Denne hook-forvirring producerer regler, der ser korrekte ud og aldrig matcher. Kontroller tællerne på selve reglen, før du omskriver politikken. En regel uden træffere fortæller dig, at den evalueres et sted, hvor pakken aldrig når hen.

Design A: bær beslutningen som forbindelsestilstand

Et forbindelsesmærke kan bære indgangsbeslutningen gennem oversættelsen, men det skal gendannes på pakken før det ruteopslag, der betyder noget. Faserne er:

  1. Reservér et mærkefelt og en regelprioritet, der ikke kolliderer med Docker, VPN'en eller en anden politiksejer.
  2. Identificér kun den tilsigtede nye WAN-forbindelse på et punkt før DNAT, hvor forbindelsessporing er tilgængelig.
  3. Registrér beslutningen på forbindelsesmærket uden at tvinge selve den oprindelige anmodning over i WAN-tabellen.
  4. I svarretningen skal du kun gendanne dine egne mærkebits på pakken før routing.
  5. Vælg en komplet WAN-tabel tidligt nok til, at en VPN-regel ikke kan vinde først.

Den tabel har brug for de rigtige tilsluttede ruter og gatewayen. Den har også brug for en defineret adfærd, når ruten mangler. Stille gennemfald i tunnelen er det værste udfald, fordi konfigurationen stadig ser ud til at virke. Fejl lukket i stedet og log det.

Design B: terminér på værten

En bevidst konfigureret frontend på værtssiden, såsom en TCP-proxy eller en omvendt proxy foran containeren, holder svaret med oprindelse i værtens adresse. Regler skrevet til værten opfører sig så som forventet, og containeren bliver på sit private netværk.

Prisen er endnu en bevægelig del med sin egen konfiguration, håndtering af kildeadresser og adgangskontrol. Det er normalt den enklere understøttede grænse, og det er ofte det rigtige svar, når rutepolitikken skulle vedligeholdes af én person, som måske forsvinder.

Verificér ændringen, ikke hensigten

Åbn en ny autoriseret forbindelse fra den offentlige side, og bekræft, at svaret forlader det tilsigtede interface. Kontroller derefter, at en urelateret anmodning startet af containeren stadig følger VPN'en.

Skyl ikke maskinens forbindelsestabel for at teste én regel: eksisterende poster beholder deres tidligere mapping, og skylningen ødelægger alt andet på værten. At udgive en port definerer tilgængelighed. Det definerer ikke svarvejen. Skriv det valgte design ned med dets tabelnavne, så den næste person ikke genopdager det under en hændelse.

Relaterede artikler