Zablokovat jednoho klienta OpenVPN z LAN bez zastavení tunelu
Připněte tunelovou adresu klienta k jeho certifikátu, zahoďte jeho LAN provoz na začátku FORWARD a poté ověřte IPv6, sledované relace a přežití restartu.
Jeden klient na vašem serveru OpenVPN musí ztratit přístup do LAN, zatímco všechny ostatní tunely zůstanou běžet. Když to hledáte, nejlepší odpověď obvykle říká, že to démon neumí, což je jen napůl pravda: OpenVPN nemá firewall pro jednotlivé klienty, ale hostitel, který tunel ukončuje, už pakety filtruje. Dvě rozhodnutí, na kterých záleží, jsou identita, kterou blokujete, a pozice pravidla. Udělejte je správně a změna se stane jedním řádkem, který můžete otestovat a odstranit.
Připněte klienta, než napíšete pravidlo
OpenVPN přiděluje tunelové adresy z fondu, takže 10.8.0.6 je místo, ne osoba. Když relace skončí, pronájem se vrátí a může být předán dalšímu připojení, což znamená, že pravidlo napsané proti této adrese sleduje místo, ne uživatele. Nejprve se tedy rozhodněte, co vlastně blokujete: adresu pro krátký experiment, nebo certifikát pro někoho, koho chcete držet venku.
Chcete-li adresu svázat s certifikátem, vytvořte soubor v adresáři uvedeném v client-config-dir a dejte souboru přesně common name certifikátu. Vložte do něj jednu direktivu, ifconfig-push 10.8.0.6 255.255.255.0, a tento klient si při opětovném připojení zachová stejnou tunelovou adresu. Aby to platilo, musí existovat dvě nastavení: client-config-dir musí být deklarováno v konfiguraci serveru a posílaná adresa musí ležet v podsíti, kterou server umí směrovat. Když jedno chybí, soubor se ignoruje bez chyby, což dělá další test firewallu zavádějícím.
Dočasný blok může použít adresu z fondu, pokud tiket zaznamenává, která relace ji v té době držela.
Pořadí rozhoduje, zda se zahazování provede
Na linuxové bráně, která přeposílá mezi tunelem a LAN, procházejí pakety řetězem FORWARD. Přečtěte si příkaz níže jako větu: vložit na začátek FORWARD, zachytit provoz vstupující z tun0, od tohoto jediného hostitele, směřující do podsítě LAN, a zahodit ho.
iptables -I FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROPPrávě -I způsobí, že pravidlo běží. Přidáno přes -A skončí pod jakýmkoli širokým povolením pro tunelovou podsíť a nikdy neuvidí paket. Ověřte pozici pomocí iptables -vnL FORWARD --line-numbers a čtěte i čítače: zahození nahoře, které nic nepočítá, znamená, že provoz přichází jinou cestou.
Vlastní LAN adresa brány je jiná cesta. Pakety poslané samotnému boxu jdou do INPUT, ne do FORWARD, takže klient může ztratit hostitele v LAN a přesto otevřít administraci routeru. Když na tom záleží, přidejte odpovídající pravidlo INPUT.
Co filtr nevidí
Filtrování probíhá při vyhodnocení paketu, takže navázaná TCP relace může pokračovat, dokud se nezavře nebo neresetuje. Pokud má blok zabrat okamžitě, vymažte sledované toky pro tento zdroj pomocí conntrack -D -s 10.8.0.6 poté, co pravidlo přidáte. Pokud je několik sekund překryvu přijatelných, zapište tuto volbu, místo abyste ji nechali implicitní. Ať tak či onak, další člověk musí vědět, zda pravidlo zastavuje živý provoz, nebo jen nová spojení.
Provoz mezi peery se nikdy nedotkne firewallu hostitele. Když je zapnuto client-to-client, OpenVPN tyto pakety přeposílá uvnitř démona, takže je nevidí ani FORWARD, ani INPUT. Jediným řešením je vypnout client-to-client nebo přijmout, že se peery mohou navzájem dostat; pravidlo iptables tento provoz neuvidí.
IPv6, firmware a přežití restartu
Pravidlo IPv4 neříká nic o IPv6. Pokud tunel i LAN nesou obě rodiny, musí ekvivalentní pravidlo existovat v ip6tables, nebo v sadě pravidel nftables, která na tomto hostiteli vlastní politiku. Firmware routeru často skrývá netfilter za vlastní abstrakcí, takže syntaxe a názvy tabulek zkopírované z fóra nemusí platit.
Na OpenWrt je dokumentovanou cestou položka konfigurace firewallu, nikoli ručně psaný řádek iptables, a ručně psaný řádek může při načtení firewallu zmizet. Jiné distribuce obnovují pravidla přes netfilter-persistent, bootovací jednotku nebo úložiště výrobce a tyto mechanismy nejsou zaměnitelné. Dokažte ten, který jste zvolili, restartem, protože načtení procvičuje jinou cestu.
Ověřte po cestách a potom čistě vraťte
Testujte každou cestu zvlášť, protože jedna úspěšná kontrola skrývá ostatní. Blokovaný klient by měl stále dosáhnout internetu tunelem, ale selhat proti hostiteli v LAN, druhý klient by měl dosáhnout stejného hostitele a adresa brány i cesta k peeru potřebují každá vlastní pozorování. Zapište výsledky vedle pravidla, aby další změna měla základ. Tabulka níže je sada, kterou stojí za to v tiketu ponechat.
| Cesta | Očekáváno s pravidlem | Když selže |
|---|---|---|
| Blokovaný klient k hostiteli v LAN | Žádná odpověď | Pravidlo je pod povolením, nebo zdroj neodpovídá |
| Blokovaný klient k internetu | Funguje přes tun0 | Pravidlo je příliš široké, bez shody cíle |
| Druhý klient ke stejnému hostiteli v LAN | Funguje | Pravidlo odpovídalo více než zamýšlenému hostiteli |
| Blokovaný klient k LAN adrese brány | Blokováno jen s odpovídajícím pravidlem INPUT | Pravidlo INPUT chybí |
| Blokovaný klient k tunelové adrese peeru | Stále funguje | client-to-client je zapnuto a mimo dosah firewallu |
Vrácení je smazání podle specifikace, ne flush: iptables -D FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP odstraní přesně tento záznam a zbytek řetězu nechá nedotčený. Odstraňte stejný řádek ze souboru, který pravidla obnovuje při startu, znovu jej načtěte a potvrďte, že klient znovu dosáhne hostitele v LAN. Flush FORWARD by zrušil i pravidla, která jste nenapsali, což mění vrácení v druhý incident.
Než tiket zavřete, potvrďte tři věci: připnutá adresa odpovídá certifikátu, pravidlo je nad povoleními s nenulovým čítačem a soubor perzistence obsahuje stejné pravidlo, které jste testovali. Pokud něco z toho chybí, blok je iluze v shell relaci.