Ping VPN-en át: miért nem találják el a visszautat az echoválaszra vonatkozó szabályok

Pingeljen egy hosztot VPN-en át: a kérés egy ICMP-típussal indul és egy másikkal tér vissza, ami elég ahhoz, hogy összezavarjon minden portokra megfogalmazott szabályt. Az echo-csere során nincs cél szolgáltatásport, amit a visszatérési szabályba lehetne másolni, és a szimmetriát váró szűrő eldobja a választ, miközben a kérés akadálytalanul átmegy. A javítás azzal kezdődik, hogy a csomagot úgy olvassuk, ahogy valójában van, majd eldöntjük, melyik határ hozza a döntést az útvonalon. Általában két réteg dolgozik, miközben a harmadik csendben eldobja a választ. Az alábbi szakaszok abban a sorrendben választják szét őket, ahogy egy csomag találkozik velük.

A csomag típust vált, nem portot

Az echokérés ICMP 8-as típus, 0-s kód, és azonosítót meg sorszámot hordoz. A válasz 0-s típus, 0-s kód, ugyanazzal az azonosítóval és sorszámmal, az IP-végpontok pedig felcserélve. Ezeket a mezőket az RFC 792 definiálja, és éppen az azonosító teszi lehetővé, hogy a küldő a válaszokat a saját kéréseihez párosítsa.

Ami hiányzik, az ugyanolyan fontos: nincs TCP- vagy UDP-fejléc, tehát nincs port, amit engedélyezni kellene. Az a szabály, amely portot nevez meg az echoválaszhoz, olyan csomagot ír le, amely soha nem fog létezni. Ez a leggyakoribb hiba a VPN-es pingjegyekben. A szabály konkrétnak látszik, semmire nem vonatkozik, és pontosan ott hagyja a hibát, ahol volt.

Három kontextus dönt a csomagról

Ha a ping a távoli LAN egyik hosztját célozza, a kérést az átjárónak továbbítania kell. Ha olyan címet céloz, amely magához az átjáróhoz tartozik, akkor a helyi bemeneti útvonalon fejeződik be. Ha az átjáró maga indítja a pinget, a csomag a saját kimeneti útvonalán indul, és egyáltalán nem halad át a továbbítási döntésen.

Ennek a három kontextusnak külön szabályláncai és külön számlálói vannak, és épp az, hogy egynek tekintjük őket, az oka annak, hogy „a tűzfal engedi az ICMP-t” mégis sikertelen pinget adhat. A külső alagút a negyedik kontextus: a VPN-figyelő engedélyezése nem engedélyezi automatikusan a visszafejtett belső kérést, a belső engedély pedig semmit sem mond arról, hogy a külső alagút áll-e.

Az állapotkövető és az állapot nélküli szűrő másképp kezeli a választ

Egy állapotkövető tűzfal, amely látta a kérés kimenetelét, a választ ehhez a folyamhoz kapcsolhatja, és második szabály nélkül beengedheti. Az állapot nélküli szűrőnek nincs ilyen memóriája, ezért a visszatérő iránynak saját kifejezett engedélyre van szüksége, a forrás és a cél felcserélésével.

Bármi írása előtt ellenőrizze, melyik modellt valósítja meg valójában a termék. Az echokérésre vonatkozó szabály nem feltétlenül fedi le az echoválaszt, és az ICMP-lekérdezéseket követő termék még mindig más szabályzatot alkalmazhat a másik interfészen érkező válaszokra.

Határolja be, amit engedélyez. Minden echoválasz engedélyezése bárhonnan nem ugyanaz, mint egy állapotkövető társítás befejezése, és egy típusszám nem hitelesíti a küldőt.

A fordítás az azonosítót is megváltoztatja

Ha a forrásfordítás szándékos, a távoli vég sora nem egyezik azzal, amit a kliens küldött. A NAT az ICMP-lekérdezés azonosítóját a címekkel együtt fordíthatja, ezért annak erőltetése, hogy ugyanaz a szám jelenjen meg mindkét oldalon, hamis eltérést eredményez.

Inkább a fordító által jelentett leképezéshez kapcsolódjon. Az azonosítót átíró fordító nem őrzi meg a kliense által naplózott számot, ezért a leképezést tekintse azonosságnak, nem a számot. Ezután kövessen egy azonosítható kérést az útvonalon: erősítse meg, hogy a várt forrással éri el a célt, erősítse meg, hogy a cél választ küldött, kövesse annak a válasznak a visszaútját, és erősítse meg, hogy a kliens megkapta, ahelyett hogy csak egy átjáró-számláló növekedését nézné.

Ne olvassza össze az ICMP-hibákat az echo-szabályzattal

Az útvonal-MTU felderítés által használt „töredezés szükséges” üzenet nem echoválasz, és a hasznos terhe azt a csomagot idézi, amely kiváltotta. Az csak echót engedélyező szabály, amely csendben eldobja ezeket a hibákat, egy méretproblémát akadó kapcsolattá alakít, ami a hasznos ellentéte.

Ugyanez a óvatosság érvényes a címcsaládokra. Az ICMPv6 más üzenettípusokat használ, és olyan lényeges funkciókat hordoz, amelyekkel az IPv4 nem rendelkezik, ezért ezeket a számokat IPv6-szabályba másolni egyszerűen hibás.

Amikor az echo-csere működik, külön tesztelje a valódi alkalmazást. Egy sikeres ping egy protokoll egy méretben egy cél felé tett oda-vissza útját bizonyítja, és nem felhatalmazás arra, hogy feltételezzük: a HTTPS, az SMB vagy bármely más folyam engedélyezett.