A házirend-szabály megjelölt csomagokat küld egy dedikált táblába, és a szokásos elvárás az, hogy a VPN-útvonal elvesztése blokkolja őket. A mechanizmus mást tesz. Amikor egy táblában nincs egyező útvonal, a keresés továbbhalad a következő szabályra ahelyett hogy megállna, és a main tábla továbbra is tart egy közönséges alapértelmezett útvonalat az uplinkhez. Az eredmény egy olyan konfiguráció, amely fail-closednak látszik, de fail-openként viselkedik.

Semmi sem tört el; a házirend-alapú útválasztás így van meghatározva.

A keresés továbbhalad, ha a táblában nincs semmi

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 lookup default
32766: from all lookup main

Vegye ezt a szabálykészletet: a megjelölt keresés a 42-es táblába megy, és egy későbbi szabály ugyanazt a jelölést egy default nevű táblába küldi. Amíg a 42-es tábla használható alapértelmezett útvonalat tart, az első keresés adja az útvonalat. Amikor az az útvonal eltűnik, és a 42-es táblában semmi más nem egyezik, a keresés nem válik eldobássá; a feldolgozás a következő szabályra lép, és amikor az sem talál semmit, eléri a main táblát. Ebben a sorrendben semmi sem jelenti melyik szabály adta a végső választ, ezért egy működő kapcsolat működő házirendnek látszik.

A 253-as tábla, amelyet hagyományosan defaultnak neveznek, közönséges útválasztási tábla, és általában üres. A neve nem utasítás a csomagok eldobására, és nem ugyanaz, mint egy táblán belüli alapértelmezett célútvonal.

A terminális műveletek befejezik a keresést

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 prohibit
32766: from all lookup main

Egy terminális szabály követheti a VPN-keresést üres táblás keresés helyett. Ugyanazzal a jelöléssel a 42-es tábla szabálya után elhelyezett prohibit művelet befejezi a keresést, amikor az a tábla semmit sem ad, és adminisztratív elutasítást ad vissza ahelyett, hogy a main táblának még egy esélyt adna. Az unreachable és a blackhole szintén terminális, a küldő számára eltérő hibaviselkedéssel.

A throw típusú útvonal más: azon a táblán belül úgy viselkedik, mintha semmi nem egyezett volna, így a későbbi szabályok mégis sorra kerülnek. Ez a throw-t hasznossá teszi szándékos visszaeséshez, és hibássá végső blokként.

Ellenőrizze a valódi jelöléssel és interfésszel

ip -4 rule show
ip -4 route show table 42
ip -4 route get 198.51.100.20 from 10.44.0.2 iif lan0 mark 0x36

Vizsgálja meg a valódi szabályokat és táblát diagram helyett, majd kérdezze le a folyamot azzal a forrás-, jelölés- és belépési kontextussal, amely valóban van neki. A célra irányuló, csak olvasható keresés, amelynek megadják a forráscímet, az interfészt és a jelölést, azt az útvonalat jelenti, amelyet a kernel választana anélkül, hogy csomag távozna. A jelölés megadása a lekérdezésben nem bizonyítja, hogy a tűzfal valódi forgalmat jelöl meg; az a jelölési szabályok külön ellenőrzése. A lekérdezésből levont következtetések előtt erősítse meg az értéket számlálóval vagy naplóval.

A helyben generált kéréseknek saját kontextusra van szükségük, mert jelölési útvonaluk gyakran eltér a továbbított forgalométól. Ellenőrizze őket azzal a kimeneti interfésszel, amelyet az alkalmazás valóban használna.

Két hibaállapot, nem egy

Az egyik hibaállapot az, hogy a VPN-útvonal eltűnik, és a forgalom átcsúszik az uplinkre. A halott alagút, amelynek útvonala telepítve marad, egy másik: a csomagok továbbra is egy használhatatlan útra irányulnak ahelyett, hogy átcsúsznának, és a tünet csendes veszteség, nem látható közvetlen kapcsolat. Tesztelje mindkettőt, valamint az indítás, az újracsatlakozás és a szolgáltatás leállításának viselkedését.

Egy ilyen szabály csak addig segít, amíg létezik, és amíg a csomagok még hordozzák az őt kiválasztó jelölést. Egy leállító szkript, amely törli a szabályt, vagy egy útvonal, amely leveszi a jelölést, visszaállítja a nyitott viselkedést. Ezeket az átmeneteket érdemes begyakorolni.

Alkalmazza a házirendet az IPv6-ra külön, és tartsa a jóváhagyott végpont-kivételeket kifejezettként, nem hallgatólagosként.

Kapcsolódó cikkek