Két szkript, amely ugyanazért az útvonalért harcol, a Linux VPN-probléma megszokott formája, amelyet útvonal-hibaként regisztrálnak. Az egyik komponens létrehozza az alagút eszközét, egy másik hozzáad egy alapértelmezett útvonalat, a harmadik újraírja a feloldó konfigurációját, a negyedik pedig újratölti a tűzfal szabályait. Bármelyikük visszavonhatja a másik munkáját, és a győztes egyszerűen az, aki utolsóként futott. A válaszra érdemes kérdés nem az, melyik csomagot telepítse, hanem az, melyik komponens illetékes az állapot egyes darabjaiért.

Írja fel ezt a térképet egyszer, és az újracsatlakozási hibák többsége megszűnik rejtélyesnek lenni. Négy objektum számít: az eszköz és címei, az útvonalak és házirend-szabályok, a DNS-konfiguráció és a tűzfal.

Az eszköz és címei

Az alagút eszközét vagy egy profilismertető kezelő hozza létre, vagy egy démon, amelyet valaki kézzel indított. Mindkét elrendezés működik önmagában; a keverésük nem. Ha a profilt a NetworkManager birtokolja, hagyja, hogy az eszközt is birtokolja, és ne indítson kezeletlen OpenVPN-folyamatot ugyanazon alagútnév ellen.

Jegyezze fel, ki távolítja el az eszközt a munkamenet végén. Az az eszköz, amely túléli a munkamenetét, a legelterjedtebb forrása az elavult címeknek és az őket követő zavarnak.

Útvonalak és házirend-szabályok

Éppen az útvonalakon okoznak látható kárt a tulajdonosi konfliktusok. A kapcsolatkezelő telepít egy alapértelmezett útvonalat az alagúthoz, plusz egy konkrétabb útvonalat a távoli hálózathoz; egy kézzel írt szkript ezután hozzáadja a saját alapértelmezett útvonalát más metrikával, és csendben nyer vagy veszít az időzítéstől függően. Döntse el, mely bejegyzések kapcsolathoz kötöttek, melyek állandó házirendek, és melyik komponens frissíti őket újracsatlakozás után. Utána tartsa távol a többi komponenst ettől a táblától.

A házirend-szabályok ugyanazt a világosságot érdemlik, mert egy olyan táblára mutató szabály, amelyet senki sem tölt ki, fekete lyukat hoz létre, amely pontosan úgy néz ki, mint egy halott alagút. Ha egy szabály azért létezik, hogy valahová kényszerítse a forgalmat, akkor az általa kiválasztott táblát ugyanannak a tulajdonosnak kell karbantartania.

A DNS mindig külön tulajdonos

A feloldó démon saját folyamatként fut a saját identitása alatt, ezért nem örökli véletlenül az alagút útvonal-döntéseit. Amikor a VPN DNS-kiszolgálókat tol, valaminek le kell fordítania ezt olyan kapcsolatonkénti konfigurációvá, amelyet a feloldó tiszteletben tart, és valaminek utána el kell távolítania.

A mítosz itt az, hogy a névszerver profilba írása megváltoztatja, hová mennek a lekérdezések. Azt változtatja meg, amit a feloldónak mondanak, nem azt, melyik socketet használja a feloldó felfelé. Teszteljen egy lekérdezéssel és egy útvonalkereséssel ahelyett, hogy bízna a fájlban.

A tűzfal állapota, és ki állítja helyre

A tűzfal szabályai a legtöbbször felülírt objektum egy VPN-gazdagépen. A kezelő kapcsolatonként NAT- vagy továbbítási szabályokat adhat hozzá, miközben az indítási tűzfalszolgáltatás újratölt egy mentett szabálykészletet, és törli azokat. Válasszon egyetlen hatóságot a házirendhez, és tegye a másikat annak fogyasztójává, vagy fogadja el, hogy az újraindítás csendben megváltoztatja a viselkedést. A kapcsolathoz kötött kivételek abba a fájlba tartoznak, amelyet ugyanaz a tulajdonos tölt be, nem egy hibaelhárítás közben beírt iptables-parancsba.

Ha a szabályoknak túl kell élniük egy újracsatlakozást, mondja ki nyíltan. Ha nem kell, azt is mondja ki, mert a következő mérnök a kényelmesebb választ fogja feltételezni.

Életciklus: rendszerindítás, újracsatlakozás, leszerelés

Adjon tulajdonost mindhárom pillanathoz. Indításkor döntse el, mi készíti elő az előfeltételeket, és milyen sorrendben. Puha újraindításnál ne feledje, hogy az eszköz túlélheti, míg a munkamenet állapota nem, ezért egy érvényesítőnek kell futnia, nem egy létrehozónak. Leszereléskor csak azt távolítsa el, amit ez a kapcsolat létrehozott, mert minden útvonal visszaállítása vagy a teljes tűzfal kiürítése nem ugyanaz, mint egyetlen alagút nyugdíjazása.

Megfigyeléshez a ip monitor link address route mutatja a kernel változásait, ahogy történnek, de eseményeket jelent, nem szándékot: egy törölt útvonal semmit sem mond arról, melyik folyamat törölte. Párosítsa a tulajdonosi térképpel, és egy zavaros leállítás rövid jelöltlistává válik.

A kivételeknek is áruk van. Egy egész eszközosztály kezeletlenként megjelölése a konfliktus elkerülésére senkinek adja át ezt az állapotot, ami döntés, nem javítás.

Kapcsolódó cikkek