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

Regelen sier at adressen til VPN-serveren skal tillates mot den publiserte tjenesten, og likevel brytes forbindelsen. Det resultatet er vanlig, og det er ikke en Docker-feil. To separate treff er feil: 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 i stedet for tjenestediagrammet.

Myten: tillat VPN-serveren, og du er ferdig

En rutet VPN kan bevare klientens tunneladresse helt til Docker-verten. En gateway som gjør kildeoversettelse, kan erstatte den adressen med sin egen. Begge designene er legitime, og de gir ulike kilder for samme brukerhandling.

Så uttrykket VPN-serverens IP beskriver en antakelse, ikke en observasjon. Til du vet hvilket av de to designene som ligger foran deg, er regelen en gjetning.

Kilde: klientpool eller oversatt gateway

Kontroller fire ting i rekkefølge. Først klientadressepoolen, for eksempel 10.90.0.0/24. For det andre om gatewayen oversetter den poolen før den når verten. For det tredje kilden verten faktisk observerer for én ny forbindelse. For det fjerde om applikasjonsautentisering skiller mellom enkeltbrukere, fordi en delt oversatt adresse ikke kan.

Hvis poolen bevares, bommer en regel som bare matcher gatewayens offentlige adresse, på hver klient. Hvis gatewayen oversetter med vilje, slipper tillatelse av den oversatte adressen inn hver bruker bak den, noe som kan være akseptabelt for en tjeneste med egen innlogging og uakseptabelt for alt annet.

Port: DNAT endrer nummeret du matcher

Ved vanlig Linux-bro-publisering med Docker iptables oversettes en vertsmapping fra 8443 til containerport 443 før videresendingsfilteret kjører. Pakken kommer til filteret med destinasjonsport 443. En regel som matcher 8443 på det tidspunktet, utløses aldri, selv om 8443 er det klienten skrev.

Den publiserte porten finnes fortsatt i forbindelsessporing, og derfor kan den opprinnelige destinasjonen matches der når du virkelig trenger det.

Bestem hvilket nummer som uttrykker hensikten. Match containerporten etter DNAT når regelen beskytter tjenesten inne i containeren. Match den opprinnelige destinasjonen med conntrack-alternativet når regelen må beskrive hva klienten ba om, og godta den ekstra matchekostnaden og omhuen med regelrekkefølgen som følger med.

Kjede: DOCKER-USER, ikke INPUT

Dockers iptables-veiledning plasserer brukervideresendingspolicyen i DOCKER-USER-kjeden, som evalueres før Dockers egne videresendingsregler. En regel kopiert fra en vertstjeneste til INPUT-kjeden filtrerer trafikk rettet mot verten, ikke trafikk videresendt til en container. Den feilen gir en regel som ser riktig ut og ikke har noen effekt på containerens vei.

Hold kildeområdet, den effektive destinasjonsporten, protokollen og inngangsgrensesnittet sammen i samme regel. En tillatelse kun på kilde for hver videresendt destinasjon er bredere enn å tillate én publisert tjeneste.

Bekreft med ferske forbindelser

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

Dockers iptables-veiledning dokumenterer kjedeordenen og portoversettelsesatferden bak disse kontrollene. Les den før du kopierer en oppskrift, og bekreft hvilken backend den installerte Docker bruker, fordi nftables-backenden integrerer policy annerledes.