Firewall distribúcie Linux môže blokovať prevádzku VPN

Tunel sa zdvihne, log hlási pripojené, a jedna aplikácia napriek tomu nič nedosiahne. Na klientovi Linux to zvyčajne znamená, že firewall distribúcie filtruje cestu, ktorú klient VPN nikdy nespravoval. Dvaja správcovia môžu byť aktívni súčasne, každý s vlastnou predstavou o rozhraní, zóne a smere premávky. Zistiť vlastníka pred akoukoľvek úpravou je rýchlejšie než skúšať pravidlá, kým niečo nezačne fungovať.

Nájdite správcu a backend

Začnite tým, čo je skutočne načítané, nie tým, čo je nainštalované. Distribúcia môže dodávať firewalld, ufw a obyčajnú službu nftables, a len jedna z nich vlastní bežiacu sadu pravidiel. Balíky pokojne koexistujú a pravidlo zadané cez nesprávny frontend sa nikdy nedostane do jadra. Prečítajte aktívnu službu a potom sadu pravidiel, ktorú vytvorila.

Backend je rovnako dôležitý ako frontend. Inštalácia firewalld môže poháňať nftables alebo starší backend iptables podľa verzie a konfigurácie a oba produkujú odlišný výstup kontroly. Zapíšte distribúciu, verziu a backend do tiketu, kým svoj systém porovnáte s akýmkoľvek návodom.

Zladiť smer a rozhranie

Odchádzajúca požiadavka klienta, prichádzajúci poslucháč a preposielaný paket prechádzajú rôznymi hákmi a pravidlo pre jeden nepokrýva ostatné. Zóna, ktorá povoľuje miestnu LAN, často nezahŕňa rozhranie tunela ani fond adries VPN. Rozhranie tunela zvyčajne pristane vo východiskovej zóne, ktorá býva prísnejšia než zóna fyzického adaptéra. Tento nesúlad vysvetľuje, prečo prehliadanie v LAN funguje a zastaví sa v okamihu, keď sa tunel zdvihne.

Pred výberom pravidla sa spýtajte, ktorý smer zlyhal. Aplikácia, ktorá sa nedokáže pripojiť von, potrebuje výstupnú cestu, zatiaľ čo prichádzajúca služba potrebuje vstupnú cestu na rozhraní tunela. Pridanie pravidla do nesprávneho reťazca vytvorí zmenu, ktorá vyzerá aplikovaná a nerobí vôbec nič.

Udržujte vlastníkov pravidiel v zhode

Hák klienta VPN, runtime kontajnerov a služba distribúcie môžu meniť sieť, a navzájom sa nekoordinujú. Ručne zadané pravidlá zmiznú pri ďalšom načítaní a pravidlá vložené do reťazca správcu sa môžu vyhodnocovať v poradí, ktoré ste nezamýšľali. Použite trvalú konfiguráciu správcu a kontrolujte výslednú sadu pravidiel namiesto súboru, ktorý ste napísali. Vypnutie celého firewallu preto, že jedna služba je nedostupná, vymení malý problém za veľký.

Úzke počítadlá sú lacný spôsob, ako nájsť odmietnutý tok. Pravidlo protokolovania obmedzené na jeden cieľ a jeden port ukáže, či k zahadzovaniu dochádza lokálne bez zachytenia cudzej premávky. Po skončení vyšetrovania pravidlo protokolovania odstráňte, pretože je to diagnostika, nie politika, a dokumentácia zón firewalld vysvetľuje, ako sa kombinujú rozhrania a služby.

Overte opravu bez straty uzamknutia

Skontrolujte aplikovaný stav správcom, ktorý ho vlastní, pomocou príkazov zodpovedajúcich zaznamenanému backendu. Nasledujúci zoznam predpokladá, že je zodpovedný firewalld; nahraďte ho ekvivalentom pre nftables alebo ufw namiesto spúšťania všetkých. Miešanie nástrojov v jednej relácii je spôsob, akým stroj skončí s dvoma protichodnými sadami pravidiel.

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

Prvý príkaz pomenuje zóny a rozhrania, ktoré im boli priradené, čo ukazuje, kam tunel skutočne pristál. Druhý vypíše pravidlá a služby zóny, takže vidíte, či je rozhranie VPN vôbec pokryté. Výpis nftables je základná pravda pre používaný backend a pravidlo, ktoré existuje len v konfiguračnom súbore, sa tam neobjaví. Porovnajte tri výstupy s pravidlom, ktoré ste pridali, a nesúlad sa zvyčajne pomenuje sám.

Potom zopakujte pôvodnú požiadavku a požadované správanie pri zlyhaní. Novofungujúca stránka nestačí, ak tá istá zmena odstránila uzamknutie klienta, preto otestujte aj nechránenú cestu. Zapíšte správcu, backend, rozhranie a účel pravidla, pretože aktualizácia balíka, ktorá oživí druhého správcu, inak celý neporiadok znova postaví.