Docker-portudgivelse og VPN-kilder: to match du går glip af

Reglen siger tillad VPN-serverens adresse til den udgivne tjeneste, og forbindelsen afvises alligevel. Det resultat er almindeligt, og det er ikke en Docker-fejl. To separate match er forkerte: den kilde, du skrev, er måske ikke den kilde, værten modtager, og den port, du skrev, er måske ikke den port, filteret ser. At rette begge kræver, at du ser på pakkens vej i stedet for tjenestens diagram.

Myten: tillad VPN-serveren, og du er færdig

En rutet VPN kan bevare klientens tunneladresse hele vejen til Docker-værten. En gateway, der udfører kildeoversættelse, kan erstatte den adresse med sin egen. Begge design er legitime, og de giver forskellige kilder til samme brugerhandling.

Så udtrykket VPN-serverens IP beskriver en antagelse, ikke en observation. Indtil du ved, hvilket af de to design der er foran dig, er reglen et gæt.

Kilde: klientpulje eller oversat gateway

Kontroller fire ting i rækkefølge. For det første klientadressepuljen, for eksempel 10.90.0.0/24. For det andet om gatewayen oversætter den pulje, før den når værten. For det tredje den kilde, værten faktisk ser for én ny forbindelse. For det fjerde om applikationsgodkendelse skelner mellem enkelte brugere, fordi en delt oversat adresse ikke kan.

Hvis puljen bevares, rammer en regel, der kun matcher gatewayens offentlige adresse, forbi hver klient. Hvis gatewayen oversætter med vilje, lukker tilladelse af den oversatte adresse hver bruger bag den ind, hvilket kan være acceptabelt for en tjeneste med sit eget login og uacceptabelt for alt andet.

Port: DNAT ændrer det nummer, du matcher

Ved almindelig Linux-bro-udgivelse med Docker iptables oversættes en værtsmapping fra 8443 til containerport 443, før videresendelsesfilteret kører. Pakken ankommer til filteret med destinationsport 443. En regel, der matcher 8443 på det tidspunkt, udløses aldrig, selvom 8443 er det, klienten skrev.

Den udgivne port findes stadig i forbindelsessporing, og derfor kan den oprindelige destination matches der, når du virkelig har brug for det.

Beslut, hvilket nummer der udtrykker hensigten. Match containerporten efter DNAT, når reglen beskytter tjenesten inde i containeren. Match den oprindelige destination med conntrack-indstillingen, når reglen skal beskrive, hvad klienten bad om, og accepter den ekstra matchningsomkostning og omhu med regelrækkefølgen, der følger med.

Kæde: DOCKER-USER, ikke INPUT

Dockers iptables-guide placerer brugerens videresendelsespolitik i DOCKER-USER-kæden, som evalueres før Dockers egne videresendelsesregler. En regel, der er kopieret fra en værttjeneste til INPUT-kæden, filtrerer trafik rettet mod værten, ikke trafik videresendt til en container. Den fejl giver en regel, der ser rigtig ud og ikke har nogen effekt på containerens vej.

Hold kildeområdet, den effektive destinationsport, protokollen og indgangsgrænsefladen sammen i samme regel. En tilladelse kun på kilde for hver videresendt destination er bredere end at tillade én udgivet tjeneste.

Bekræft med friske forbindelser

Test begge retninger med nye forbindelser: én tilladt VPN-klient og én kilde, der skal forblive afvist. Eksisterende forbindelsestilstand kan holde en session i live, efter politikken er ændret, så en gammel forbindelse beviser intet om den nye regel. Derefter kontroller svarvejen, fordi containeren stadig skal rute tilbage til den kilde, den ser.

Dockers iptables-guide beskriver kæderækkefølgen og portoversættelsesadfærden bag disse kontroller. Læs den, før du kopierer en opskrift, og bekræft, hvilken backend den installerede Docker bruger, fordi nftables-backenden integrerer politik anderledes.