Az OpenVPN csatlakozik, de semmi nem folyik: találja meg a réteget, ahol a csomag elvész
Egy csatlakozott alagútnak forgalom nélkül legalább öt oka van. Bizonyítsa a figyelőt, rögzítse a külső csomagot, majd hagyja, hogy a számlálók vagy egy nyom megnevezze a szabályt.
OpenVPN csatlakozottnak mondja magát, és semmi forgalom nem mozdul, egy mondat, amely legalább öt független hibát fed le. Tűzfal-szabályokat szerkeszteni, mielőtt tudná, melyik réteg hibázik, megsokszorozza az ismeretlent, és a következő mérnökre káoszt hagy. Dolgozzon inkább a folyamatból kifelé, mert minden lépés alább vagy tisztít egy szakaszt, vagy szűkíti, hol hal meg a csomag. A sorrend itt számít: egy rögzítés, amelyet azelőtt vesznek fel, hogy tudná, melyik cím van hozzákötve, bizonyít valamit, csak nem azt, amire szüksége van.
A socket vagy kötött, vagy nem
Egy aktívnak jelentkező szolgáltatás továbbra is kötődhet olyan címhez vagy átvitelhez, amelyet soha nem szándékozott. Kérdezze meg magát a socketet: ss -lunp felsorolja az UDP-figyelőket, ss -ltnp pedig a TCP-ket, és az olvasásra érdemes oszlop a helyi cím, nem az állapot.
Az üres válasz általában három dolog egyikét jelenti: a folyamat indítás után kilépett, másik konfigurációs fájlt töltött be, vagy más címen figyel, mint amelyre tárcsáznak.
ss -lunp | grep 1194
ss -ltnp | grep 1194
A local direktíva egyetlen címhez rögzíti a figyelőt, így az ugyanazon a gazdagépen máshová irányuló kliens elutasításra kerül, miközben a szolgáltatás kívülről még egészségesnek látszik. Egy példánynév is mutathat olyan fájlra, amelyet soha nem szerkesztett, ami két profilt egymás mellett futtató gazdagépeken fordul elő.
A külső csomagot rögzítse, ne az alagutat
Szűrjön a fizikai interfészen és a valódi porton, a saját interfészét behelyettesítve: tcpdump -ni eth0 udp port 1194. A kimenő csomagok, amelyekre semmi nem jön vissza, arra mutatnak, ami feljebb van: szolgáltatói szűrés, NAT-eszköz vagy olyan távoli cím, amely nem az, amire gondol. A csend mindkét irányban kliens-útválasztásra vagy helyi tűzfalra mutat. Az alagút előrehaladása nélkül érkező válaszok a vezérlőcsatornára mutatnak, azaz kulcs- vagy titkosítási eltérésre, nem szűrésre.
Rögzítse mindkét irányt, és tartsa rövidnek a fájlt. A hosszú rögzítés eltemeti az érdekes három másodpercet, és a válasz szinte mindig az első cserében van.
Először a számlálók, nyom csak amikor hazudnak
Kezdje a számlálókkal, mert azok semmibe nem kerülnek. Vagy a nft list ruleset, vagy a iptables -L -n -v válaszol az egyetlen itt fontos kérdésre: illeszkedett-e a szabály? A sorrend dönti el az eredményt, mert az első egyezés nyer, ezért hagyja egy széles DROP egy későbbi ACCEPT előtt azt az ACCEPT-et halottnak, és ezért javít olyan ritkán bármit egy szabály hozzáadása.
A tulajdonjog is megbotlasztja az embereket. A kernel a helyben létrehozott csomagokat ahhoz a folyamathoz rendeli, amely a socketet megnyitotta, és az OpenVPN általában rootként fut, így egy közönséges felhasználói ID-hez kötött szabály soha nem látja magának az alagútnak a forgalmát. Ellenőrizze a tulajdonos UID-t, mielőtt eldöntené, hogy a szabály hibás.
Csak amikor a számlálók kétértelműek maradnak, éri meg a napló a zajt, és akkor is csak egy szűk szeletre: egy iptables-szabály, amely sebességet korlátoz és előtagot tesz a naplósoraira, vagy egy nftables-szabály, amely meta nftrace set 1-et hordoz, miközben nft monitor trace fut. A nyom megnevezi a láncot és a szabályt, amely a csomagot elfogadta vagy eldobta. Utána távolítsa el mindkettőt, és tartsa kívül a hasznos teher naplózását.
Ellenőrizze az átvitelt is. A TCP-re korlátozott tűzfalszolgáltatás semmit nem mond az adott számon figyelő UDP-figyelőről, ezért egy helyesen olvasott szabály még minden csomagot eldobhat.
Útválasztás és a visszaút
Egy elfogadott csomag, amely mégis eltűnik, a célútja vizsgálatát igényli. A ip route get jelenti az egy címhez választott útvonalat, és a fordított útvonal szűrése eldobhat egy választ, amely olyan interfészen érkezik, amelyet a fő tábla soha nem választana. A tünet pontosan tűzfal-eldobásnak látszik, ezért ez az ellenőrzés egy újabb NAT-szabály előtt jön.
Egy átjárón a továbbítást és a forward láncot vizsgálja az input lánc helyett. Utána erősítse meg, hogy a távoli oldal tudja, hogyan érje el a forrás címet, mert egy működő kimenő út, amelyre semmi nem jön vissza, mindkét esetben csend.
Mit kell mondania a feljegyzésnek
Minden változásnál jegyezze fel a tesztelt szakaszt, az olvasott bizonyítékot és a számláló értékét annak mindkét oldalán. Ez a feljegyzés teszi túlélhetővé a "most működik" kijelentést a következő átvizsgáláskor.
Két rövidítés tartja őszintén a feljegyzést. Egy csomag, amely soha nem hagyta el a gazdagépet, nem dobhatta el egy szabály máshol, bármilyen meggyőző is a távoli oldal konfigurációja. Egy csomag, amely elment és visszatért, a kérdést a hálózati réteg fölé helyezi, ahol a tűzfal számlálóinak már nincs mit mondaniuk.