Helyezzen engedélyezési szabályt rossz helyre, és úgy viselkedik, mintha egyáltalán nem lenne szabály. Az nftablesben az insert és az add közötti választás dönti el, hogy a hivatkozott szabály melyik oldalára kerül az új utasítás, a fogantyú pedig a szabályt nevezi meg az élő szabálykészletben, nem a sorszámát. Ha a hely rossz, a csomag előbb éri el a dropot.

Az alábbi összehasonlítás egy rögzített partnert és egy külső hallgatócserét használ. Szándékosan szűk; egy teljes lánc lecserélése más változtatás, más kockázati profillal.

Két elhelyezés, két különböző eredmény

insert a hivatkozott szabály elé helyez szabályt. add utána helyezi. Ha a hivatkozott szabály a folyamat terminális dropja, ez a két parancs ellentétes eredményt ad, még ha a szabály szövege azonos is.

A hely megadásának elhagyásának saját alapértelmezett viselkedése van, ami újabb ok arra, hogy ne másoljon parancsot fórumról anélkül, hogy elolvasná, mihez van horgonyozva. A horgony maga a döntés. Írja le a szándékolt oldalt, mielőtt beírja a parancsot. Az insert és az add egy szóban tér el a fájlban.

Az elhelyezés egy adott láncban lévő szabályhoz viszonyított. Ugyanannak az utasításnak másik láncba vagy másik hook-prioritásba mozgatása megváltoztatja, mely csomagokat látja, akkor is, ha a szabály szintaxisa helyesnek tűnik.

A fogantyú szabályt azonosít, nem sorszámot

Egy 42-es fogantyú azonosító a szabálykészlet aktuális állapotában. Nem a negyvenkettedik szabály, és nem stabil gazdagépek, újraépítések vagy a konfigurációját újratöltő kezelő között.

A horgony kiválasztása előtt keresse meg a láncot és a tényleges terminális dropot. Ezután erősítse meg a fogantyút azon a szabályon ugyanabban a listában, amely a dropot mutatja, hogy a szám és a szabály együtt legyen olvasható. Egy régi listából olvasott fogantyú már más szabályhoz tartozhat. Olvassa újra abban a munkamenetben, amely alkalmazni fogja a változtatást.

iptables --version
nft -a list ruleset

Az iptables verziója megmondja, melyik backend van használatban. Egy iptables-nft szabálykészlet és egy önállóan kezelt natív tábla együtt létezhet, ezért egy frontend listája nem automatikusan a teljes szűrési kép. Válasszon láncot csak mindkét nézet ellenőrzése után.

Keresse meg a láncot és a szabályt, amely valóban dropol

Olvassa el az input hookot, a lánc prioritását és a szabályt, amely elutasítja ezt a hallgatófolyamot. Egy inet tábla mindkét címcsaládot hordozhatja, de egy egyedi szabály továbbra is csak IPv4-re illeszkedhet.

Vegyen egy jóváhagyott partnert, példaként a dokumentációs tartományból a 198.51.100.25 címet használva. Egy átvizsgált natív fájl külső engedélyt helyezhet a 42-es fogantyú elé:

insert rule inet filter input handle 42 iifname "eth0" ip saddr 198.51.100.25 udp dport { 500, 4500 } counter accept

A vizsgálat után cserélje ki a családot, a táblát, a láncot, a fogantyút, a bejövő interfészt és a partnert. A példa az nft 1.0.9-hez dokumentált fogantyú-helyzet alakot használja, és bemeneti fájlba való; a kapcsos zárójelek idézése külön kérdés, amikor a parancsot interaktívan írják be.

Tartsa egyértelműen a konfiguráció tulajdonosát. Egy kezelő, amely újraépíti a szabályait, felülírhat egy futásidejű módosítást, és egy elavult fogantyút keményen kódoló indítószkript vagy meghiúsul, vagy a rossz szabályhoz kapcsolódik.

Az engedélyezés hatókörrel bír, a drop terminális

Az engedélyező ítélet az aktuális útvonalán fejezi be az értékelést, de egy később alkalmazható alap-lánc még mindig eldobhatja a csomagot. A drop-ítélet terminális. Ezért a növekvő engedélyezésszámláló nem bizonyítja, hogy a folyamat sikeres volt.

Vizsgálja meg az összes releváns hook-prioritást egyetlen lánc helyett elszigetelten. Egy csomag átjuthat egy input szűrőn, és mégis elutasíthatja egy másik tábla hookja más prioritáson. Sorolja fel minden alap-láncot, amely látja a folyamatot.

Ez a szabály csak a külső hallgatócserét fedi le. A szállítási beágyazású ESP, a natív ESP, az IPv6-os partnerek és az alagútban lévő visszafejtett forgalom mind saját házirendet igényel. Ez nem egy teljes webhely-VPN tűzfal.

Ellenőrizze a fájlt, majd igazolja az élő eredményt

Az alkalmazás előtt futtasson szintaxis- és tranzakcióellenőrzést az átvizsgált fájlon. Az ellenőrző mód jelzi, hogy az nft képes-e elemezni és előkészíteni a változtatást; nem alkalmazza, és nem bizonyítja, hogy egy másik hook engedélyezni fogja a csomagot. A fájl javaslat marad, amíg a tulajdonos alkalmazza:

nft -c -f reviewed-vpn-rule.nft

A tulajdonos ellenőrzött folyamatán keresztül alkalmazza, és őrizze meg a helyreállítási hozzáférést. Ha a szabály hibás, a drop, amelyet meg akart előzni, elvághatja azt az útvonalat is, amelyen javítani próbálja.

A változtatás után figyeljen meg egy új engedélyezett partnerkísérletet, és ellenőrizze, hogy a jóváhagyott partneren kívüli források továbbra is elutasításra kerülnek. Vigye át a tartós szabályt abba a kezelőbe, amely a szabálykészletet birtokolja, mert a futásidejű fogantyúk az aktuális objektumokat lokalizálják, nem pedig indítások között azonosítják őket.

Kapcsolódó cikkek