Az ESP szépen visszafejt, a belső csomag mégsem jut el sehova

Az ESP fogadási számlálója nő, az alagút állva marad, az alkalmazás mégsem látja soha a csomagot. A visszafejtés lefutott, az integritásellenőrzés átment, majd a fogadónak el kellett döntenie, mi is valójában a védett hasznos teher. Pontosan ebben az utolsó lépésben jelenik meg a formátum-eltérés, és kívülről ez egyáltalán nem tűnik tűzfalproblémának.

Mit lát, amikor a címke hazudik

A kliens naplójában semmi sem különbözteti meg ezt egy útvonalválasztási fekete lyuktól. Mindkettő alkalmazás-időtúllépést okoz egy egészséges alagút mellett, ezért először a számlálókat okolják.

A növekvő fogadási számláló valóban jó hír: a csomagok megérkeznek és hitelesítődnek. Ez nem bizonyítja, hogy a belső csomag értelmes volt a titkosítási réteg felett bármi számára.

A típus a trailerben lakik

Szokásos IPsec-alagút módban az ESP-vel védett hasznos teher egy teljes belső IP-csomagot tartalmaz. A trailer következő fejléc mezője határozza meg, mi ez a teher, és ez nem TCP-port, nem a külső fejléc protokollszáma, és nem része a kezdeti SPI- és sorszámmezőnek. RFC 4303 2.6. szakasz hasznosteher-típus mezőként határozza meg, ami pontos név egy pontos feladathoz.

A szembejövő értékek kicsik és érdemes megjegyezni őket: az IPv4 értéke 4 (0x04), az IPv6 értéke 41 (0x29).

Ezek a számok az IANA protokollszám-kiosztásaiból származnak, nem helyi szokásból. Az a küldő, amely IPv4-et jelent be, miközben IPv6-csomagot csomagol be, formátum-ellentmondást hozott létre, és egyetlen tűzfalszabály sem javítja meg azokat a bájtokat, amelyek saját címkéjüknek mondanak ellent.

Hogyan különböztessük meg a szokásos gyanúsítottaktól

A legtöbb hiányzó csomag nem kódolási hiba. Először a szelektorokat ellenőrizze, mert az IPv6-előtagot kizáró forgalomszelektor még a beágyazás előtt eldobja a forgalmat. Utána ellenőrizze az útvonalválasztást, majd a fogadó gazdagép helyi szűrését. Csak ezek kizárása után válik hihető magyarázattá a hasznosteher formátumának eltérése.

Titkosított mentés nem dönti el, mert a védett következő fejléc a titkosított teher belsejében van. Implementációs diagnosztikára vagy támogatott, visszafejtett megfigyelési pontra van szükség, és mindkettőhöz engedély kell a használat előtt.

Ha senki nem tudja ezt a bizonyítékot előállítani, nincs formátumhibája. Van egy elmélete, és a szelektorok maradnak a jobb tipp.

Ami nem javítás

Ne kapcsolja ki az integritásellenőrzéseket, hogy a forgalom átjusson. Ne írja át a titkosított csomagokat egy köztes útválasztón, mert az nem működhet és tönkreteszi a folyamot, miközben egy mentésben hasznosnak látszik. Ne nyisson szélesebb alkalmazás-tűzfalszabályt arra az elméletre, hogy egy port blokkolva van. Ezek egyike sem érinti a címke eltérését.

Ha megerősített eltérés partner-implementációból származik, tartson meg egy minimális, tisztított reprodukciót, és vigye el az adott implementáció támogatott csatornájára.

A folyamot ellenőrizze, ne a számlálót

A javítás után tesztelje a tényleges IPv6-folyamot végponttól végpontig: egy alkalmazáskérés az alagúton át, annak válasza, és az a címpár, amelyet mindkét oldal lát. A növekvő ESP-számláló csak azt bizonyítja, hogy a csomagok fogadása és hitelesítése megtörténik. Semmit sem mond arról, hogy a belső csomag használható volt-e.

Rögzítse mindkét eredményt a jegyben. Számlálómozgás és működő folyam együtt javítás; a számlálómozgás önmagában pontosan az, ami a kezdés előtt volt.