Docker-portpublicering och VPN-källor: två träffar du missar

Regeln säger tillåt VPN-serverns adress till den publicerade tjänsten, och anslutningen bryts ändå. Det resultatet är vanligt, och det är inte ett Docker-fel. Två separata träffar är fel: källan du skrev är kanske inte den källa som värden tar emot, och porten du skrev är kanske inte den port som filtret ser. Att rätta båda kräver att du tittar på paketets väg i stället för tjänstediagrammet.

Myten: tillåt VPN-servern och du är klar

Ett routat VPN kan bevara klientens tunneladress ända fram till Docker-värden. En gateway som utför källöversättning kan ersätta den adressen med sin egen. Båda lösningarna är legitima, och de ger olika källor för samma användaråtgärd.

Alltså beskriver uttrycket VPN-serverns IP ett antagande, inte en observation. Tills du vet vilken av de två lösningarna som ligger framför dig är regeln en gissning.

Källa: klientpool eller översatt gateway

Kontrollera fyra saker i ordning. Först klientadresspoolen, till exempel 10.90.0.0/24. För det andra om gatewayen översätter den poolen innan den når värden. För det tredje vilken källa värden faktiskt observerar för en ny anslutning. För det fjärde om applikationsautentisering skiljer mellan enskilda användare, eftersom en delad översatt adress inte kan.

Om poolen bevaras missar en regel som bara matchar gatewayens offentliga adress varje klient. Om gatewayen översätter med avsikt släpper en tillåtelse för den översatta adressen in varje användare bakom den, vilket kan vara acceptabelt för en tjänst med egen inloggning och oacceptabelt för allt annat.

Port: DNAT ändrar numret du matchar

Vid vanlig Linux-bryggpublicering med Docker iptables översätts en värdmappning från 8443 till containerport 443 innan vidarebefordringsfiltret körs. Paketet når filtret med destinationsport 443. En regel som matchar 8443 vid den punkten utlöses aldrig, även om 8443 är det klienten skrev.

Den publicerade porten finns fortfarande kvar i anslutningsspårningen, därför kan den ursprungliga destinationen matchas där när du verkligen behöver det.

Bestäm vilket nummer som uttrycker avsikten. Matcha containerporten efter DNAT när regeln skyddar tjänsten inne i containern. Matcha den ursprungliga destinationen med conntrack-alternativet när regeln måste beskriva vad klienten bad om, och acceptera den extra matchningskostnaden och omsorgen om regelordningen som följer med.

Kedja: DOCKER-USER, inte INPUT

Dockers iptables-guide placerar användarens vidarebefordringspolicy i DOCKER-USER-kedjan, som utvärderas före Dockers egna vidarebefordringsregler. En regel som kopierats från en värdtjänst till INPUT-kedjan filtrerar trafik som riktas till värden, inte trafik som vidarebefordras till en container. Det felet ger en regel som ser rätt ut och inte har någon effekt på containerns väg.

Håll källområdet, den effektiva destinationsporten, protokollet och det inkommande gränssnittet tillsammans i samma regel. En tillåtelse enbart på källa för varje vidarebefordrad destination är bredare än att tillåta en enda publicerad tjänst.

Verifiera med färska anslutningar

Testa båda riktningarna med nya anslutningar: en tillåten VPN-klient och en källa som ska förbli nekad. Befintligt anslutningstillstånd kan hålla en session vid liv efter att policyn ändrats, så en gammal anslutning bevisar ingenting om den nya regeln. Kontrollera sedan svarsvägen, eftersom containern fortfarande måste routa tillbaka till den källa den ser.

Dockers iptables-guide dokumenterar kedjeordningen och portöversättningsbeteendet bakom dessa kontroller. Läs den innan du kopierar ett recept, och bekräfta vilken backend den installerade Docker använder, eftersom nftables-backenden integrerar policy annorlunda.