UFW zahodí DNS server VPN, jakmile se tunel zvedne

Jména přestanou být překládána v okamžiku, kdy se VPN připojí, zatímco ping na veřejnou adresu stále odpovídá a stav firewallu neukazuje nic, co by vypadalo špatně. V politice se nezměnilo nic; změnilo se to, že se objevilo nové rozhraní, a výchozí zamítnutí ho pokrývá od prvního paketu. UFW rozhoduje podle směru a rozhraní, takže pravidlo napsané pro bezdrátové spojení neříká nic o provozu, který opouští tunel. Oprava je hrst úzkých pravidel použitých v určitém pořadí.

Příznak se objeví až poté, co je tunel zvednutý

Politika výchozího zamítnutí dělá přesně to, co jí bylo řečeno: cokoli bez odpovídajícího pravidla je odmítnuto, na každém rozhraní, které existuje. Tunel při psaní pravidel neexistoval, takže žádné z nich ho nemůže pokrýt, a zamítnutí, které tam bylo vždy, se nyní vztahuje na překlad jmen. Přímý provoz na doslovnou adresu může stále fungovat, když ho pokrývá širší povolení, a proto ping na veřejný překladač uspěje, zatímco hledání jména selže. Mezera je pravidlo pro rozhraní, které politika nikdy neviděla.

To také vysvětluje, proč se selhání čistě obrátí: sundejte tunel a jména se znovu přeloží, protože dotaz se vrací na rozhraní, které pravidla má. Politika, která selhává jen při zvednutém tunelu, není problém DNS, a ladění samotného překladače zde ztrácí nejvíce času. Přečtěte si seznam rozhraní dřív, než přečtete konfiguraci překladače.

Tři směry, tři různé sady pravidel

Jedna relace se dotýká pravidel ve více než jednom směru a tunel přidává druhé rozhraní téměř ke každému z nich. Když provoz nejprve roztřídíte podle směru a rozhraní, zbytek se stane mechanickým, protože každý řádek níže potřebuje vlastní pravidlo na svém místě. Příklady používají tun0 a fond 10.8.0.0/24, takže nahraďte názvy a rozsahy těmi z vlastního výstupu klienta.

Dva řádky se často pletou, protože oba zmiňují tunel. Pravidlo pro překladač povoluje provoz, který klient posílá do tunelu, zatímco pravidlo pro SSH povoluje provoz, který server odtud přijímá; žijí na různých strojích a selhávají nezávisle. Řádek, na který se nejčastěji zapomíná, je druhý, protože klient vůbec nemůže tunel vytvořit, dokud není povolen jeho provoz na veřejnou adresu serveru. Pracujte shora dolů a každé selhání má jednu pravděpodobnou příčinu.

Protlačený překladač potřebuje vlastní pravidlo

Zda tunel nese DNS, závisí na tom, co server posílá. Server, který protlačí volbu překladače, nainstaluje do konfigurace klienta soukromou adresu a tato adresa je směrovatelná jen přes tunel. Pokud server nic neprotlačí, klient si ponechá překladač, který už měl, a pravidla níže nemají co povolit. Před psaním čehokoli zkontrolujte protlačený stav a aktuální výsledek dotazu:

dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numbered

Výstup stavu pojmenuje překladač, který se používá, a spojení, ke kterému je vázán, a hledání trasy za ním ukáže, které rozhraní by dotaz na tuto adresu neslo. Když překladač sedí na jiném spojení, problém je dřív než firewall a žádné pravidlo nepomůže. Když se oba shodnou na tunelu, jsou potřeba dvě pravidla, protože UDP nese většinu dotazů a TCP se ujme, když je odpověď zkrácena. Zapište obě hodnoty, protože právě ty pravidla pojmenují:

sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'

Otevřete vnější cestu dřív než vnitřní

Klient se musí dostat na veřejnou adresu serveru dřív, než tunel existuje, takže pravidlo pro ni sedí na fyzickém spojení a musí být na místě první. Politika, která povolí překladač, ale zapomene na server, nechá klienta zcela neschopného tunel postavit, a tento příznak se obvykle svádí na kill switch. Potom povolte služby, které jste skutečně chtěli přes tunel, po jednom úzkém pravidle, místo abyste rozhraní otevřeli celé. Úzká pravidla jsou důvodem, proč může zamítnutí zůstat na místě.

sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'

Pořadí je při testování důležité, protože první pravidlo je to, co tunelu vůbec dovolí se zvednout. Přidejte ho, připojte se a potvrďte, že tunel je zvednutý, než přidáte pravidlo služby, protože dělat obojí najednou znamená, že selhání nic neřekne o tom, která polovina je špatně. Nahraďte dokumentační adresu výše koncovým bodem, pro který je klient nakonfigurován.

Dokončete klientskou stranu tím, že se záměrně odpojíte. Zamítnutí by stále mělo odmítat provoz, který jste záměrně vyloučili, protože překladač, který odpovídá při zvednutém tunelu, pokrývá jen polovinu politiky, která v případě pochybnosti zamítá.

Klient, který se připojí, ještě není vpuštěn

Server má vlastní směr, který je třeba zvážit, a klient, který dokončí handshake, se stále nedostane na nic, co na serveru běží, dokud ho server nevpustí. Pravidlo veřejného listeneru dovoluje jen existenci tunelu; nepouští provoz tunelu dovnitř. Na serveru jsou to dvě pravidla plus jedna kontrola, že služba skutečně naslouchá:

sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'

Fond v pravidle se musí rovnat rozsahu, který server přiděluje, a číslo tunelu musí odpovídat tomu, které server vytvořil, protože pravidlo pro jiné rozhraní je nerozeznatelné od žádného pravidla. limit je záměrné pro administrativní port, protože omezuje opakovaná připojení místo toho, aby je přijímalo bez omezení. Kontrola listeneru odděluje zavřený port od zahozeného paketu, které z pohledu klienta vypadají stejně. Číslovaná pravidla také nejsou celý obraz: pravidla before v UFW a všechny ručně psané řádky nftables se shodují dřív a stále mohou odmítnout paket, který seznam zdánlivě povoluje.