Docker-portközzététel kontra VPN: hová megy a válasz

Egy közzétett konténer a saját címéről válaszol a fordított NAT előtt. Két terv tarthatja ezt a választ a nyilvános úton, eltérő költségekkel.

A gazdagép továbbra is válaszol SSH-n, miután egy teljes alagutas VPN feljön, miközben az ugyanazon a gépen Dockerrel közzétett szolgáltatás elhallgat. A fogadóval nincs semmi baj: a konténer fut, a portleképezés létezik, és a csomag megérkezik. A konténer egészséges, és a kérés valóban eléri. A különbség az, hogy honnan indul a válasz, amikor a Linux kiválasztja az útvonalát, és ez a különbség dönti el, melyikre van szükség az alábbi két terv közül.

Kövesse a tuple-t a cél-NAT-on keresztül

Vegyünk egy gazdagépet ezen a címen: 192.0.2.10, amely a TCP 2222 portot közzéteszi egy konténerre ezen a címen: 172.30.240.5:22. A kérés forrása: 198.51.100.25 címről érkezik, és a konténer elérése előtt lefordítódik, majd a konténer önmagaként válaszol.

WAN request:      198.51.100.25 -> 192.0.2.10:2222
after DNAT:       198.51.100.25 -> 172.30.240.5:22
container reply:  172.30.240.5:22 -> 198.51.100.25

A gazdagép útvonal-döntésénél a válasz még a konténer forráscímét hordozza. A fordított fordítás később állítja vissza a közzétett tuple-t, és ezért tűnik hibásnak a csomag éppen abban a pillanatban, amikor az útvonal kiválasztódik.

Miért hagyja ki egy csak gazdagépre vonatkozó szabály

Egy szabály, amely csak a következő forrásból érkező csomagokra választja a WAN-táblát: 192.0.2.10, lefedi a gazdagép saját démonjait, és teljesen kihagyja ezt a továbbított választ. A válasz forráscíme 172.30.240.5, nem a gazdagép.

A túlkorrekció az, hogy a konténer minden forgalmát a WAN-on keresztül irányítjuk, ami a konténer független kimenő kapcsolatait is mentesíti a VPN alól. Ez más politika, mint amit kértek, és általában később valakit meglep.

A DNAT utáni egyeztetés másik hook

A Docker dokumentációja a tűzfalakról megjegyzi, hogy a szokásos felhasználói szűrés a DNAT utáni célt látja, ezért a közzétett 2222 port egyeztetése egy normál szabályban nem ugyanaz, mint a konténer 22 portjának egyeztetése. Ha az eredeti tuple számít, használja a támogatott eredeti cél mechanizmusát ahelyett, hogy találgatná, melyik port látható.

Ez a hook-zavar olyan szabályokat hoz létre, amelyek helyesnek tűnnek, és soha nem egyeznek. A szabály átírása előtt ellenőrizze a számlálókat magán a szabályon. A nulla találatot mutató szabály elmondja, hogy olyan helyen értékelődik ki, ahová a csomag soha nem érkezik meg.

Terv A: hordozza a döntést kapcsolatállapotként

Egy kapcsolatjelölés átviheti a belépési döntést a fordításen, de vissza kell állítani a csomagra a fontos útvonalkeresés előtt. A lépések:

  1. Foglaljon le egy jelölésmezőt és szabályprioritást, amely nem ütközik a Dockerrel, a VPN-nel vagy más szabálytulajdonossal.
  2. Csak a szándékolt új WAN-kapcsolatot azonosítsa egy DNAT előtti ponton, ahol a kapcsolatkövetés elérhető.
  3. Rögzítse a döntést a kapcsolatjelölésen, anélkül hogy magát az eredeti kérést a WAN-táblára kényszerítené.
  4. A válasz irányában csak a saját jelölésbitjeit állítsa vissza a csomagra az útválasztás előtt.
  5. Válasszon teljes WAN-táblát elég korán ahhoz, hogy egy VPN-szabály ne nyerhessen elsőként.

Ennek a táblának szüksége van a valódi csatlakoztatott útvonalakra és az átjáróra. Szüksége van meghatározott viselkedésre akkor is, ha az útvonal hiányzik. A csendes alagútba hullás a legrosszabb kimenet, mert a konfiguráció még mindig úgy tűnik, mintha működne. Inkább zárjon zártan, és naplózza.

Terv B: fejezze be a gazdagépen

Egy szándékosan beállított gazdagép oldali frontend, például egy TCP-proxy vagy egy fordított proxy a konténer előtt, a választ a gazdagép címéről származtatva tartja. Ekkor a gazdagéphez írt szabályok a várt módon viselkednek, és a konténer a saját magánhálózatán marad.

Az ár egy újabb mozgó alkatrész, saját konfigurációval, forráscím-kezeléssel és hozzáférés-vezérléssel. Általában ez az egyszerűbb támogatott határ, és gyakran ez a helyes válasz, amikor az útválasztási szabályzatot egy olyan ember tartaná karban, aki esetleg távozik.

A változást ellenőrizze, ne a szándékot

Nyisson egy új, engedélyezett kapcsolatot a nyilvános oldalról, és erősítse meg, hogy a válasz a szándékolt interfészen távozik. Ezután ellenőrizze, hogy a konténer által indított független kérés továbbra is a VPN-t követi.

Ne ürítse ki a gép kapcsolattábláját egyetlen szabály teszteléséhez: a meglévő bejegyzések megtartják a korábbi leképezésüket, és az ürítés minden mást elront a gazdagépen. Egy port közzététele elérhetőséget határoz meg. Nem határozza meg a válasz útját. Írja le a választott tervet a táblaneveivel, hogy a következő embernek ne kelljen újra felfedeznie egy incidens közben.

Kapcsolódó cikkek