Elszakad a VPN egy DHCP-megújítás után? Hasonlítsa össze a címeket

A bérlet megújítása és a VPN meghibásodása elég gyakran jelenik meg együtt a naplókban ahhoz, hogy az emberek arra következtessenek, az egyik okozza a másikat. Az időbeli egybeesés valódi; az okság általában nem. A megújítás egy unicast kérés a bérletet kiadó kiszolgáló felé, hogy folytathassa ugyanazt a kötést, és a kiszolgáló meghosszabbíthatja anélkül, hogy a kliens egyetlen címet is megváltoztatna. A kliens saját értékeinek vizsgálata az esemény körül elválasztja a csendben megújított bérletet attól a hálózattól, amely valóban megváltozott egy futó alagút alatt.

Kezdje azzal a klienssel, amelyik elszakadt

Először nyissa meg a kliens kapcsolati naplóját, és jegyezze fel a szakadás idejét másodpercig. Aztán nyissa meg az operációs rendszer hálózati naplóját ugyanarra a percre, és olvassa sorrendben, mit tett az interfész. Ez a sorrend az egész vizsgálat: a leválás előtti DHCP-esemény, a DHCP-esemény előtti leválás és két esemény, amelyek között semmi sincs, három különböző lelet. Az a naplósor, amely csak a bérletet említi, miközben az alagút már újra csatlakozott, díszítés, nem bizonyíték.

Írja le az idővonalat menet közben, ahelyett hogy fejben tartaná. A különböző eszközök időbélyegei ritkán egyeznek tökéletesen, és néha maga az eltérés a magyarázat.

Hasonlítsa össze a négy értéket az esemény körül

Négy érték elég jól leírja a kapcsolat helyi oldalát egy valódi változás megragadásához: az interfész címe, az alapértelmezett átjáró, a feloldók listája és az interfész üzemállapota. Rögzítse őket a szakadás utáni egy percen belül, és hasonlítsa össze egy olyan felvétellel, amely az alagút egészséges állapotában készült.

ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp

A változatlan cím változatlan átjáróval és megváltozott feloldólistával a névfeloldásra, nem az útválasztásra mutat, és az alagút túlélhette, miközben az alkalmazások abbahagyták a gazdagépek megtalálását. A megváltozott átjáró azt jelenti, hogy a helyi hálózatból kivezető út elmozdult, ami elég ahhoz, hogy érvénytelenítsen egy útvonalat, amely az előzőre mutatott. Ha mind a négy érték megegyezik az egészséges felvétellel, a bérlet nem az Ön oka, és a kliens saját újracsatlakozási logikája lesz a téma. Az összehasonlítást akkor készítse, amikor a hiba látható, mert az újraindítás után készült egészséges felvétel cím-előzménye más, és nem fog egyezni.

Mit változtathat meg egy megújítás és mit nem

A RFC 2131 a megújítást az eredeti kiszolgálóhoz intézett kérésként írja le a bérletidő felénél, újrakötéssel bármely kiszolgálóhoz a hét nyolcadánál, ha az első kísérlet válasz nélkül marad. Egyik lépés sem követeli meg, hogy a kliens más címet szerezzen, és az együttműködő kiszolgáló általában meghosszabbítja a meglévő kötést. A valódi címváltozás általában más úton érkezik: a kiszolgáló elutasítja a megújítást, a kliens elveszítette az állapotát és újrakezdte, vagy a hálózat más szegmensbe helyezte az eszközt.

A kapcsolat nyilvános oldala minden helyi változás nélkül is megváltozhat. Szolgáltatói szintű fordítás mögött a VPN-partner által látott cím függetlenül újraosztható attól, amit a helyi bérlet tett, és ez az újraosztás a kliensen belülről pontosan úgy néz ki, mint egy helyi hálózati hiba. A helyben jelentett cím és a partner oldali megfigyelés összehasonlítása az egyetlen módja az elkülönítésüknek.

Amikor a kliens nem tud alkalmazkodni

Az a kliens, amely a szállítását a régi címhez kötötte, elavult útvonalat tárolt a partnerhez, vagy elmentett egy interfész-identitást, tovább próbálkozhat egy már nem létező úton. Ez alkalmazkodási hiba, és úgy látszik, mint ismételt újraküldés egy cím felé, amelyet a gazdagép már nem ér el. Egyes kliensek ezt tervezésből kezelik: a WireGuard például frissíti a partner végpontját, amikor helyesen hitelesített csomag érkezik új forrásból.

A szolgáltatást visszaállító kézi újraindítás nyom arra, hol hibázott az alkalmazkodás, nem bizonyíték arra, hogy a bérletek és az alagutak összeférhetetlenek. Tartsa érvényben a blokkolási szabályzatot a tesztelés alatt, különben maga a teszt lesz más okú kiesés. Jegyezze fel, hogy a kliens magától helyreállt-e, mennyi ideig tartott, és melyik címet próbálta újra; ez a sorrend többet mond az interfészen látható leválási oknál.

Ismételje meg az eseményt, mielőtt okolná

Reprodukálja a feltételt ahelyett, hogy az ütemezésre várna: szabadítsa fel és újítsa meg a bérletet, vagy kényszerítse ki az egyenértékű ellenőrzött eseményt, és figyelje, túléli-e az alagút. Kezelt hálózaton egyeztessen minden címváltoztatást a hálózat tulajdonosával, mert egy önkényes statikus hozzárendelés ütközhet egy eszközzel, amely már birtokolja azt a címet.

Támogatott javítás után ismételje meg ugyanazt az eseményt, majd teszteljen egy alkalmazást és egy névkeresést, mert az az alagút, amely újracsatlakozik, de elrontja a DNS-t, gyengébb tesztet teljesít annál, amelyik számít. Jelentse a megfigyelt konkrét változást az időbélyegével, ahelyett hogy az ütemezett bérletet nevezné meg okként. A két jelentés közötti különbség az, hogy a következő ember reprodukálni tudja-e a hibát, vagy csak a pletykát.