Docker-portpublisering og VPN-kilder: to treff du kan gå glipp av

Regelen sier at VPN-serverens adresse skal tillates mot den publiserte tjenesten, og likevel blir forbindelsen brutt. Det er et vanlig utfall, og det skyldes ikke en feil i Docker. To atskilte treff er gale: kilden du skrev er kanskje ikke kilden verten mottar, og porten du skrev er kanskje ikke porten filteret ser. Å rette begge krever at du ser på pakkens vei framfor tjenesteskissen.

Myten: tillat VPN-serveren, og jobben er gjort

En rutet VPN kan bevare klientens tunneladresse helt fram til Docker-verten. En gateway som utfører kildeoversettelse, kan bytte den adressa ut med sin egen. Begge løsningene er legitime, og de gir forskjellige kilder for samme brukerhandling.

Altså beskriver uttrykket VPN-serverens IP en forutsetning, ikke en observasjon. Inntil du vet hvilken av de to løsningene som er foran deg, er regelen bare en antakelse.

Kilde: klientpool eller oversatt gateway

Sjekk fire ting i rekkefølge. Først klientadressepoolen, for eksempel 10.90.0.0/24. Deretter om gatewayen oversetter denne poolen før den når verten. Så kilden verten faktisk observerer for én ny forbindelse. Til slutt om applikasjonsautentisering skiller enkeltbrukere, siden en delt oversatt adresse ikke kan gjøre det.

Bevares poolen, vil en regel som bare matcher gatewayens offentlige adresse, overse alle klienter. Oversetter gatewayen bevisst, slipper en tillatelse for den oversatte adressa inn alle brukere bak den, noe som kan være greit for en tjeneste med egen pålogging og ugreit for alt annet.

Port: DNAT forandrer nummeret du matcher

Ved vanlig publisering over Linux-bro med Docker iptables oversettes en vertsmapping fra 8443 til containerport 443 før videresendingsfilteret kjører. Pakken ankommer filteret med målport 443. En regel som matcher 8443 der, vil aldri slå til, selv om 8443 er det klienten skrev inn.

Den publiserte porten eksisterer fortsatt i forbindelsessporingen, og derfor kan den opprinnelige destinasjonen matches der når du virkelig har behov for det.

Avgjør hvilket nummer som uttrykker hensikten. Match containerporten etter DNAT når regelen beskytter tjenesten inne i containeren. Match den opprinnelige destinasjonen med conntrack-valget når regelen skal beskrive hva klienten ba om, og godta den ekstra kostnaden ved matching og den omhuen regelrekkefølgen krever.

Kjede: DOCKER-USER, ikke INPUT

Docker sin iptables-guide legger brukervideresendingspolicyen i DOCKER-USER-kjeden, som vurderes før Docker sine egne videresendingsregler. En regel som er kopiert fra en vertstjeneste til INPUT-kjeden, filtrerer trafikk adressert til verten, ikke trafikk som videresendes til en container. Den feilen gir en regel som ser riktig ut, men som ikke påvirker containerens vei i det hele tatt.

Hold kildeområdet, den effektive målporten, protokollen og inngangsgrensesnittet samlet i én og samme regel. En tillatelse kun basert på kilde for hver videresendt destinasjon er videre enn å tillate én publisert tjeneste.

Verifiser med nye forbindelser

Prøv begge retninger med nye forbindelser: én tillatt VPN-klient og én kilde som skal forbli avvist. Eksisterende forbindelsestilstand kan holde en økt levende etter at policyen er endret, så en gammel forbindelse beviser ingenting om den nye regelen. Sjekk så svarveien, fordi containeren fortsatt må rute tilbake til kilden den ser.

Kjedeordenen og portoversettelsesatferden bak disse sjekkene er dokumentert i Docker sin iptables-guide. Les den før du kopierer en oppskrift, og bekreft hvilken backend den installerte Docker bruker, siden nftables-backenden integrerer policyer på en annen måte.