Mindkét vég létrejött alagutat jelent, a távoli fióktelep az átjárótól válaszol, az alkalmazás mégis időtúllépést mutat az egyik oldal felhasználóinál. A szokásos tanács szerint mindkét irányban tűzfalszabályt kell felvenni. Néha ez helyes, néha egy már létező szabályt duplikál, és néha éppen a második szabály az, amely elrontja az állapotot. Melyik eset áll fenn, az attól függ, hol látja a csomagot a tűzfal.

Az állapotkövető visszatérő forgalom megváltoztatja a számot

Az állapotkövető tűzfal rögzíti a kérést és második szabály nélkül engedi a választ, így az egyetlen szabályt igénylő kialakítás normális. Az állapot nélküli hozzáférési lista nem rendelkezik ilyen memóriával, és a választ kifejezetten engedélyezni kell. Mindkettő helyes a saját platformján, ezért mondanak ellent egymásnak a tanácsok.

Olvassa el az előtte lévő platform továbbítási dokumentációját, és ellenőrizze, hogy a szerkesztett házirend állapotkövető-e ott, ahol a csomagot látja. A létrejött forgalom kifejezett tiltása, vagy a szabálysorrend, amely a választ az állapottábla előtt értékeli, működő kialakítást rejtélyessé tesz. A szabályok száma megvalósítási részlet, a követelmény pedig az, hogy az engedélyezett beszélgetés mindkét iránya befejeződhessen.

Hol látja a tűzfal a visszafejtett csomagokat

Szabályalapú alagútban a tűzfal a titkosított csomagot a visszafejtés előtt és a visszafejtett csomagot utána is értékelheti, különböző interfészeken. A rossz interfészre írt szabály jelen van, helyes, és soha nem illeszkedik. Így egy működő telepítésből másolt szabálykészlet azonos hardveren is meghiúsulhat.

Az útvonalalapú IPsec és a legtöbb modern megvalósítás alagút-interfészt biztosít, így a visszafejtett csomag ott érkezik meg, és a szokásos interfészszabályok érvényesek. A szabálykészlet másikhoz írt útmutatóból való másolása előtt erősítse meg, melyik modellt használja a telepítés. Az alagút-interfész az a hely is, ahol megnézheti, egyáltalán vissza lett-e fejtve egy csomag.

Az aszimmetrikus útválasztás megtöri a feltevést

Az állapotkövető tűzfal feltételezi, hogy a beszélgetés mindkét felét látja. Ha a válasz másik átjárón keresztül tér vissza, az az eszköz nem tart állapotot a kéréshez, és a saját házirendje szerint eldobja azt. A tünet egyirányú hiba, amelyet a küldő oldalon egyetlen szabály sem tud kijavítani. Kövesse a válasz útját mielőtt bármit szerkesztene.

Ellenőrizze a válasz útvonalát, mielőtt széles engedélyező szabályt adna hozzá mindkét oldalon. Mindent eltűrni minden interfészen elrejti az útválasztási hibát, és egyben szélesíti a hozzáférést, ami a legrosszabb elérhető kombináció.

Ellenőrizze mindkét irányt valódi forrás-címekkel

A távoli oldal által ténylegesen látott címmel teszteljen, mert a fordítás miatt egy forrásszabály semmivel sem illeszkedhet. Futtassa a rögzítést mindkét átjárón egyszerre.

tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15

A távoli átjárón váratlan forráscímmel megjelenő kérés olyan szabályt magyaráz, amely soha nem illeszkedik, a rossz interfészre érkező válasz pedig állapot-eltérést magyaráz. Ezután teszteljen egy célpontot a jóváhagyott hatókörön belül és egyet azon kívül, hogy a határ bizonyítva legyen, ne feltételezve.

Jegyezze fel a forráscímet a fordítás után, az interfészt, amelyet a visszafejtett csomag használt, és az illeszkedő szabályt. Ez a három tény megválaszolja a következő jegyet a teljes vizsgálat megismétlése nélkül.

Kapcsolódó cikkek