Hogyan ellenőrizzük, hogy egy Linux VPN-alagút valóban működik-e

A cron tízpercenként újraindít egy teljesen egészséges VPN-t, és ugyanez a feladat egy holtat egész heti működésben hagy. Mindkét hiba abból ered, hogy a «működik» szót egyetlen tényként kezeljük, holott legalább négy. Egy eszköz lehet adminisztratívan engedélyezett, helyesen irányított, teljesen titkosított, és mégis semmi hasznosat nem szállít. Először válassza külön a megfigyeléseket, és az ellenőrzés szinte magától megírja magát.

A kapcsolat jelzői az eszközt írják le, nem a pályát

Az ellenőrzés, amit mindenki másol, csupa nullából álló hardvercímet keres. Ez a trükk egyes illesztőprogramokban elválasztja a valódi interfészt egy helyőrzőtől, a többiekben pedig semmit nem bizonyít, mert a tun eszköznek egyáltalán nincs MAC-címe, amit jelenthetne. ip -brief link show tun0 helyette jelzőket ad: UP azt jelenti, hogy egy rendszergazda engedélyezte az eszközt, és LOWER_UP azt jelenti, hogy az illesztőprogram a kapcsolatot használhatónak tartja. Együtt olvasva azt mondják, hogy az eszköz létezik, és nincs adminisztratívan kikapcsolva. Egyik sem mondja, hogy a csomagnak van hova mennie.

OpenVPN még az útvonalak telepítése előtt létrehozza a tun eszközét, így a jelzők tökéletesnek látszhatnak, holott semmi nincs irányítva. Kezelje ezeket előfeltételként, soha nem válaszként.

Kérdezze meg, hová menne egy csomag

Az útvonal-lekérdezés válaszol arra a kérdésre, amelyre a jelzők nem képesek. ip route get 10.8.0.1 from 10.8.0.2 megnevezi az interfészt, a forráscímet és a táblázatot, amelyet a kernel használna, és pontosan ez az, amivel szemben egy osztott alagutat ellenőrizni kell. Forráscím nélkül valami mást kérdez, és szabályalapú irányításnál a válasz forrásonként eltérhet. Ez a legolcsóbb őszinte próba, mert ugyanazokat a szabályokat kérdezi meg, amelyeket a forgalma használni fog.

A WireGuardnál adjuk hozzá a kézfogást. wg show páronként kiírja a legutóbbi kézfogás időpecsétjét, és az az időpecsét, amely megállt az előrehaladásban, azt jelenti, hogy a partner eltűnt, bármit is mondanak az interfész jelzői. A friss kézfogás nélküli konfigurált interfész az egyik leggyakoribb téves riasztás a házi felügyeletben.

A 220-as tábla meséli el az IPsec történetét

A strongSwan a tárgyalt szelektorok útvonalait a 220-as táblába telepíti, ha az útvonal-telepítés engedélyezett. ip route list table 220 ezért elválasztja a tárgyaltat az irányítottól: egy töltött kapcsolat mellett álló üres tábla azt jelenti, hogy az IKE és CHILD SA-k feljöttek, de semmilyen forgalom nem irányul beléjük. Ellenőrizze ip xfrm state mellette, mert listázza a telepített biztonsági társításokat és végpontjaikat.

A csapdapolitika az az eset, amelyre figyelni kell. Inkább várakozik érdekes forgalomra, mint hogy irányítsa, így a tábla üres marad, amíg valami nem indítja el az alagutat.

A kezelő állapota és a démon állapota külön listák

A NetworkManager csak az általa birtokolt kapcsolatokat listázza. nmcli -t -f NAME,TYPE connection show --active semmit nem ad vissza olyan alagútra, amelyet közvetlenül a wg-quick vagy egy OpenVPN-démon indított.

Ez a megkülönböztetés akkor fontos, amikor egy szkriptnek el kell döntenie, melyik két kezelőtől kérdezzen. Azt válassza, amelyik valóban birtokolja az alagutat ezen a hoszton, és hagyja figyelmen kívül a másik hallgatását. Ha mindkettő létezik, döntse el, melyik a mérvadó, és kapcsolja ki a másodikat, mert két kezelő, amely ugyanazon az interfészen átírja az útvonalakat, olyan hibákat okoz, amelyeket senki nem tud újra előidézni. A hiányzó bejegyzés a kezelőről szóló információ, nem az alagútról.

A következő lépést az általa igényelt vizsgálathoz kösse

Egy UDP-port vizsgálata semmit nem bizonyít a felkészültségről, mert az UDP-nek nincs kézfogása, és nc -u sikeres, amint a csomag elindul. Vizsgálja azt, amit a következő lépés valóban fogyaszt: TCP-kapcsolat a továbbított portra, kérés az alagúton belüli gazdagéphez, olyan név, amely csak ott oldódik meg. Határolja a várakozást egy időkorláttal és a kísérletek számával, és hangosan bukjon el, amikor lejár.

A kampók legyőzik a lekérdezést, ha az ügyfél kínálja. Az OpenVPN --up és --down szkriptjei az interfész állapotváltozása után futnak, ami teljesen megszünteti a versenyt, de a démon által megtartott jogosultságokkal futnak. Ha az OpenVPN user és group révén jogosulatlan fiókra esett, a kampó ezzel a fiókkal fut. Egy rendszerszolgáltatás újraindítása ekkor sudo-t igényel, hogy pontosan azt a parancsot engedélyezze. Adja az ismételt próbálkozást a szolgáltatáskezelőnek cron-hurok helyett: a kezdési korláttal rendelkező, korlátozott újraindítási szabályzat felfedi a törött alagutat, míg a korlátlan hurok végtelenül elrejti.