Hostitel iptables jen pro VPN: pojmenujte zařízení tun, ne tun+

Napsat -o tun+ vypadá jako přesná instrukce, ale ve skutečnosti je to zástupný znak, který odpovídá každému tunelu, jejž jádro má. Druhý klient VPN, kontejnerový most nebo rozhraní, které zůstalo po spadlé relaci, všechny ho splňují, a hostitel pak propustí provoz, kterému měla zásada zabránit. Postup níže zafixuje jeden název zařízení, seřadí výjimky tak, aby tunel skutečně mohl vzniknout, a nechá vám cestu zpět, pokud pravidla dopadnou špatně. Každý krok je dost krátký na to, aby se dal zrušit samostatně.

Krok 1: zapište pravidla, která máte teď

Než změníte výchozí zásadu, uložte aktuální stav, aby vrácení bylo příkazem, a ne vzpomínkou. iptables-save > /root/iptables.pre zapíše každou tabulku do souboru, který můžete obnovit, a druhý terminál s otevřenou relací root není paranoia, když zásada, kterou se chystáte nastavit, shodí spojení, které ji nese. Pokud pracujete vzdáleně, naplánujte také flush jako mrtvý spínač.

Potom vypište rozhraní, protože název, který jste předpokládali, je název, který jste měli přečíst: ip -br link ukazuje, co právě existuje, a tunel se neobjeví, dokud nebude nahoru. Zapisujte si názvy zařízení, jak je čtete.

Krok 2: dejte tunelu jeho vlastní název

OpenVPN přijímá dev tun_work v konfiguraci klienta a Linux pak vytvoří rozhraní přesně s tímto názvem, místo aby přidělil tun0. Název zůstává stabilní napříč opětovnými připojeními, dokud si ho nic jiného nenárokuje, a právě to dělá pravidlo, které zařízení pojmenovává, smysluplným.

Tam, kde název nelze ovládat, porovnávejte místo toho adresu tunelu nebo značku paketu. Obě fungují, obě se hůř čtou a obě selhávají tišeji, když tunel změní číslování. Ať tak či onak, porovnávejte jednu věc a buďte výslovní v tom kterou.

Krok 3: napište zásadu s výjimkou pro endpoint na prvním místě

Hostitel jen pro VPN je hostitel s výchozím odmítnutím a krátkým seznamem výjimek, a výjimka, na které záleží nejvíc, je ta, která tunelu dovoluje existovat. Stavte ji v tomto pořadí, s pravidlem pro endpoint před pravidlem pro zařízení tunelu, aby handshake měl kam jít:

# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT  -i tun_work -j ACCEPT
iptables -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Doslovná adresa endpointu a port patří vašemu poskytovateli, ne této stránce. Pokud je endpoint název hostitele, přeložte ho jednou a výsledek zafixujte, protože pravidlo neumí vyhledat název a rotující odpověď tiše rozbije zásadu po další změně DNS. Zkontrolujte i port, protože poskytovatelé, kteří vás přesunou na TCP 443, jinak budou potřebovat pravidlo, které nikdo nezapsal. Tunel, který funguje jen na jednom protokolu, je obvykle právě toto opomenutí, a ne závada firewallu.

Na routeru stejný tvar jde do řetězce FORWARD pro klienty za ním a vlastní provoz routeru potřebuje vlastní pravidla. Sada pravidel, která pokrývá jen předávané pakety, nechává SSH a DNS na staré cestě, a tak se router stane nedostupným v okamžiku, kdy tunel vstane.

Krok 4: zkontrolujte pořadí, ne jen přítomnost

Pravidla se vyhodnocují postupně, takže ACCEPT, který přijde dřív, prostě skryje REJECT, který jste přidali potom. Shoda established a related je to, co nechává odpovědi na vaše vlastní odchozí požadavky vrátit se, aniž by otevřela obecnou příchozí cestu, a její umístění za přijetím tunelu znamená, že spadlý tunel stále propouští zpětný provoz na svém rozhraní.

Držte počet pravidel dost malý, aby se dal přečíst na jednu obrazovku. Sada pravidel, kterou neumíte auditovat, je ta, kterou budete záplatovat přidáváním výjimek nahoru, a tak zásady výchozího odmítnutí postupně získávají hranu výchozího povolení. Spočítejte ACCEPT před změnou a po ní.

Krok 5: zajistěte, aby přežil boot i rodinu adres

Pravidla zadaná ručně při restartu zmizí, proto je načítejte ze služby firewallu distribuce nebo z unitu, který se spustí poté, co rozhraní tunelu existuje. Odkazovat na tun_work ve skriptu, který se spouští před startem OpenVPN, je častý způsob, jak vytvořit bootovací smyčku se zahozeným provozem.

Potom zkontrolujte IPv6 zvlášť, protože dobrá zásada výchozího odmítnutí pro IPv4 neříká nic o druhé rodině. ip -6 route vám řekne, zda má hostitel trasu, která by mohla nést provoz kolem tunelu, jenž zpracovává pouze IPv4, a ip6tables nebo nftables potřebuje vlastní ekvivalentní pravidla. Testujte s cílem IPv6-only, místo abyste věřili symetrii sady pravidel.

Krok 6: ověřte a buďte připraveni obnovit

Zvedněte tunel, potvrďte, že zamýšlená služba funguje, a pak zkuste něco, co by zásada měla odmítnout. Obnovte pomocí iptables-restore < /root/iptables.pre, pokud vás odpověď překvapí, a teprve potom začněte pravidla upravovat. Trvalost plus vyzkoušená cesta obnovy je to, co z toho dělá změnu, kterou můžete udělat dvakrát.