Kam patrí VPN NAT v before.rules UFW a ako ho otestovať

Pravidlo NAT, ktoré funguje pri zadaní do shellu, zlyhá pri vložení do before.rules, pretože tento súbor nie je skript. Je to dokument vo formáte obnovy so sekciami tabuliek, deklaráciami reťazcov a značkou COMMIT pre každú tabuľku. Riadok na nesprávnom mieste buď preruší celú obnovu, alebo potichu zahodí pravidlá, o ktorých ste si mysleli, že tam sú. Postup nižšie umiestni fragment tam, kde ho rámec očakáva, a pred ďalším načítaním dokáže výsledok.

Príkaz v shelli nie je súbor na obnovu

Riadok začínajúci iptables -t nat je inštrukcia pre binárku iptables, zatiaľ čo súbor, ktorý UFW číta, je opis kompletnej sady pravidiel. Rozdiel nie je kozmetický: formát obnovy musí vedieť, v ktorej tabuľke sa nachádza, ktoré reťazce existujú a kde tabuľka končí. Príkaz vložený do tohto dokumentu je buď syntaktická chyba, alebo, čo je horšie, pravidlo pripojené k nesprávnej tabuľke. Rámec načíta tieto súbory nástrojmi obnovy práve preto, že sú deklaratívne, a nie sekvenčné.

Dokument sa načítava aj ako celok, takže jedna chybná sekcia môže zastaviť uplatnenie zvyšku súboru. Malá chyba vo fragmente NAT tak so sebou strhne aj pravidlá filtra, a presne tak sa zo zmeny firewallu stane výpadok.

Umiestnite fragment do existujúcej sekcie tabuľky

Fragment NAT má tvar a tvar je dôležitejší ako text pravidla v ňom. Hlavička tabuľky otvára sekciu, deklarácie reťazcov zavádzajú počítadlá, nasledujú pravidlá a COMMIT sekciu uzatvára.

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

Pula a rozhranie vyššie sú zástupné hodnoty pre vaše vlastné; štruktúra je časť, ktorú stojí za to kopírovať. Ak súbor už obsahuje sekciu *nat, pridajte pravidlo do tejto sekcie namiesto otvárania druhej, pretože formát očakáva jeden COMMIT na tabuľku a dve sekcie pre rovnakú tabuľku sú oprava čakajúca na udalosť. Nechajte definície reťazcov distribúcie nedotknuté, vrátane tých, ktoré dodávateľ pridal pre svoju vlastnú integráciu. Príručka rámca UFW dokumentuje súbory before, user a after spolu s požiadavkou na zodpovedajúci COMMIT.

Ak sa súbor ukáže prázdny, nevyplňujte ho podľa návodu. Overte, ktorý balík ho vlastní a aká je skutočná živá politika, pretože prázdny trvalý súbor nedokazuje, že jadro nemá pravidlá, a načítaná sada pravidiel nedokazuje, že ďalšie načítanie bude mať úplný súbor na čítanie. Najprv obnovte podporovanú základnú úroveň a potom na ňu znova aplikujte zmeny pracoviska.

Otestujte kandidáta bez aplikovania

Nástroj obnovy dokáže sadu pravidiel analyzovať a zostaviť bez toho, aby ju aplikoval, a to je najlacnejší dostupný test. Spustite ho na chránenej kópii, nie na živom súbore, a čítajte text chyby, nielen návratový kód. Zlyhanie analýzy pomenuje riadok a zvyčajne tabuľku, čo je viac, než vám povie neúspešné načítanie.

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

Prejdenie tejto kontroly dokazuje, že sa dokument analyzuje, a nič viac. Nedokazuje, že kandidát stále obsahuje každý reťazec, na ktorom UFW závisí, že povoľuje iba zamýšľané zdroje, alebo že vzdialená správa zostáva dostupná. To sú samostatné recenzie a posledná si zaslúži druhú reláciu otvorenú pred začiatkom.

Vyberte nástroj zodpovedajúci nainštalovanému backendu a rodine adries. Hostiteľ spúšťajúci backend nft cez vrstvu kompatibility potrebuje zodpovedajúci príkaz a pravidlá IPv6 žijú v úplne inom súbore.

Držte preposielanie, NAT a prístupovú politiku oddelene

Preklad zdroja rieši problém adresovania a nič nedáva. Preposielanie je samostatné oprávnenie riadené sysctl a tabuľkou filtra, a práve naň ľudia zabúdajú, keď tunel smeruje, ale neprepúšťa prevádzku. Politika prístupu je tretie rozhodnutie o tom, ktoré zdroje môžu dosiahnuť ktoré služby, a žiadne pravidlo NAT ju nevyjadruje. Práve oddelenie týchto troch robí poruchu diagnostikovateľnou namiesto jediného vágneho príznaku.

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

Čítajte tieto tri výstupy spolu, nie jeden po druhom. Pravidlo masquerade s vypnutým preposielaním vytvorí klienta, ktorý sa pripojí a nikam sa nedostane, čo z pohľadu klienta vyzerá presne ako porucha smerovania a posiela ľudí k nesprávnemu súboru. Tabuľka filtra je aj miesto, kde sa skrýva príliš široký accept, takže sa tam pozrite aj na jej predvolenú politiku.

Overte načítanie, odmietnutie a stratu VPN

Tri pozorovania tvoria úplný akceptačný test: načítanie uspeje, povolená operácia klienta funguje a požiadavka, ktorá má byť odmietnutá, je skutočne odmietnutá. Tretie sa preskakuje a je jediným dôkazom, že politika vôbec niečo robí.

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

Potom otestujte poruchu, pre ktorú ste navrhovali. Zhodte tunel a sledujte, čo hostiteľ robí, pretože politika, ktorá funguje len dovtedy, kým je VPN zapnutá, je politika s nevyslovenou závislosťou. Potom znova načítajte, aby ste dokázali, že funkčný výsledok dáva súbor, a nie nejaký zvyškový bežiaci stav.

NAT pre IPv4 nehovorí o IPv6 nič, preto uveďte zamýšľané pokrytie oboch rodín v tej istej poznámke ako pravidlo. Cieľom je súdržná spravovaná politika a fragment, ktorý sa náhodou analyzoval, nie je jej dôkazom.