DNAT VPN-konténerben: továbbítás, nem INPUT

DNAT után az alagút címére érkező kérés továbbított forgalommá válik. Szűkítse a továbbítási szabályt, olvassa el a Docker-láncot, és válasszon visszaútvonalat szándékosan.

A kérés az alagút IP-címére címezve érkezik, és ugyanabból a konténerből egy szomszédos szolgáltatás címére címezve távozik. A két pillanat között a DNAT átírta a célt, és a csomag megszűnt bemenet lenni a VPN-konténer számára. Most továbbított forgalom, amelyről másik szabály dönt. Ez a váltás magyarázza, miért nincs hatással a fordított kapcsolatra egy tűzfal-szabály, amely az alagút címéhez helyesnek tűnik.

Kövesse a csomagot a fordítás után

Vegyen egy 10.90.0.0/24 klienspoolt és egy 10.90.0.1 alagútcímet. Két konténer ül egy hídon: a 192.0.2.2 futtatja a VPN-t, a 192.0.2.3 pedig az alkalmazást. Egy kliens csatlakozik a 10.90.0.1:8080-hoz, és a VPN-konténer névterében lévő DNAT-szabály átírja az alkalmazás valódi címére és portjára. Ezután egy útvonal átküldi a csomagot a hídon. Ezek a címek szemléltetők, nem telepítési recept.

A port, amelyen az alkalmazás valóban figyel, eltérhet a hoszton közzétett bármely porttól. Olvassa a figyelőt a konténeren belül, ahelyett hogy feltételezné, hogy a két szám megegyezik.

Az engedély a továbbítási útvonalhoz tartozik

A VPN-konténernek IP-továbbításra és a klienspoolra, az alkalmazás címére és a szándékolt portra szűkített továbbítási döntésre van szüksége. A létrejött válaszoknak saját engedély kell. Az eredeti alagútcímre illeszkedő szabály DNAT után nem fog illeszkedni, mert a cél már megváltozott. Az INPUT-engedély rossz kampó az olyan forgalomhoz, amely már nem ehhez a hosthoz címzett.

Tartsa szűken a hatókört: egy forrástartomány, egy cél, egy szolgáltatás. Egy megengedő továbbítási szabályt könnyebb megírni, és sokkal nehezebb később megvédeni.

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

A Docker láncai nem a konténer láncai

A konténer névterén belüli szabályok nem a Docker-host szabályai. Amikor a forgalom az alagút interfészéről a hídra lép, a host híd-tűzfala más döntést hozhat. A Docker iptables-hátterével a dokumentált továbbítási láncok és a DNAT utáni illesztési pontok azok, ahol ez a döntés megjelenik.

A Docker tűzfal-referencia leírja ezeket a láncokat és a DNAT utáni illesztést. Ne javítsa a hiányzó elfogadást a Docker tűzfal-kezelésének kikapcsolásával vagy minden lánc megengedővé tételével, mert az eltávolítja a határt, amelyet használni próbál.

Tegye szándékos választássá a visszaútvonalat

Ha a forráscím megmarad, az alkalmazás 10.90.0.x-et lát, és a válaszokat a VPN-konténeren keresztül kell visszairányítania. Különben a szokásos Docker-átjárója a hostra küldi őket, amely nem birtokolja az alagutat. A másik lehetőség a szűken korlátozott forrásfordítás a VPN-konténeren, amely egyszerűsíti a választ, de elrejti a klienst az alkalmazás elől. Válasszon szándékosan, és írja le, melyiket választotta.

Teszteljen egy friss engedélyezett kapcsolatot egy közönséges kliensről, majd erősítse meg, hogy a nem kapcsolódó portok zárva maradnak. Amikor egy csomag eltűnik, vizsgálja meg a VPN névterét, az alkalmazás névterét és az alkalmazás saját naplóját. A híd átjárójára küldött ping nem elfogadási teszt a szolgáltatásra.

Tartsa a szabályokat a konténer támogatott indítási konfigurációjában, mert az interaktív módosítások eltűnnek, amikor újra létrejön. A hostport közzététele más kitettségi útvonal, és nem szükséges csak azért, mert a szolgáltatás elérhető az alagúton.

Kapcsolódó cikkek