Docker-portpublisering og VPN-kjelder: to treff du går glipp av

Regelen seier at adressa til VPN-serveren skal tillatast mot den publiserte tenesta, og likevel blir sambandet brote. Det resultatet er vanleg, og det er ikkje ein Docker-feil. To separate treff er feil: kjelda du skreiv, er kanskje ikkje kjelda verten tek imot, og porten du skreiv, er kanskje ikkje porten filteret ser. Å rette båe krev at du ser på vegen til pakken i staden for tenestediagrammet.

Myten: tillat VPN-serveren, og du er ferdig

Ein ruta VPN kan halde på tunneladressa til klienten heilt til Docker-verten. Ein gateway som gjer kjeldeomsetjing, kan bytte ut den adressa med si eiga. Båe designa er legitime, og dei gir ulike kjelder for same brukarhandling.

Så uttrykket IP-en til VPN-serveren skildrar ei føresetnad, ikkje ei observasjon. Til du veit kva av dei to designa som ligg framfor deg, er regelen eit gjet.

Kjelde: klientpool eller omsett gateway

Kontroller fire ting i rekkjefølgje. Fyrst klientadressepoolen, til dømes 10.90.0.0/24. For det andre om gatewayen omset den poolen før han når verten. For det tredje kjelda verten faktisk observerer for éin ny samband. For det fjerde om applikasjonsautentisering skil mellom einskildbrukarar, fordi ei delt omsett adresse ikkje kan.

Viss poolen blir halden på, bommar ein regel som berre matchar den offentlege adressa til gatewayen, på kvar klient. Viss gatewayen omset med vilje, slepp tillating av den omsette adressa inn kvar brukar bak henne, noko som kan vere akseptabelt for ei teneste med eigen innlogging og uakseptabelt for alt anna.

Port: DNAT endrar nummeret du matchar

Ved vanleg Linux-bru-publisering med Docker iptables blir ei vertsmapping frå 8443 til containerport 443 omsett før videresendingsfilteret køyrer. Pakken kjem til filteret med målport 443. Ein regel som matchar 8443 på det tidspunktet, blir aldri utløyst, sjølv om 8443 er det klienten skreiv.

Den publiserte porten finst framleis i sambandssporing, og difor kan den opphavlege destinasjonen matchast der når du verkeleg treng det.

Avgjer kva nummer som uttrykkjer føremålet. Match containerporten etter DNAT når regelen vernar tenesta inne i containeren. Match den opphavlege destinasjonen med conntrack-valet når regelen må skildre kva klienten bad om, og godta den ekstra matchkostnaden og omhugna med regelrekkjefølgja som følgjer med.

Kjede: DOCKER-USER, ikkje INPUT

Iptables-rettleiinga til Docker plasserer videresendingspolicyen for brukarar i DOCKER-USER-kjeda, som blir vurdert før Docker sine eigne videresendingsreglar. Ein regel kopiert frå ei vertsteneste til INPUT-kjeda filtrerer trafikk retta mot verten, ikkje trafikk videresend til ein container. Den feilen gir ein regel som ser rett ut og ikkje har nokon verknad på vegen til containeren.

Hald kjeldeområdet, den effektive målporten, protokollen og inngangsgrensesnittet saman i same regel. Ei tillating berre på kjelde for kvar videresend destinasjon er breiare enn å tillate éi publisert teneste.

Stadfest med ferske samband

Test båe retningar med nye samband: éin tillaten VPN-klient og éi kjelde som skal halde fram med å vere avvist. Eksisterande sambandstilstand kan halde ein sesjon i live etter at policyen er endra, så eit gammalt samband provar ingenting om den nye regelen. Deretter kontroller svarvegen, fordi containeren må framleis rute tilbake til kjelda han ser.

Kjedeordenen og portomsetjingsåtferda bak desse kontrollane er dokumentert i iptables-rettleiinga til Docker. Les henne før du kopierer ei oppskrift, og stadfest kva backend den installerte Docker brukar, fordi nftables-backenden integrerer policy annleis.