Kam patří VPN NAT v before.rules UFW a jak ho otestovat

NAT řádek v before.rules musí ležet uvnitř platné sekce tabulky s COMMIT. Kandidáta projděte pomocí iptables-restore --test, než znovu načtete UFW.

Pravidlo NAT, které funguje při zadání do shellu, selže při vložení do before.rules, protože tento soubor není skript. Je to dokument ve formátu obnovy se sekcemi tabulek, deklaracemi řetězců a značkou COMMIT pro každou tabulku. Řádek na špatném místě buď přeruší celou obnovu, nebo tiše zahodí pravidla, o kterých jste si mysleli, že tam jsou. Následující postup umístí fragment tam, kde ho rámec očekává, a výsledek prokáže před dalším načtením.

Příkaz v shellu není soubor pro obnovu

Řádek začínající iptables -t nat je instrukce pro binárku iptables, zatímco soubor, který UFW čte, je popis kompletní sady pravidel. Rozdíl není kosmetický: formát obnovy musí vědět, ve které tabulce se nachází, které řetězce existují a kde tabulka končí. Příkaz vložený do tohoto dokumentu je buď syntaktická chyba, nebo, což je horší, pravidlo připojené ke špatné tabulce. Rámec načítá tyto soubory nástroji pro obnovu právě proto, že jsou deklarativní, a ne sekvenční.

Dokument se také načítá jako celek, takže jedna vadná sekce může zastavit uplatnění zbytku souboru. Malá chyba ve fragmentu NAT tak s sebou strhne i pravidla filtru, a přesně tak se ze změny firewallu stane výpadek.

Umístěte fragment do existující sekce tabulky

Fragment NAT má tvar a tvar je důležitější než text pravidla uvnitř. Hlavička tabulky otevírá sekci, deklarace řetězců zavádějí počítadla, následují pravidla a COMMIT sekci uzavírá.

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

Pula a rozhraní výše jsou zástupné hodnoty pro vaše vlastní; struktura je část, kterou stojí za to kopírovat. Pokud soubor už obsahuje sekci *nat, přidejte pravidlo do této sekce, místo abyste otevírali druhou, protože formát očekává jeden COMMIT na tabulku a dvě sekce pro stejnou tabulku jsou oprava čekající na událost. Ponechte definice řetězců distribuce nedotčené, včetně těch, které dodavatel přidal pro svou integraci. Příručka rámce UFW dokumentuje soubory before, user a after spolu s požadavkem odpovídajícího COMMIT.

Pokud se soubor ukáže prázdný, nevyplňujte ho podle návodu. Ověřte, který balíček ho vlastní a jaká je skutečná živá politika, protože prázdný trvalý soubor nedokazuje, že jádro nedrží žádná pravidla, a načtená sada pravidel nedokazuje, že příští načtení bude mít úplný soubor ke čtení. Nejprve obnovte podporovanou základní úroveň a poté na ni znovu aplikujte změny pracoviště.

Otestujte kandidáta bez aplikace

Nástroj pro obnovu umí sadu pravidel analyzovat a sestavit, aniž by ji aplikoval, což je nejlevnější dostupný test. Spusťte ho na chráněné kopii, ne na živém souboru, a čtěte text chyby, ne jen návratový kód. Selhání analýzy pojmenuje řádek a obvykle tabulku, což je víc, než vám řekne neúspěšné načtení.

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

Projití této kontroly dokazuje, že se dokument analyzuje, a nic víc. Nedokazuje, že kandidát stále obsahuje každý řetězec, na kterém UFW závisí, že povoluje jen zamýšlené zdroje, nebo že vzdálená správa zůstává dostupná. To jsou samostatné revize a poslední si zaslouží druhou relaci otevřenou před začátkem.

Vyberte nástroj odpovídající nainstalovanému backendu a rodině adres. Hostitel spouštějící backend nft přes vrstvu kompatibility potřebuje odpovídající příkaz a pravidla IPv6 žijí v úplně jiném souboru.

Držte předávání, NAT a přístupovou politiku odděleně

Překlad zdroje řeší problém adresování a nic nedává. Předávání je samostatné oprávnění řízené sysctl a tabulkou filtru a je to právě ono, na které lidé zapomínají, když tunel směruje, ale nepropouští provoz. Politika přístupu je třetí rozhodnutí o tom, které zdroje mohou dosáhnout na které služby, a žádné pravidlo NAT ji nevyjadřuje. Právě oddělení těchto tří věcí činí poruchu diagnostikovatelnou místo jediného vágního příznaku.

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

Čtěte tyto tři výstupy společně, ne jeden po druhém. Pravidlo masquerade s vypnutým předáváním vytvoří klienta, který se připojí a nikam nedosáhne, což z pohledu klienta vypadá přesně jako porucha směrování a posílá lidi ke špatnému souboru. Tabulka filtru je také místem, kde se skrývá příliš široký accept, takže se tam podívejte i na její výchozí politiku.

Ověřte načtení, odmítnutí a ztrátu VPN

Tři pozorování tvoří úplný akceptační test: načtení uspěje, povolená operace klienta funguje a požadavek, který má být odmítnut, je skutečně odmítnut. Třetí z nich se přeskakuje a je jediným důkazem, že politika vůbec něco dělá.

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

Poté otestujte poruchu, pro kterou jste navrhovali. Shodte tunel a sledujte, co hostitel dělá, protože politika, která funguje jen dokud je VPN zapnutá, je politika s nevyslovenou závislostí. Poté znovu načtěte, abyste prokázali, že funkční výsledek dává soubor, a ne nějaký zbytkový běžící stav.

NAT pro IPv4 neříká o IPv6 nic, takže uveďte zamýšlené pokrytí obou rodin ve stejné poznámce jako pravidlo. Cílem je soudržná spravovaná politika a fragment, který se náhodou analyzoval, není jejím důkazem.

Související články