NAT pre LAN cez tun0 na OpenBSD VPN bráne

Dvaja inžinieri s tou istou OpenBSD bránou vám často dajú dve rôzne sady pravidiel na dosiahnutie vzdialenej siete a obe sa dajú obhájiť. Voľba medzi prekladom zdroja a spätnou trasou vôbec nie je otázkou syntaxe. Všetko závisí od toho, čo druhá strana už vie o 192.168.88.0/24 a čo potrebujete zachovať v logoch. Pomýlite sa tu a riadok nat-to bude vyzerať dokonale správne, kým odpovede zmiznú vo vzdialenej predvolenej bráne.

Smerovanie a prepisovanie odpovedajú na rôzne otázky

Smerovacia tabuľka rozhoduje, že 172.20.0.0/16 je dostupné cez tun0, a toto rozhodnutie padá predtým, než sa konzultuje akýkoľvek pf preklad. Preklad zdroja potom zmení hlavičku paketu, takže vzdialený koniec vidí adresu tunela brány namiesto hostiteľa LAN. Ani jeden mechanizmus nenahrádza druhý: pravidlo nat nemôže vytvoriť trasu a trasa nedokáže presvedčiť vzdialený router, ktorý nikdy nepočul o vašej súkromnej podsieti. Keď druhej strane chýba spätná cesta, odpovede sa zahodia alebo sa odošlú na jej predvolenú bránu, a žiadne ladenie pravidiel to nenapraví.

Jednoducho povedané, preposielanie odpovedá na to, kam premávka ide, a preklad na to, odkiaľ sa zdá, že prichádza. Držte ich v oddelených myšlienkových škatuliach, kým navrhujete sadu pravidiel.

Tri podmienky, ktoré rozhodujú

Položte tri otázky v poradí a návrh sa zvyčajne vyberie sám. Má vzdialená sieť statickú trasu smerujúcu na adresu tunela pre 192.168.88.0/24, alebo jej správca ovláda routery na tej ceste? Ak áno, nechajte adresy LAN cestovať nezmenené a preklad úplne vynechajte. Potrebujete viditeľnosť pre každého klienta na druhej strane, či už pre prístupovú politiku alebo pre auditnú stopu? Ak áno, zachovanie zdroja stojí za prácu so smerovaním. Je adresa tunela dosť stabilná na to, aby sa zapísala do vzdialenej trasy, alebo sa mení medzi opätovnými pripojeniami?

Ak je ktorákoľvek odpoveď nie alebo neznáma, nat-to je pragmatická možnosť a zároveň tá vratná. Pravidlo prekladu zmizne jediným riadkom, keď druhá strana pridá poriadnu trasu. Spätná trasa, ktorá nikdy nebola nainštalovaná, vás stojí jedno vlákno podpory zakaždým, keď sa niekto opýta, prečo tunel funguje len jedným smerom.

Umiestnite fragment tak, aby ho pf skutočne vyhodnotil

Fragment nižšie predpokladá, že LAN je 192.168.88.0/24, vzdialená sieť je 172.20.0.0/16 a rozhranie tunela je tun0. Nič v ňom nevyberá ďalší skok. Iba prepisuje zdroj na paketoch, ktoré už vychádzajú cez tunel.

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 tom prvom riadku nesú väčšinu váhy. Zátvorky okolo tun0 hovoria pf, aby pri každom zostavení záznamu stavu prečítal adresu rozhrania, čo je dôležité, keď sa tunel po opätovnom pripojení prečísluje. Slovo match znamená, že pravidlo prepíše a potom prepadne ďalej, takže samostatné pravidlo pass musí tok stále prepustiť. Rozhranie uvedené v riadku match musí byť tiež to, ktoré vyberie smerovacia tabuľka, inak pf vyhodnotí pravidlo na inej odchádzajúcej ceste, než akou paket skutočne ide.

Nezabudnite na stranu jadra. Preposielanie IPv4 musí byť zapnuté a stavové pravidlá pass pre tunel a LAN musia existovať skôr, než to všetko získa zmysel. Sekcia PF NAT v OpenBSD FAQ je správnym zdrojom pre poradie kľúčových slov.

Overte sadu pravidiel, kým uveríte prevádzke

Najprv skontrolujte syntax pomocou pfctl -nf /etc/pf.conf, ktorý súbor analyzuje bez jeho načítania. Potom načítajte politiku a prečítajte, čo jadro skutočne drží, pretože pravidlo, ktoré sa čisto analyzovalo, môže byť stále zatienené alebo pripojené k nesprávnemu rozhraniu. pfctl -sn vypisuje pravidlá prekladu v ich načítanej podobe a pfctl -sr vypisuje pravidlá filtrovania v poradí vyhodnocovania.

Potom sledujte kábel. Na bráne tcpdump -ni tun0 'host 172.20.0.10' ukazuje, či zdrojová adresa vychádzajúca z tunela je adresou tunela alebo hostiteľa LAN. Rýchly netstat -rn -f inet potvrdí, na ktoré rozhranie sa cieľ rozkladá. Keď prevádzka začne tiecť, pfctl -ss vypíše záznamy stavu; ak tok nevytvoril stav, paket nikdy nenarazil na pravidlo, ktoré by ho vytvorilo.

Ak strana tunela vyzerá správne a odpovede stále neprichádzajú, prestaňte upravovať pf. Zvyšná porucha je na vzdialenom routeri, kde sa odpoveď posiela na súkromnú adresu, ktorú tá strana nedokáže dosiahnuť.

Keď preklad stojí viac, než ušetrí

Preklad skrýva klientov a niekedy je to práve nesprávna výmena. Prekrývajúce sa podsiete sú jeden prípad: ak druhá strana interne používa tiež 192.168.88.0/24, prezentovanie hostiteľov LAN ako brány zhoršuje kolíziu namiesto toho, aby ju zmiernilo. Politiky IPsec, ktoré vyberajú prevádzku podľa páru adries, sú druhý prípad, pretože databáza bezpečnostnej politiky sa porovnáva pred prekladom a nikdy nevidí prepísaný paket. Akékoľvek nasadenie, ktoré účtuje, obmedzuje alebo audituje na používateľa, tiež stráca identitu, ktorú potrebuje v okamihu, keď sa zdroj zrúti na jednu adresu.

Prenosné deriváty pf sú samostatná pasca. Produkty, ktoré generujú vlastné súbory pravidiel, očakávajú, že NAT sa bude konfigurovať cez ich rozhranie, a ručne upravené fragmenty sa pri ďalšom načítaní prepíšu. Sady pravidiel skopírované z príručiek napísaných pred vznikom kľúčového slova match sa na aktuálnom jadre nenačítajú, preto preneste syntax a prečítajte chybu namiesto hádania.

Rozhodovacie pravidlo, ktoré prežije kontakt s reálnymi sieťami, je krátke: nainštalujte spätnú trasu, keď môžete, prekladajte, keď nemôžete, a zapíšte, ktorá z troch podmienok vás k tej voľbe priviedla. Tá poznámka ušetrí ďalšiemu človeku popoludnie.