Az OpenVPN megszakad egy DHCP-megújítás után: tartsa meg a végpont útvonalát

A tunnel csatlakozik, majd a hozzáférési linken egy bérlet-megújítás megöli, és a napló útvonal helyett időtúllépést okol. A VPN konfigurációjában semmi sem változott, és épp ez a nyom: valami azon kívül változott meg. Egy DHCP-esemény átírta a címet vagy az átjárót, és a hoszt-útvonal, amely elérhetőn tartotta a tunnel végpontját, most egy olyan következő ugrásra mutat, amely már nem létezik. Ez birtoklási probléma, mielőtt útvonalválasztási probléma lenne.

Hasonlítsa össze a tünetet a fél-alapértelmezett útvonalakkal

redirect-gateway def1 használatával az OpenVPN 0.0.0.0/1 és 128.0.0.0/1 útvonalat telepít az alapértelmezett útvonal lecserélése helyett. Együtt a kettő az egész címteret lefedi, és már puszta előtaghosszal legyőzi a 0.0.0.0/0 útvonalat. Ezért minden cél pontosabb egyezés nélkül a tunnelbe kerül.

A végpontnak kivételre van szüksége. Az OpenVPN hoszt-útvonalat ad a kiszolgáló címéhez az eredeti hozzáférési átjárón keresztül, mielőtt a fél-alapértelmezettek bekerülnek, hogy a beágyazott csomagok kijuthassanak. Amikor ez a kivétel eltűnik, vagy olyan következő ugrást tart meg, amely már nem létezik, a tunnel saját külső csomagjai egy fél-alapértelmezettel egyeznek, és visszakerülnek a tunnelbe. Az eredmény egy kapcsolat, amely a következő keepalive vagy kézfogás során meghal, és a naplóban semmi sem hasonlít útvonalválasztási hibára.

Erősítse meg a tábla alakját, mielőtt bármi máshoz hozzányúl. A ip route show parancsnak mindkét felet fel kell sorolnia, plusz egy hoszt-útvonalat a kiszolgáló címéhez; ha a hoszt-útvonal hiányzik, a vizsgálat többi részének nyilvánvaló kiindulópontja van.

Miért nyernek a fél-alapértelmezettek metrika módosítása nélkül

Az alacsonyabb metrika nem győzi le a hosszabb előtagot. A /1 útvonalak azért nyernek, mert a kernel először a legpontosabb útvonalat egyezteti, így az alapértelmezett útvonal metrikájának emelése semmit sem változtat azon, hova megy a tunnelbe tartó forgalom. A metrikák hajszolása a leggyakoribb rossz irány ebben a diagnózisban.

Ellenőrizze a választást a ip route get 203.0.113.10 paranccsal, a valódi kiszolgálócímet behelyettesítve. A válasz megnevezi az interfészt és a következő ugrást, amelyet a kernel valóban használna, ami tanulságosabb, mint egy táblát olvasni és arról gondolkodni.

Futtassa ezt a parancsot a tunnel indulása előtt, működés közben és a bérletesemény után. Három válasz egyetlen parancsból, és láthatóvá válik az eltérés pontja.

Három pillanatképet vegyen, ne egyet

Gyűjtse össze a hozzáférési címet, a hozzáférési átjárót, a végpont célját, a kiválasztott útvonalat és bármilyen házirend-szabályt három pillanatban: a hozzáférési link beállítása után, a VPN csatlakozása után és a bérlet- vagy szolgáltatói esemény után. Minden pillanatkép egy marék parancs, és csak együtt van értelmük. Egyetlen hiba utáni pillanatkép az állapotot rögzíti, nem az átmenetet. Írja a parancsokat egy kis szkriptbe, hogy minden pillanatkép ugyanúgy készüljön.

Tartsa a pillanatképeket egy fájlban időbélyegekkel, mert a későbbi érdekes kérdés a sorrend. A DHCP-esemény azelőtt vagy azután érkezett, hogy a OpenVPN frissítette volna az útvonalát? A válasz dönti el, kinek kell megjavítania. A rossz óráról származó időbélyeg rosszabb a semminél, ezért az útvonaltáblát birtokló hosztról vegye.

Amikor a végpont cím helyett névként van beállítva, minden pillanatképben oldja fel azt is. A hozzáférési linken történő DNS-változás elmozdíthatja a végpontot anélkül, hogy bármely útvonalhoz hozzányúlnának.

Döntse el, melyik komponens frissíti a kivételt

Egy dhcpcd rendszeren a hookok a hook-könyvtárból és a kilépési hookból futnak, és a menedzser mód hatóköre eltér az interfészenkénti módtól. Bármit tesz is a hook, idempotensnek kell lennie, mert a megújítások sorozatokban érkezhetnek.

A megbízható birtokos az az integráció, amely már mindkét oldalt ismeri: egy hálózatkezelő, amely a VPN-kapcsolatot kezeli, vagy egy unit, amely a hozzáférési link feljövetele után van sorrendezve. A hook által hozzáadott statikus útvonal a következő átjáróváltozásig működik, majd pontosan ugyanúgy meghibásodik. Ha mégis hookot használ, olvastassa vele futásidőben az aktuális átjárót, ahelyett hogy a mait keménykódolná.

Rögzítse a birtokost a konfiguráción belül. A következő embernek, aki újracsatlakozást hibakeres, tudnia kell, hogy a kivétel-útvonalért egy hook, nem a VPN felelős.

Tesztelje az életciklust, ne csak az újracsatlakozást

Kényszerítsen megújítást a dhcpcd -n eth0 paranccsal vagy a bérlet elengedésével és újrafelvételével, majd ellenőrizze újra a végpontot a ip route get paranccsal. Tegye ezt kétszer, mert a második futás elkapja azokat a hookokat, amelyek duplikált útvonalakat adnak hozzá. Aztán indítsa újra, mert a tartósság más tulajdonság, mint a helyesség.

Az a tunnel, amely túlél egy megújítást és egy újraindítást, birtokossal és működő kivétellel rendelkezik. Amelyik csak egy kézi újraindítást él túl, egyikkel sem rendelkezik, és a következő olyan eseménynél fog meghibásodni, amelyet nem tud ütemezni.