Omezit bránu OpenVPN na jednu LAN pomocí pravidel UFW

Rozhodněte o povolení dřív, než otevřete soubor firewallu: ověření klienti smějí otevírat spojení do jedné konkrétní podsítě a brána musí odmítnout každou jinou tranzitní cestu, i když si klient nainstaluje další trasy. Ta věta je návrh a každé pravidlo níž existuje proto, aby ho vynutilo. Cokoli širšího, třeba celý privátní adresní prostor, odchod do internetu tunelem nebo provoz mezi rovnocennými uzly, je jiný návrh, který potřebuje vlastní rozhodnutí. Pravidla jsou také záměrně nudná, protože chytrý firewall je ten, který později nikdo nedokáže auditovat.

Nejprve zapište topologii a povolení

Příklad používá server Community OpenVPN s uživatelským zařízením TUN nazvaným tun0, fond klientů 10.77.0.0/24 a jednu připojenou podsíť 192.168.60.0/24 na lan0. Přeposílání IPv4 už funguje a LAN už má zpáteční trasu do fondu, takže nic zde nezávisí na překladu mezi nimi.

Firewall na tomto hostiteli vlastní UFW a žádná sada pravidel v kontejneru ani samostatná tabulka nftables nesmí nainstalovat dřívější cestu přijetí. Zkratka hardwarového odlehčení toku, která obchází filtr, by ochranné řetězce proměnila v dekoraci, proto potvrďte, že žádná není aktivní. Nechte vlastní přeposílání client-to-client OpenVPN vypnuté, protože provoz mezi rovnocennými uzly, který nikdy nepřejde filtr operačního systému jím nelze omezit. Externí posluchač a administrativní pravidla zůstávají, jak jsou, protože tato změna řídí dešifrovaný provoz tunelu, místo aby nahrazovala firewall.

Umístěte stráže před raná přijetí UFW

Povolení trasy následované odmítnutím na striktní hranici nestačí. Výchozí pravidla before přijímají navázaný provoz a vybrané ICMP dřív, než se vezme v úvahu jakékoli uživatelské pravidlo, takže tok povolený minulý týden může zůstat mimo nové omezení cíle jen proto, že má stále stav. Zálohujte soubory UFW a před úpravou mějte otevřenou konzolu mimo pásmo.

V sekci *filter souboru /etc/ufw/before.rules deklarujte dva řetězce vedle stávajících deklarací a před jakýmkoli řádkem pravidla.

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

Hned po deklaracích a před povoleními pro vstup a přeposílání do nich skočte a definujte, co propouštějí.

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

Zbytek sekce a její řádek COMMIT ponechte. Vložení druhé tabulky filtru nebo smazání nesouvisejících pravidel je způsob, jak se změna firewallu promění ve výpadek, a soubor je jedno restartování od toho, aby byl jedinou kopií, na které záleží.

Přečtěte si, co každá stráž propouští a odmítá

První řetězec pokračuje ve zpracování jen tehdy, když je zdroj ve fondu, cíl je ona jediná podsíť, výstupní rozhraní je LAN a paket putuje v původním směru svého toku. Vše ostatní přicházející z tunelu se zahodí, včetně zdroje mimo fond a jakéhokoli cíle za povolenou podsítí.

Paket mezi rovnocennými uzly vstupuje a vystupuje přes tun0, takže selže v testu rozhraní LAN ještě předtím, než se vůbec dostane ke kontrole cíle. Nová spojení z LAN směrem ke klientům také selhávají v testu směru odpovědi, což ve výchozím nastavení zavírá zpětnou cestu volání.

Cíl RETURN udržuje běžnou politiku UFW ve hře. Tyto řetězce filtrují a povolení trasy, které přidáte potom, stále rozhoduje, zda bude přeživší paket přijat. Právě toto oddělení vám později umožní změnit povolenou podsíť na jednom místě. Kdyby stráže pakety přijímaly rovnou, každé budoucí pravidlo by se muselo přidávat dvakrát.

Povolte podsíť a zavřete boční dveře

Nejprve zobrazte náhled povolení trasy, potom zrušte příznak náhledu, abyste ho použili: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. Poté zkontrolujte pořadí uživatelských pravidel, protože dřívější odmítnutí stále poráží pozdější povolení. Povolení pro celou podsíť je také špatný tvar, když má být dostupný jen port HTTPS jednoho hostitele.

Všimněte si, co dělá zahození vstupu: klienti tunelu nedosáhnou na žádnou službu přímo na bráně, včetně posluchače DNS vázaného na její adresu v LAN. Hostování DNS tam vyžaduje záměrnou výjimku před zahozením a revidovanou smlouvu o povolení. Pokud UFW spravuje IPv6, přidejte odpovídající zahození pro tun0 v before6.rules také, protože seznam cílů IPv4 nic neříká o paketech IPv6.

Ověřte načtenou politiku, ne náhled

Zobrazte náhled znovunačtení, použijte ho v maintenance okně a přečtěte živou sadu pravidel.

sudo ufw --dry-run reload
sudo ufw show raw

Potvrďte, že stráže tunelu jsou před výchozími povoleními stavu a ICMP. Obyčejný ufw status nezobrazuje ručně upravená pravidla before, a proto operátoři usoudí, že pravidlo chybí, když je ve skutečnosti načtené. Čtěte surový výpis shora dolů, místo abyste hledali fragment. Pokud se stráže objeví až po povolení stavu, hranice nedělá to, co soubor naznačuje.

Potom testujte chování, ne text. Otevřete nové spojení k povolenému hostiteli a sledujte odpověď, namiřte neškodný požadavek na cíl mimo podsíť a potvrďte, že umře, zkuste spojení mezi rovnocennými uzly, zkuste službu lokální na bráně a zkuste nevyžádané spojení z LAN ke klientovi. Zahrňte jeden tok mimo rozsah, který existoval před změnou, a vymažte jen ten tok, místo abyste propláchli celou sledovací tabulku stroje.

Zapište omezení vedle pravidel: tohle omezuje tranzit a nic jiného. Nezabrání klientovi použít vlastní internetové připojení, nezabrání povolenému hostiteli v LAN přeposílat provoz dál a nenahrazuje ověřování uvnitř povolených služeb.