A hoszt eléri az IPsec partnert, a Docker konténer nem

Pingeli a távoli hosztot a Linux gépről, és az válaszol, tehát az alagút működik. A mellette lévő konténer továbbra is időtúllépést kap, és a természetes következő lépés a Docker újraindítása. Egy hídhálózati konténer általában más forráshellyel indul, és továbbítás útján lép be a hosztra, nem a hoszt alkalmazásának saját kimeneti útvonalán, ezért a sikeres teszt más csomagot mért. Szabályalapú strongSwan-alagút esetén a távoli alhálózat felé vezető egyszerű útvonal nem elég, ha a továbbított csomag nem illeszkedik a telepített IPsec-szabályhoz.

Az alábbi végigvezetés egy célt követ két forráson át, és az állapotot olvassa ki, mielőtt bármi változna.

Induljon ki egy célból és két forrásból

Először válasszon egy IP szerint ismert szolgáltatást, hogy ne a DNS-t hibakeresse ugyanakkor. Jegyezzen fel három tényt: a konténer híd-előtagját, a működött hosztkérés forráshelyét, és az alagút egyeztetett helyi és távoli forgalomszelektorait. Ez a három szám szinte minden ilyen tünetet megmagyaráz.

Ezután ismételje meg a sikertelen kérést a konténer belsejéből, és rögzítse a ténylegesen használt forrást. Ha ezt a címet nem fedi le a helyi szelektor, már ismeri az eredményt, és a konténer újralétrehozása sem változtat rajta.

Olvassa el a szabályokat, mielőtt hozzányúl a Dockerhez

A csak olvasható hosztellenőrzések az útválasztási döntéseket, a szabályadatbázist és a köztük választó szabályokat fedik le:

ip rule show
ip route show table all
ip xfrm policy

A szabálylista szelektorokat és irányt mutat anélkül, hogy kulcsanyaggal teli IPsec-állapotkiíratásra lenne szükség, ezért biztonságos jegybe másolni. Keressen olyan helyi szelektort, amely lefedi a hoszt címét, de a híd-előtagot nem. Ellenőrizze az átfedést is: egy olyan konténerútvonal, amely a távoli célt helyinek tekinti, soha nem állítja elő a várt továbbított csomagot, és az alagutat okolják érte. Tegye el ezt a listát a konténer forráshelye mellé, mert a kettő együtt a teljes összehasonlítás.

Ha a konténer előtagja hiányzik, álljon meg, és döntse el az architektúrát, mielőtt bármi mást szerkesztene. A végigvezetés többi része feltételezi, hogy megegyeztek abban, melyik forráshelynek kell megjelennie a hálózaton.

Ellenőrizze a szűrést és az átfordítást sorrendben

A Docker Linux híd-tűzfala az IPsec-től függetlenül blokkolhatja a továbbítást. Az iptables háttérrel vizsgálja meg a FORWARD útvonalat és a DOCKER-USER döntéseket, szem előtt tartva, hogy egy korábbi ítélet után hozzáfűzött szabály lehet, hogy soha nem fut le. Az nftables háttér másként integrálódik, ezért ne hozzon létre DOCKER-USER láncot csak azért, mert egy iptables-példa így nevezte el; ellenőrizze, melyik hátteret használja valójában a daemon.

Ezután ellenőrizze a forrásátfordítást. Egy széles MASQUERADE-szabály olyan csomaggá alakíthat egy korábban IPsec-szelektorhoz illeszkedő csomagot, amely már nem illeszkedik, és a hiba pontosan útválasztási problémának látszik. A strongSwan továbbítási útmutató dokumentálja a NAT-kivételt, amelyre egy ilyen átfordítás előtt szükség van a már szabályhoz illeszkedő forgalomnál.

Ez a kivétel nem arra való, hogy lefedetlen konténerforrást adjon az alagúthoz. Csak a már a tervezésbe illő forgalmat védi, ezért először rendezze a szelektor és a visszaút kérdéseit, majd hangolja össze a NAT-ot és a szűrést a válasszal. Ha inkább a kivételt kezdi szélesíteni, akkor a szelektort kell módosítani, nem a NAT-szabályt.

Ezután döntsön útvonalról vagy átfordításról

Egy útválasztott konténer-alhálózat megköveteli, hogy mindkét fél elfogadja azt az alhálózatot, és legyen hozzá távoli visszaút, ami általában szelektormódosítást jelent mindkét végén, és egyeztetést a távoli oldal tulajdonosával. Egy szándékosan átfordított tervezésnek viszont a megfelelő keresési szakaszban a szabály által lefedett címet kell felmutatnia, ami általában szűk, dokumentált szabályt jelent az alapértelmezett MASQUERADE helyett.

Egyik elrendezés sem következik automatikusan a hoszt működő alagútjából, és a köztük való választás tulajdonossal rendelkező tervezési döntés. Írja le, melyiket választotta, különben a következő mérnök újra levezeti a tűzfal-számlálókból.

Figyeljen a hibrid hibára is: a szabálykészlet fele átfordítva, fele nem, ami szakaszos sikert eredményez, amely a célporttól függ, és nem a hálózat bármely tulajdonságától.

Új kapcsolattal ellenőrizze, ne újraindítással

Használjon új alkalmazáskapcsolatot, miközben szűk tűzfal-számlálókat és a távoli fogadót figyeli, hogy minden megfigyelésnek legyen forrása. A Docker újraindítása megváltoztathatja a szabályok állapotát, és megzavarja a munkaterheléseket is, ami elviszi a tiszta jelzést, amelyet meg akart kapni.

A tartós eredmény négy állítás, amelyet meg tud mutatni: a konténer forrása, a megfelelő védett útvonal, az engedélyezett továbbítás, és egy válasz, amely visszajön. Ha mind a négy teljesül, a konténer ugyanazon okból éri el a partnert, mint a hoszt.