Přepínač UFW blokuje vaši VPN? Povolte protějšek

Prošli jste kontrolní seznam: zakažte odchozí, povolte tunel, zapněte ufw. Pak klient čeká na handshake a nikdy se nepřipojí, nebo se připojí a nenačte se žádná stránka. Obě selhání pocházejí ze stejné mezery. Chybí pravidlo, které tunelu umožňuje existovat, protože tunel není rozhraní, kterým vaše pakety odcházejí.

Proč povolení na tun0 nejdřív ničemu neodpovídá

tun0 vytváří klient poté, co existuje relace. Datagramy, které tuto relaci staví, jsou obyčejné UDP pakety adresované poskytovateli na port 1194 a odcházejí přes wlan0 nebo eth0 s fyzickou zdrojovou adresou. allow out on tun0 odpovídá jen provozu, jehož odchozí rozhraní je tun0, takže během handshake neodpovídá vůbec ničemu.

Položte default deny outgoing navrch a vnější pakety se zahodí dřív, než se rozhraní vůbec objeví. Klient to zkouší znovu, vyprší časový limit a ohlásí selhání TLS nebo handshake, což lidi pošle pátrat po certifikátech a MTU, zatímco firewall tiše požírá spojení. Pravidlo, které mělo váš provoz zadržet, brání tomu, aby se ten provoz zadržel.

Reflexní oprava činí únik trvalým. sudo ufw allow out on wlan0, nebo přepnutí výchozího nastavení zpět na povolit, zvedne tunel a nechá stroj bez přepínače: až tunel příště spadne, všechno se obnoví přes fyzický adaptér. Ztratil jsem odpoledne přesně na té dvojici úprav, než jsem zjistil, který paket vlastně filtruji.

Co obě sady paketů potřebují

Váš provoz prochází firewallem dvakrát, ve dvou podobách. Vnitřní paket jde z adresy tunelu ven přes tun0. Vnější paket jde z fyzické adresy k protějšku a je jediné, co je na drátě vidět. Jedno pravidlo na podobu:

sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow out to 203.0.113.10 port 443 proto tcp comment 'tcp fallback'

Nahraďte adresu a port těmi ze svého profilu. Protějšky WireGuard obvykle odpovídají na 51820/udp; profily OpenVPN jedoucí přes TCP 443 potřebují místo toho tento port. Podrobnosti se liší, podoba ne: obě pravidla jsou úzká a společně určují jediné cíle, kterých může stroj dosáhnout, když tunel neběží.

Pořadí je druhý mýtus. U surového iptables čtete řetěz shora dolů a uvažujete, které pravidlo vyhraje. ufw není tenký obal kolem seznamu, který jste napsali; překládá vaše pravidla do vlastních řetězů a volí místa vložení. ufw status je vypisuje v pořadí ufw, ne vašem. Když pravidlo vypadá ignorované, porovnejte ufw show added s přeloženou sadou z iptables -S | grep ufw dřív, než cokoli přepíšete.

Výjimka musí zůstat široká jednu adresu

Pravidlo pro protějšek je správné jen tehdy, dokud pojmenovává adresu, na kterou klient vytáčí. Poskytovatelé rotují koncové body a profil, který překládá název hostitele, bude následovat změnu DNS na novou adresu, zatímco pravidlo dál ukazuje na starou. Když tunel, který měsíce fungoval, přestane nabíhat, porovnejte adresu v pravidle s tou, kterou klient hledá, než cokoli rozšíříte.

Rozšíření na celou podsíť nebo na každý cíl na portu 1194 promění politiku zpět ve firewall s dírou. Výjimkou je přepínač; jakmile je široký, není co přepínat. Držte ho na jedné adrese a nechte komentář s názvem profilu a poskytovatele, protože za šest měsíců bude adresa vypadat libovolně.

Překlad názvů si zaslouží vlastní řádek. Vyhledání probíhá dřív, než tunel existuje, přes fyzické rozhraní, takže přísná politika zákazu odchozího provozu může nechat klienta neschopného najít vlastní server. Povolte port 53 na adresu svého resolveru, nebo jednou přeložte a adresu připněte v profilu. Povolení DNS na každém rozhraní je rozhodnutí, ne výchozí stav.

Postavte politiku dřív, než bude tunel potřeba

ufw enable uplatní celou politiku najednou a znovu načte své řetězy, a změna výchozí politiky na běžícím firewallu je také znovu načte. ufw manuál varuje, že to může shodit existující spojení, jako je SSH. Proto jdou příkazy v tomto pořadí, s pravidlem SSH před zapnutím a otevřenou konzolovou relací:

sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

ufw reset je z toho bloku záměrně vynechán. Smaže každé pravidlo a vypne firewall, a na vzdáleném hostiteli je to následné zapnutí, co shodí vaši relaci. Pokud přesto resetujete, přidejte pravidlo SSH a před dalším postupem potvrďte druhou cestu zpět přes konzoli.

Pořadí není kosmetické. Pravidla přidaná za běhu ufw nic nespláchnou, ale ve chvíli, kdy přepnete výchozí politiku, se řetězy znovu načtou a relace, kterou stará politika povolovala, jde s nimi. Udělejte výchozí nastavení, povolení a zapnutí v jednom průchodu, dokud ještě máte cestu dovnitř, která nezávisí na stroji.

Otestujte zablokovaný stav a ponechte zrušení

Neotestovaný přepínač je dohad. Záměrně odpojte klienta a zkuste načíst stránku: musí selhat. Připojte se znovu a musí se zotavit, aniž byste se dotkli pravidla. sudo ufw status verbose potvrzuje výchozí nastavení a stav protokolování a ufw status numbered ukazuje, které testovací pravidlo smazat, až přežije svůj účel.

Držte obrácený skript vedle přímého. Stroj se zákazem odchozího provozu a mrtvým tunelem si nemůže stáhnout vlastní opravu, takže zrušení musí ležet na disku a být čitelné z konzole:

sudo ufw reset
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

Spusťte ho, když tunel už spadl a pravidla musí jít dolů, ne jako rutinní krok. Než zavřete terminál, musí platit čtyři věci: pravidlo pro protějšek pojmenovává přesně jednu adresu, DNS má pojmenovanou výjimku, zapnutí přišlo po povoleních a stažení tunelu zabije běžný provoz, aniž by klienta nadobro zabilo.