Hová kerül a VPN NAT az UFW before.rules fájljában, és hogyan teszteljük

Egy NAT-szabály, amely héjban begépelve működik, akkor hibázik, amikor a before.rules fájlba illesztjük, mert az a fájl nem szkript. Visszaállítási formátumú dokumentum táblaszakaszokkal, láncdeklarációkkal és táblánkénti COMMIT-jelölővel. A rossz helyen lévő sor vagy megszakítja a teljes visszaállítást, vagy csendben eldobja azokat a szabályokat, amelyekről azt hitte, ott vannak. Az alábbi eljárás oda teszi a töredéket, ahol a keretrendszer várja, és a következő újratöltés előtt bizonyítja az eredményt.

A héjparancs nem visszaállítási fájl

A iptables -t nat szöveggel kezdődő sor utasítás az iptables binárisnak, míg az UFW által olvasott fájl egy teljes szabálykészlet leírása. A különbség nem kozmetikai: a visszaállítási formátumnak tudnia kell, melyik táblában van, mely láncok léteznek, és hol ér véget a tábla. A dokumentumba illesztett parancs vagy szintaktikai hiba, vagy ami rosszabb, a rossz táblához csatolt szabály. A keretrendszer éppen azért tölti be ezeket a fájlokat visszaállító eszközökkel, mert deklaratívak, nem pedig szekvenciálisak.

A dokumentum egészként is betöltődik, így egy hibás szakasz megakadályozhatja a fájl többi részének érvényesülését. Ezért egy kis hiba a NAT-töredékben magával rántja a szűrőszabályokat is, és így válik egy tűzfalváltozás kieséssé.

Helyezze a töredéket a meglévő táblaszakaszba

A NAT-töredéknek alakja van, és az alak fontosabb, mint a benne lévő szabály szövege. A táblafejléc nyitja a szakaszt, a láncdeklarációk állítják fel a számlálókat, következnek a szabályok, és egy COMMIT zárja a szakaszt.

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

A fenti pool és interfész a saját értékei helyőrzői; a szerkezet az a rész, amelyet érdemes másolni. Ha a fájl már tartalmaz *nat szakaszt, abba a szakaszba illessze a szabályt, ne nyisson másodikat, mert a formátum táblánként egy COMMIT-ot vár, és ugyanahhoz a táblához két szakasz olyan javítás, amely a megtörténésre vár. Tartsa érintetlenül a disztribúció láncdefinícióit, beleértve azokat is, amelyeket a szállító a saját integrációjához adott hozzá. Az UFW keretrendszer kézikönyve dokumentálja a before, user és after fájlokat, valamint a megfelelő COMMIT követelményét.

Ha a fájl üresnek bizonyul, ne töltsük ki egy útmutatóból. Erősítsük meg, melyik csomag birtokolja, és mi a tényleges élő szabályzat, mert egy üres állandó fájl nem bizonyítja, hogy a kernel nem tart nyilván szabályokat, és egy betöltött szabálykészlet nem bizonyítja, hogy a következő újratöltésnek lesz teljes fájlja olvasásra. Először állítsa vissza a támogatott alapvonalat, majd alkalmazza újra a telephelyi módosításokat.

Tesztelje a jelöltet alkalmazás nélkül

A visszaállító eszköz képes egy szabálykészletet elemezni és felépíteni anélkül, hogy alkalmazná, és ez a legolcsóbb elérhető teszt. Védett másolaton futtassa, ne az élő fájlon, és a hibaüzenetet olvassa, ne csak a kilépési állapotot. Az elemzési hiba egy sort és általában egy táblát nevez meg, ami több annál, mint amit egy sikertelen újratöltés mond.

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

Ennek az ellenőrzésnek a teljesítése azt bizonyítja, hogy a dokumentum elemezhető, és semmi mást. Nem bizonyítja, hogy a jelölt még mindig tartalmazza az összes láncot, amelytől az UFW függ, hogy csak a szándékolt forrásokat engedi, vagy hogy a távoli adminisztráció elérhető marad. Ezek külön felülvizsgálatok, és az utolsó egy második munkamenetet érdemel, amelyet a kezdés előtt nyitnak meg.

Válassza azt az eszközt, amely megfelel a telepített háttérrendszernek és a címcsaládnak. Az nft háttérrendszert a kompatibilitási rétegen keresztül futtató gazdagépnek a megfelelő parancsra van szüksége, és az IPv6-szabályok teljesen más fájlban élnek.

Tartsa külön a továbbítást, a NAT-ot és a hozzáférési szabályzatot

A forrásfordítás megold egy címzési problémát, és semmit nem ad. Az átirányítás külön engedély, amelyet egy sysctl és a szűrőtábla vezérel, és éppen ezt felejtik el az emberek, amikor az alagút irányít, de nem enged át forgalmat. A hozzáférési szabályzat a harmadik döntés arról, mely források mely szolgáltatásokat érhetnek el, és egyetlen NAT-szabály sem fejezi ki. Éppen a három szétválasztása teszi a hibát diagnosztizálhatóvá egyetlen homályos tünet helyett.

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

Olvassa ezt a három kimenetet együtt, ne egyenként. A továbbítás nélküli masquerade-szabály olyan klienst hoz létre, amely csatlakozik és semmit nem ér el, ami kliensoldalról pontosan úgy néz ki, mint egy útvonal-hiba, és az embereket a rossz fájlhoz küldi. A szűrőtábla az a hely is, ahol egy túl széles accept elrejtőzik, ezért nézze meg ott az alapértelmezett szabályzatát is.

Ellenőrizze az újratöltést, az elutasítást és a VPN elvesztését

Három megfigyelés tesz ki egy teljes elfogadási tesztet: az újratöltés sikerül, egy engedélyezett kliensművelet működik, és egy elutasítandó kérés ténylegesen elutasításra kerül. A harmadik az, amelyet kihagynak, és ez az egyetlen bizonyíték arra, hogy a szabályzat egyáltalán tesz valamit.

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

Ezután tesztelje azt a hibát, amelyre tervezett. Ejtse ki az alagutat, és figyelje, mit tesz a gazdagép, mert egy szabályzat, amely csak addig működik, amíg a VPN fut, kimondatlan függőségű szabályzat. Utána töltsön újra még egyszer, hogy bizonyítsa: a fájl, nem pedig valamilyen maradék futó állapot állítja elő a működő eredményt.

Az IPv4 NAT-ja semmit nem mond az IPv6-ról, ezért ugyanabban a megjegyzésben adja meg a tervezett lefedettséget mindkét családra, mint a szabály. A cél egy koherens, kezelt szabályzat, és egy töredék, amely véletlenül elemezhető volt, nem bizonyíték erre.