A Linux-disztribúció tűzfala blokkolhatja a VPN-forgalmát

Az alagút feljön, a napló azt mondja kapcsolódva, és egy alkalmazás mégsem ér el semmit. Linux-kliensen ez általában azt jelenti, hogy a disztribúció tűzfala olyan útvonalat szűr, amelyet a VPN-kliens soha nem kezelt. Két kezelő lehet egyszerre aktív, mindegyiknek megvan a maga elképzelése az interfészről, a zónáról és a forgalom irányáról. A tulajdonos azonosítása bármilyen szerkesztés előtt gyorsabb, mint szabályokat próbálgatni, amíg valami működni nem kezd.

Keresse meg a kezelőt és a backendet

Azzal kezdje, ami valóban betöltődött, nem azzal, ami telepítve van. Egy disztribúció szállíthat firewalld-t, ufw-t és egy egyszerű nftables-szolgáltatást, és közülük csak egy birtokolja a futó szabálykészletet. A csomagok békésen megférnek egymás mellett, és a rossz frontend irányából bevitt szabály soha nem éri el a kernelt. Olvassa el az aktív szolgáltatást, majd az általa létrehozott szabálykészletet.

A backend ugyanolyan fontos, mint a frontend. Egy firewalld-telepítés a verziótól és a konfigurációtól függően nftables-t vagy a régi iptables backendet hajthatja, és a kettő eltérő ellenőrzési kimenetet ad. Írja be a disztribúciót, a verziót és a backendet a jegybe, mielőtt bármilyen útmutatóhoz hasonlítaná a rendszerét.

Egyeztesse az irányt és az interfészt

A kimenő kliens-kérés, a bejövő figyelő és a továbbított csomag különböző horgokon halad át, és az egyikre vonatkozó szabály nem fedi a többit. A helyi LAN-t engedélyező zóna gyakran nem tartalmazza az alagút interfészét vagy a VPN-címtartományt. Az alagút interfésze általában az alapértelmezett zónába kerül, amely gyakran szigorúbb, mint a fizikai adapter zónája. Ez az eltérés magyarázza, miért működik a böngészés a LAN-on, és miért áll le abban a pillanatban, amikor az alagút feljön.

Kérdezze meg, melyik irány hibázott, mielőtt szabályt választ. A kifelé kapcsolódni nem tudó alkalmazásnak a kimeneti útvonalra van szüksége, míg a bejövő szolgáltatásnak a bemeneti útvonalra az alagút interfészén. A rossz lánchoz adott szabály olyan változást eredményez, amely alkalmazottnak látszik, és semmit sem tesz.

Tartsa egyetértésben a szabályok tulajdonosait

A VPN-kliens horga, a konténer-futtatókörnyezet és a disztribúció szolgáltatása mind módosíthatja a hálózatot, és nem hangolják össze egymással. A kézzel bevitt szabályok eltűnnek a következő újratöltéskor, és a kezelő láncába illesztett szabályok olyan sorrendben értékelődhetnek, amelyet nem szándékolt. Használja a kezelő tartós konfigurációját, és a felírt fájl helyett a létrejövő szabálykészletet vizsgálja. A teljes tűzfal kikapcsolása amiatt, hogy egy szolgáltatás elérhetetlen, kis problémát cserél nagyra.

A szűk számlálók olcsó módjai az elutasított folyam megtalálásának. Az egy célra és egy portra korlátozott naplózási szabály megmutatja, hogy az eldobás helyben történik-e, anélkül hogy más forgalmát elkapná. Távolítsa el a naplózási szabályt a vizsgálat végén, mert az diagnosztika és nem szabályzat, és a firewalld zónadokumentációja elmagyarázza, hogyan kombinálódnak az interfészek és a szolgáltatások.

Ellenőrizze a javítást a lezárás elvesztése nélkül

Vizsgálja meg az alkalmazott állapotot a tulajdonos kezelővel, a rögzített backendnek megfelelő parancsokkal. Az alábbi lista feltételezi, hogy a firewalld a felelős; helyettesítse az nftables vagy az ufw megfelelőjével, ahelyett hogy mindet futtatná. Az eszközök keverése egy munkamenetben vezet oda, hogy a gép két ellentmondó szabálykészlettel végzi.

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

Az első parancs megnevezi a zónákat és a hozzájuk rendelt interfészeket, ami megmutatja, hová landolt valójában az alagút. A második kiírja egy zóna szabályait és szolgáltatásait, így láthatja, hogy a VPN-interfész egyáltalán le van-e fedve. Az nftables lista a használt backend alapigazsága, és a csak konfigurációs fájlban létező szabály nem jelenik meg ott. Hasonlítsa össze a három kimenetet a hozzáadott szabállyal, és az eltérés általában magától megnevezi magát.

Ezután ismételje meg az eredeti kérést és az elvárt hiba-viselkedést. Egy újonnan működő webhely nem elég, ha ugyanaz a változtatás eltávolította a kliens lezárását, ezért teszteljen védtelen útvonalat is. Rögzítse a kezelőt, a backendet, az interfészt és a szabály célját, mert egy második kezelőt újraélesztő csomagfrissítés különben újraépíti az egész rendetlenséget.