NAT sítě LAN přes tun0 na VPN bráně OpenBSD

Dva inženýři se stejnou bránou OpenBSD vám často dají dvě různé sady pravidel pro dosažení vzdálené sítě a obě lze obhájit. Volba mezi překladem zdroje a vratnou trasou není vůbec otázkou syntaxe. Jde o to, co vzdálená strana už ví o 192.168.88.0/24 a co potřebujete mít ve svých protokolech. Udělejte to špatně a řádek nat-to bude vypadat naprosto správně, zatímco odpovědi zmizí ve vzdálené výchozí bráně.

Směrování a přepisování odpovídají na různé otázky

Směrovací tabulka rozhoduje, že 172.20.0.0/16 je dostupné přes tun0, a toto rozhodnutí padne dříve, než se konzultuje jakýkoli překlad pf. Překlad zdroje pak změní hlavičku paketu, aby vzdálená strana viděla adresu tunelu brány místo hostitele LAN. Ani jeden mechanismus nenahrazuje druhý: pravidlo nat nedokáže vytvořit trasu z ničeho a trasa nepřesvědčí vzdálený router, který o vaší privátní podsíti nikdy neslyšel. Když vzdálené straně chybí vratná cesta, odpovědi se zahazují nebo přeposílají její výchozí bráně a žádné ladění pravidel to nespraví.

Jednoduše řečeno, předávání odpovídá na to, kam provoz jde, a překlad na to, od koho se zdá, že přichází. Při návrhu sady pravidel je držte v oddělených myšlenkových boxech.

Tři podmínky, které to rozhodují

Položte tři otázky v pořadí a návrh se obvykle vybere sám. Má vzdálená síť statickou trasu ukazující na adresu tunelu pro 192.168.88.0/24, nebo její správce ovládá routery na této cestě? Pokud ano, nechte adresy LAN cestovat nezměněné a překlad úplně přeskočte. Potřebujete na vzdálené straně viditelnost pro jednotlivé klienty, ať už pro přístupovou politiku, nebo pro auditní stopu? Pokud ano, zachování zdroje stojí za tu práci se směrováním. Je adresa tunelu dostatečně stabilní, aby se dala zapsat do vzdálené trasy, nebo se mezi opětovnými připojeními mění?

Pokud je jakákoli odpověď ne nebo neznámá, nat-to je pragmatická volba a je také vratná. Pravidlo překladu se odstraní jedním řádkem, jakmile vzdálená strana přidá řádnou trasu. Vratná trasa, která nebyla nikdy nainstalována, vás stojí vlákno podpory pokaždé, když se někdo ptá, proč tunel funguje jen jedním směrem.

Umístěte fragment tam, kde ho pf skutečně vyhodnotí

Fragment níže předpokládá, že LAN je 192.168.88.0/24, vzdálená síť je 172.20.0.0/16 a rozhraní tunelu je tun0. Nic v něm nevolí další skok. Pouze přepisuje zdroj u paketů, které už odcházejí tunelem.

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

Dva detaily v onom prvním řádku nesou většinu váhy. Závorky kolem tun0 říkají pf, aby při každém sestavení stavového záznamu přečetl adresu rozhraní, což je důležité, když se tunel po opětovném připojení přečísluje. Slovo match znamená, že pravidlo přepíše a pak propadne, takže samostatné pravidlo pass musí tok stále povolit. Rozhraní uvedené v řádku match musí být také to, které vybere směrovací tabulka, jinak pf vyhodnotí pravidlo na jiné odchozí cestě, než jakou paket skutečně jde.

Nezapomeňte na stranu jádra. Musí být zapnuto předávání IPv4 a stavová pravidla pass pro tunel a LAN musí existovat, než cokoli z toho získá smysl. Sekce PF NAT v OpenBSD FAQ je správný odkaz pro pořadí klíčových slov zde.

Ověřte sadu pravidel, než provozu uvěříte

Nejprve zkontrolujte syntaxi pomocí pfctl -nf /etc/pf.conf, který soubor analyzuje, aniž by jej načetl. Poté načtěte politiku a přečtěte si, co jádro skutečně drží, protože pravidlo, které se čistě analyzovalo, může být stále zastíněno nebo připojeno ke špatnému rozhraní. pfctl -sn vypisuje pravidla překladu v načtené podobě a pfctl -sr vypisuje pravidla filtrování v pořadí vyhodnocování.

Dále sledujte drát. Na bráně tcpdump -ni tun0 'host 172.20.0.10' ukazuje, zda zdrojová adresa opouštějící tunel je adresa tunelu, nebo hostitel LAN. Rychlý netstat -rn -f inet potvrdí, na které rozhraní se cíl přeloží. Jakmile provoz teče, pfctl -ss vypíše stavové záznamy; pokud tok nevytvořil žádný stav, paket nikdy neodpovídal pravidlu, které nějaký vytváří.

Pokud strana tunelu vypadá správně a odpovědi přesto nikdy nepřijdou, přestaňte upravovat pf. Zbývající závada je na vzdáleném routeru, kde se odpověď posílá k privátní adrese, na kterou ta strana nedosáhne.

Když překlad stojí víc, než kolik ušetří

Překlad skrývá klienty a někdy je to přesně špatná výměna. Překrývající se podsítě jsou jeden případ: pokud vzdálená strana také interně používá 192.168.88.0/24, prezentace hostitelů LAN jako brány kolizi zhorší, ne zlepší. IPsec politiky, které vybírají provoz podle dvojice adres, jsou další, protože databáze bezpečnostní politiky se porovnává před překladem a nikdy nevidí váš přepsaný paket. Každé nasazení, které účtuje, omezuje nebo audituje po uživatelích, také ztrácí identitu, kterou potřebuje ve chvíli, kdy se zdroj zhroutí na jednu adresu.

Přenosné deriváty pf jsou samostatná past. Produkty, které si generují vlastní soubory pravidel, očekávají, že NAT se nakonfiguruje přes jejich rozhraní, a ručně upravené fragmenty se při dalším načtení přepíšou. Sady pravidel zkopírované z návodů napsaných před existencí klíčového slova match se na aktuálním jádru nenačtou, takže syntaxi přeneste a chybu si přečtěte, místo abyste hádali.

Rozhodovací pravidlo, které přežije střet s reálnými sítěmi, je krátké: nainstalujte vratnou trasu, když můžete, překládejte, když nemůžete, a zapište, která ze tří podmínek vás k volbě přivedla. Ta poznámka ušetří dalšímu člověku odpoledne.