VPN-útvonal vagy tűzfalszabály: melyik dobja el a csomagot?
Az útvonal utat választ, a szűrő pedig az engedélyről dönt. Ellenőrizze mindkettőt ugyanahhoz a forráshoz, célhoz és irányhoz, mielőtt kiterjeszt egy tűzfalszabályt.
Két független döntés születik ugyanarról a csomagról, és bármelyikük csendben lezárhatja a kérést. Az útvonalkeresés kiválaszt egy interfészt és egy következő ugrást, majd a csomagszűrő eldönti, hogy ez a kombináció engedélyezett-e. Az időtúllépés azt mondja meg, hogy a kettő közül az egyik elutasított, nem azt, hogy melyik. Haladjon végig a szakaszokon sorrendben, és a javítás általában megszűnik találgatás lenni.
Két döntés, egy csomag, két tulajdonos
Az útvonalkeresés először a házirend-szabályokat kérdezi meg, aztán a táblát, amelyre mutatnak, és a célhoz illeszkedő legpontosabb előtagot választja. Az a kliens, aki alagútútvonalat telepített, birtokolja ezt a döntést, és egy tűzfalszabály semmit sem tud helyette nyújtani. Amikor a keresés váratlan helyre mutat, minden későbbi szakasz a rossz csomagon dolgozik.
A szűrés különálló. Linux-gazdagépen a netfilter horgok aszerint osztják fel a forgalmat, hogy kinek szól a csomag: a kimenet elhagyja a gépet, a bemenet rajta végződik, az átengedés keresztülmegy rajta. Az az átjáró, amely VPN-klienseket fogad és LAN-ba irányítja őket, az átengedési útvonalat igényli, és pontosan ez az a lánc, amelyet a legtöbb alapértelmezett konfiguráció üresen hagy.
A forrásválasztás ugyanahhoz a döntéshez tartozik, és itt bújik meg a legtöbb eltérés. A kernel a kimenő interfészről választ forráscímet, hacsak az útvonal nem nevez meg egyet, ezért a LAN-alhálózatra írt szűrőszabály soha nem illeszkedik az alagút címével kilépő csomagra.
Olvassa el, mit választott a keresés valójában
Nyomtassa ki a döntést ahelyett, hogy kikövetkeztetné. Az alábbi parancs feloldja az útvonalat, amelyet a kernel ehhez a célhoz használna, beleértve az interfészt és a forrást, amelyet választana:
ip route get 10.8.0.5 ip route get 10.8.0.5 from 192.0.2.44 ip rule show ip route show table all | sed -n '1,40p'
A VPN-kliensek gyakran a főtábla alatti prioritásokon telepítenek házirend-szabályokat, ezért egy tiszta főtábla önmagában semmit sem bizonyít. Hasonlítsa össze a szabályok prioritásait az általuk választott táblákkal, és ellenőrizze, hogy az alagútútvonal túléli-e az újracsatlakozást ahelyett, hogy egyszer kézzel hozzáadnák.
A házirend-alapú IPsec hozzáad egy harmadik egyeztetési szakaszt, amelyet az útválasztás nem fed le, ahogy a strongSwan továbbítási megjegyzései leírják az alagút- és szállítási beállításokhoz. A biztonsági házirend előtag és protokoll szerint választja ki a forgalmat, míg az útvonal csak azt dönti el, hová menne egy védelem nélküli csomag. Az az alhálózat, amely át van irányítva, de nincs hozzá illeszkedő szelektora, vagy védelem nélkül marad, vagy a konfigurációtól függően eldobásra kerül, és egyik eredmény sem néz ki tűzfalproblémának. Nyomtassa ki a házirendet, és hasonlítsa össze a szelektorait azokkal az előtagokkal, amelyeket várt, hogy az alagút szállít.
A szűrés egy horognál érvényesül, nem egy útvonalnál
Az a szabály, amely engedélyezi a VPN-figyelőt, az átjáróhoz címzett forgalomról szóló szabály. Semmit sem mond azokról a kliensekről, amelyek az átjáró mögötti gazdagépeket érik el, mert az átengedett forgalom más láncon halad át. A szabálykészlet egyetlen lapos listaként való olvasása a szokásos oka annak, hogy egy helyesnek tűnő szabály soha nem lép működésbe.
A számlálók gyorsan eldöntik a kérdést. Egy nulla csomagszámlálójú szabályt soha nem értek el, ami a rossz láncra, a rossz interfészre vagy egy korábbi eldobásra mutat. Az eldobási házirend alatt növekvő számlálójú szabály az a határ, amelyet keresett, és a csomag elvetésre kerül, nem pedig rosszul irányítva.
Küldjön próbát azon az úton, amelyet a kliens használ
Az átjárón futtatott tesztek a kimeneten és a bemeneten haladnak át, az átjáró saját forráscímével. Ez más út, mint egy kliens átengedett kérése, ezért egy sikeres helyi curl kevesebbet bizonyít, mint amennyinek látszik. Teszteljen arról a gépről, amelyik meghibásodik, vagy rögzítse kifejezetten az interfészt és a forrást.
nc -vz -w 3 10.8.0.5 443 ping -c 3 -W 1 10.8.0.5 tcpdump -ni any host 10.8.0.5 and port 443 iptables -vnL FORWARD --line-numbers nft list ruleset | sed -n '1,60p'
A két végén végzett rögzítés elválasztja a fennmaradó eseteket. Az a SYN, amely elhagyja a klienst és soha nem érkezik meg, útválasztást, titkosítást vagy egy feljebb lévő hozzáférési listát jelent. Az a SYN, amely megérkezik és nem kap választ, a szolgáltatást vagy annak gazdagépszűrőjét jelenti, és az alagút soha nem volt a probléma.
A visszirányú forgalom saját pillantást érdemel. Az aszimmetrikus útválasztás és a fordított útvonal szűrése eldobja a rossz interfészen érkező válaszokat, ami egyirányú kapcsolatként jelenik meg, nem blokkolt portként. Ellenőrizze a sysctl értékét, mielőtt a tűzfalat hibáztatná egy olyan tünetért, amelyet nem okozott.
A naplózás második véleményként működik, nem első lépésként. Egy ideiglenes naplóutasítás az átengedési láncon megnevezi az interfészt és a címeket, amelyek eltalálták, és utána könnyű eltávolítani. Ha állandóan otthagyja, akkor válasz helyett naplómennyiség-problémát épített.
Minden változtatást oda tegyen, ahol túléli az újracsatlakozást
Az ip route add paranccsal hozzáadott útvonal addig él, amíg az interfész le nem áll. Őrizze meg inkább a kapcsolatprofilban: a NetworkManager elfogad további útvonalakat a kapcsolaton, a netplan pedig megőrzi őket az újraindítások között. Ugyanez a szabály vonatkozik az ügyféloldali tűzfalkivételre, amely a következő újratöltés után eltűnik.
A kiszolgálóoldali szabályok ahhoz a konfigurációs fájlhoz tartoznak, amelyet a szolgáltatás indításkor betölt, nem egy interaktív munkamenethez, amely akkor ér véget, amikor bezárja. Írja meg a szabályt, töltse újra, és erősítse meg, hogy a számláló elmozdult, mert egy szintaxist elutasító újratöltés csendben otthagyja a régi szabálykészletet.
Ezután ismételje meg az eredeti alkalmazáskérelmet elejétől a végéig, és jegyezze fel, melyik réteg változott. Az az útvonaljavítás, amelyhez szűrőváltoztatás is kellett, továbbra is meghiúsul, és a második hibát sokkal könnyebb olvasni, ha tudja, hogy az első eltűnt. Jegyezze fel a dátumot és a kliens verzióját az eredmény mellé, mert az útválasztás és a szűrés alapértelmezései is mozognak a kiadások között. Tartsa ezt a megjegyzést a jegyen, hogy a következő ember ott kezdje, ahol ön abbahagyta, ahelyett hogy megismételné a kétszakaszos utat.