Docker-portközzététel és VPN-források: két egyezés, amelyet elvét

A szabály azt mondja, engedélyezd a VPN-kiszolgáló címét a közzétett szolgáltatás felé, és a kapcsolat mégis megszakad. Ez az eredmény gyakori, és nem Docker-hiba. Két külön egyezés hibás: lehet, hogy a beírt forrás nem az a forrás, amelyet a gazdagép fogad, és lehet, hogy a beírt port nem az a port, amelyet a szűrő lát. Mindkettő javításához a csomag útvonalát kell nézni a szolgáltatás ábrája helyett.

A mítosz: engedélyezd a VPN-kiszolgálót, és kész

Egy irányított VPN a kliens alagútcímét egészen a Docker-gazdagépig megőrizheti. Egy átjáró, amely forrásfordítást végez, ezt a címet a sajátjára cserélheti. Mindkét kialakítás jogszerű, és ugyanahhoz a felhasználói művelethez eltérő forrásokat ad.

Tehát a VPN-kiszolgáló IP-je kifejezés feltevést ír le, nem megfigyelést. Amíg nem tudod, melyik kialakítás van előtted, a szabály találgatás.

Forrás: kliensmedence vagy fordított átjáró

Négy dolgot ellenőrizz sorban. Először a klienscímmedencét, például 10.90.0.0/24. Másodszor, hogy az átjáró fordítja-e azt a medencét, mielőtt a gazdagéphez ér. Harmadszor, milyen forrást figyel meg a gazdagép valóban egy új kapcsolatnál. Negyedszer, hogy az alkalmazás hitelesítése megkülönbözteti-e az egyes felhasználókat, mert egy megosztott fordított cím nem képes erre.

Ha a medence megmarad, a csak az átjáró nyilvános címére illeszkedő szabály minden klienst elvét. Ha az átjáró szándékosan fordít, a fordított cím engedélyezése beenged minden mögötte lévő felhasználót, ami elfogadható lehet saját bejelentkezéssel rendelkező szolgáltatásnál, és elfogadhatatlan minden más esetben.

Port: a DNAT megváltoztatja az illesztett számot

A szokásos Linux-hidas közzétételnél Docker iptables-szel a gazdagép 8443-ról a konténer 443-as portjára mutató leképezése a továbbító szűrő futása előtt fordítódik. A csomag 443-as célporttal érkezik a szűrőhöz. Az a szabály, amely ott 8443-ra illeszkedik, soha nem lép működésbe, pedig 8443 az, amit a kliens beírt.

A közzétett port továbbra is létezik a kapcsolatkövetésben, ezért az eredeti cél ott illeszthető, amikor valóban szükséged van rá.

Döntsd el, melyik szám fejezi ki a szándékot. A DNAT utáni konténerporthoz illeszkedj, amikor a szabály a konténeren belüli szolgáltatást védi. Az eredeti célhoz illeszkedj a conntrack beállítással, amikor a szabálynak azt kell leírnia, amit a kliens kért, és fogadd el a járulékos illesztési költséget és a szabálysorrend körültekintését, amely ezzel jár.

Lánc: DOCKER-USER, nem INPUT

A Docker iptables-útmutatója a felhasználói továbbítási szabályzatot a DOCKER-USER láncba helyezi, amelyet a Docker saját továbbítási szabályai előtt értékel. A gazdagépszolgáltatásból az INPUT láncba másolt szabály a gazdagépnek címzett forgalmat szűri, nem a konténerbe továbbított forgalmat. Ez a hiba olyan szabályt eredményez, amely helyesnek látszik, és nincs hatása a konténer útvonalára.

Tartsd együtt ugyanabban a szabályban a forrástartományt, a tényleges célportot, a protokollt és a bejövő interfészt. A csak forrás alapú engedélyezés minden továbbított célhoz szélesebb, mint egyetlen közzétett szolgáltatás engedélyezése.

Ellenőrizd friss kapcsolatokkal

Teszteld mindkét irányt új kapcsolatokkal: egy engedélyezett VPN-klienst és egy forrást, amelynek elutasítottnak kell maradnia. A meglévő kapcsolatállapot életben tarthat egy munkamenetet a szabályzat megváltoztatása után, ezért egy régi kapcsolat semmit sem bizonyít az új szabályról. Ezután ellenőrizd a válasz útvonalát, mert a konténernek továbbra is vissza kell irányítania ahhoz a forráshoz, amelyet lát.

A láncok sorrendjét és a portfordítás viselkedését ezek mögött az ellenőrzések mögött a Docker iptables-útmutatója dokumentálja. Olvasd el, mielőtt receptet másolnál, és erősítsd meg, melyik backendet használja a telepített Docker, mert az nftables backend másképp integrálja a szabályzatot.