A lánc neve nem horog: iptables és nftables

Mindkét tűzfal szűrheti a továbbított VPN-forgalmat, és a szabályokat különböző módon kapcsolják a csomagútvonalhoz. Az iptablesben egy táblán belül beépített láncok vannak, ezért a FORWARD névvel ellátott horogpontként létezik. Az nftables szétválasztja a lánc nevét annak típusától, horgától és prioritásától, ami azt jelenti, hogy a FORWARD nevű egyszerű lánc semmit sem szűr. A két modell összehasonlítása megmagyarázza, miért hatástalan az egyik eszközben helyesnek tűnő bejegyzés a másikban.

A lánc egy tároló. Hogy a kernel megnézi-e, az a megvalósítástól és attól függ, hogyan kapcsolja hozzá a szabálykészlet.

Két modell, kétféle hozzákapcsolás

Az iptablesben a filter tábla három beépített lánccal jön, INPUT, FORWARD és OUTPUT, és a -N felhasználó által meghatározott láncot hoz létre, amely csak akkor lép működésbe, ha azok egyikéből ráugranak. Az nftables kézikönyve ehelyett alapláncokat határoz meg, amelyek deklarálják a típusukat, horgukat és prioritásukat, valamint egyszerű láncokat, amelyek nem. Az alaplánc bármilyen nevet viselhet, és a FORWARD nevű egyszerű lánc semmilyen tulajdonságot nem kap a címkéjétől. Ez a teljes különbség, és láthatatlan egy olyan útmutatóban, amely csak szabályszöveget mutat.

A kompatibilitási háttérrendszerek második okot adnak arra, hogy ne következtessünk a viselkedésre egy parancs nevéből. Az iptables dokumentációja olyan műveleteket említ, amelyek az iptables-nft alatt eltérnek, ezért a natív nftables-t, az iptables-nft-t és az örökölt szabálykészletet három rendszernek tekintse, ne egy rendszer három írásmódjának.

Olvassa a hibát a valódi összefüggésében

A hiányzó tábla, az engedélyhiba, az elérhetetlen kernelfunkció és a hiányzó megnevezett lánc négy különböző megállapítás, és csak egy szól a láncról. Rögzítse az eszköz verzióját, a kért címcsaládot és táblát, a hálózati névteret és az első pontos hibát. Ezután ellenőrizze, melyik összetevő birtokolja a szabálykészletet: egy tűzfal-szolgáltatás vagy egy termék által kezelt átjáró saját láncokat és sorrendet hozhat létre. Egy natív lánc melléjük illesztése érintetlenül hagyja a kezelt szabályzatot, a leltárt pedig zavarosabbá teszi.

Egy konténer névtere a gazdagéptől eltérő szabálykészletet tarthat, ezért a rossz környezetben futtatott parancs nem mutatja meg, melyik lánc látta a továbbított csomagot. A jogosultságok emelése amiatt, hogy egy várt lánc nem volt látható, nem diagnózis.

A számlálók elérést bizonyítanak, nem ítéletet

A szabályszámlálók megmondják, hogy egy szabályt elértek. Nem mondják meg, hogy egy későbbi szabály engedélyezte a műveletet, és nem bizonyítják, hogy minden alternatív útvonal elutasításra került. Egyetlen ártalmatlan, engedélyezett folyamat közben olvassa őket, a szabálysorrenddel és a lánc hozzákapcsolásával együtt, és egyetlen megfigyelésként kezelje őket, ne ítéletként. A nullától eltérő számláló egy eldobási szabályon azt jelenti, hogy a forgalom elérte; semmit sem mond a forgalomról, amely nem érte el.

A kernel IP-továbbítása teljesen külön beállítás. Egy lánc létezése nem engedélyezi a továbbítást, és egy ismerős címke hiánya nem jelenti azt, hogy a továbbítás leállt.

Írja le azt a folyamatot, amelyet védeni kíván

Írjon le egy ügyfélkérést a dekapszuláció után: a forrását, a célját, a címcsaládot, és hogy az átjárónál végződik-e vagy áthalad rajta. A helyi szolgáltatás bemenete és a továbbított forgalom különböző pontokon figyelhető meg, ezért különböző szabályokra és különböző tesztekre van szükségük. Hídalapú VPN esetén a híd útvonalát is ellenőrizze, mert az IP-szintű lánc nem felügyeli automatikusan az Ethernet-kereteket.

Távoli átjáró módosítása előtt őrizze meg a független helyreállítási hozzáférést. Ezután ugyanazon szabálykészlet mellett igazolja a szándékolt folyamatot és a szükséges elutasításokat. Az ismerős nevű új, üres lánc nem javítás.

Az összehasonlítás egyetlen kérdésben végződik: melyik horgot hívja meg a kernel valójában ehhez a csomaghoz? Válaszoljon erre, és a lánc neve többé nem számít.