DNAT i en VPN-container: vidarebefordran, inte INPUT

Efter DNAT blir en begäran till tunneladressen vidarebefordrad trafik. Avgränsa vidarebefordringsregeln, läs Docker-kedjan och välj en returväg med avsikt.

Begäran anländer adresserad till tunnelns IP och lämnar samma container adresserad till en närliggande tjänst. Mellan de två ögonblicken skrev DNAT om destinationen, och paketet slutade vara indata för VPN-containern. Nu är det vidarebefordrad trafik, bedömd av en annan regel. Den förskjutningen förklarar varför en brandväggsregel som ser rätt ut för tunneladressen inte har någon effekt på den översatta anslutningen.

Följ paketet efter översättningen

Ta en klientpool på 10.90.0.0/24 och en tunneladress på 10.90.0.1. Två containrar ligger på samma brygga: 192.0.2.2 kör VPN och 192.0.2.3 kör applikationen. En klient ansluter till 10.90.0.1:8080, och DNAT-regeln i VPN-containerns namnrymd skriver om det till applikationens verkliga adress och port. Därefter skickar en rutt paketet över bryggan. Dessa adresser är illustrativa, inte ett recept för driftsättning.

Porten som applikationen faktiskt lyssnar på kan skilja sig från vilken port som helst som publiceras på värden. Läs lyssnaren inuti containern i stället för att anta att båda talen stämmer.

Tillståndet hör till vidarebefordringsvägen

VPN-containern behöver IP-vidarebefordran och ett vidarebefordringsbeslut som är begränsat till klientpoolen, applikationens adress och den avsedda porten. Etablerade svar behöver sitt eget tillstånd. En regel som matchar den ursprungliga tunneladressen matchar inte efter DNAT, eftersom destinationen redan har ändrats. Ett INPUT-tillstånd är fel krok för trafik som inte längre är adresserad till den här värden.

Håll omfattningen snäv: ett källområde, en destination, en tjänst. En tillåtande vidarebefordringsregel är lättare att skriva och mycket svårare att försvara senare.

docker exec vpn-container ip route get 192.0.2.3
docker exec vpn-container iptables -t nat -S
docker exec vpn-container iptables -S FORWARD

Dockers kedjor är inte din containers kedjor

Regler inuti containerns namnrymd är inte Docker-värdens regler. När trafik korsar från tunnelgränssnittet till bryggan kan värdens bryggbrandvägg fatta ett annat beslut. Med Dockers iptables-backend är de dokumenterade vidarebefordringskedjorna och matchningspunkterna efter DNAT där det beslutet dyker upp.

Dockers brandväggsreferens beskriver dessa kedjor och matchningen efter DNAT. Åtgärda inte ett saknat godkännande genom att stänga av Dockers brandväggshantering eller göra varje kedja tillåtande, eftersom det tar bort den gräns du försöker använda.

Gör returvägen till ett medvetet val

Om källadressen bevaras ser applikationen 10.90.0.x och måste dirigera svar tillbaka genom VPN-containern. Annars skickar dess vanliga Docker-gateway dem till värden, som inte äger tunneln. Alternativet är en snävt begränsad källöversättning i VPN-containern, som förenklar svaret men döljer klienten för applikationen. Välj med avsikt och skriv ned vilket du valde.

Testa en ny tillåten anslutning från en vanlig klient och bekräfta sedan att orelaterade portar förblir stängda. När ett paket försvinner, granska VPN:ns namnrymd, applikationens namnrymd och applikationens egen logg. En ping till bryggans gateway är inte ett acceptanstest för tjänsten.

Håll reglerna i containerns stödda startkonfiguration, eftersom interaktiva ändringar försvinner när den återskapas. Publicering av en värdport är en annan exponeringsväg och behövs inte bara för att tjänsten nås via tunneln.

Relaterade artiklar