Firewall linuxové distribuce může blokovat provoz vaší VPN

Tunel se zvedne, log hlásí připojeno, a jedna aplikace přesto nedosáhne na nic. Na linuxovém klientovi to obvykle znamená, že firewall distribuce filtruje cestu, kterou klient VPN nikdy nespravoval. Dva správci mohou být aktivní současně, každý se svou představou o rozhraní, zóně a směru provozu. Zjistit vlastníka před jakoukoli úpravou je rychlejší než zkoušet pravidla, dokud něco nezačne fungovat.

Najděte správce a backend

Začněte tím, co je skutečně načteno, ne tím, co je nainstalováno. Distribuce může dodávat firewalld, ufw a obyčejnou službu nftables, a jen jedna z nich vlastní běžící sadu pravidel. Balíčky klidně koexistují a pravidlo zadané přes špatný frontend se nikdy nedostane do jádra. Přečtěte aktivní službu a potom sadu pravidel, kterou vytvořila.

Backend je stejně důležitý jako frontend. Instalace firewalld může pohánět nftables nebo starší backend iptables podle verze a konfigurace a oba produkují odlišný výstup kontroly. Zapište distribuci, verzi a backend do tiketu, než svůj systém porovnáte s jakýmkoli návodem.

Sladěte směr a rozhraní

Odchozí požadavek klienta, příchozí posluchač a předávaný paket procházejí různými háky a pravidlo pro jeden nepokrývá ostatní. Zóna, která povoluje místní LAN, často nezahrnuje rozhraní tunelu ani fond adres VPN. Rozhraní tunelu obvykle skončí ve výchozí zóně, která bývá přísnější než zóna fyzického adaptéru. Tento nesoulad vysvětluje, proč prohlížení v LAN funguje a zastaví se v okamžiku, kdy se tunel zvedne.

Než vyberete pravidlo, zeptejte se, který směr selhal. Aplikace, která se nedokáže připojit ven, potřebuje výstupní cestu, zatímco příchozí služba potřebuje vstupní cestu na rozhraní tunelu. Přidání pravidla do špatného řetězce vytvoří změnu, která vypadá aplikovaně a nedělá vůbec nic.

Udržujte vlastníky pravidel ve shodě

Hák klienta VPN, kontejnerové runtime a služba distribuce mohou měnit síť, a vzájemně se nekoordinují. Ručně zadaná pravidla zmizí při dalším načtení a pravidla vložená do řetězce správce se mohou vyhodnocovat v pořadí, které jste nezamýšleli. Použijte trvalou konfiguraci správce a zkontrolujte výslednou sadu pravidel místo souboru, který jste napsali. Vypnutí celého firewallu proto, že jedna služba je nedostupná, vymění malý problém za velký.

Úzké čítače jsou levný způsob, jak najít odmítnutý tok. Pravidlo protokolování omezené na jeden cíl a jeden port ukáže, zda k zahazování dochází lokálně, aniž by zachytilo cizí provoz. Po skončení vyšetřování pravidlo protokolování odstraňte, protože je to diagnostika, nikoli politika, a dokumentace zón firewalld vysvětluje, jak se rozhraní a služby kombinují.

Ověřte opravu bez ztráty uzamčení

Zkontrolujte aplikovaný stav správcem, který ho vlastní, pomocí příkazů odpovídajících zaznamenanému backendu. Následující výpis předpokládá, že je odpovědný firewalld; nahraďte ho ekvivalentem pro nftables nebo ufw, místo abyste spouštěli všechny. Míchání nástrojů v jedné relaci je způsob, jak stroj skončí se dvěma konfliktními sadami pravidel.

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=trusted --list-all
sudo nft list ruleset | head -40

První příkaz pojmenuje zóny a rozhraní, která jim jsou přiřazena, což ukáže, kam tunel skutečně dopadl. Druhý vypíše pravidla a služby zóny, takže vidíte, zda je rozhraní VPN vůbec pokryto. Výpis nftables je základní pravda pro používaný backend a pravidlo, které existuje jen v konfiguračním souboru, se tam neobjeví. Porovnejte tři výstupy s pravidlem, které jste přidali, a nesoulad se obvykle pojmenuje sám.

Potom zopakujte původní požadavek a chování selhání, které vyžadujete. Nově fungující web nestačí, pokud stejná změna odebrala uzamčení klienta, takže otestujte i nechráněnou cestu. Zapište správce, backend, rozhraní a účel pravidla, protože aktualizace balíčku, která oživí druhého správce, jinak celý nepořádek znovu postaví.