A WAN IP megváltozott és az alagút leesett: az ellenőrzések sorrendben

Az alagút leesik, az útválasztó újracsatlakozást naplóz, és a helyi hálózaton semmi sem mozdult. Az új WAN-cím érvényteleníti a külső kapcsolatot anélkül, hogy belül bármi változna: az ügyfél forráscíme megváltozott, a régi NAT-állapot egy már nem létező forrásra mutat, és a távoli partner talán még mindig az előző címre küld. A helyreállás normális viselkedés, és a hasznos kérdés az, melyik állapot nem frissült.

Nevezze meg az eseményt, mielőtt a naplót olvassa

Ellenőrizze, mi történt valójában a hozzáférési rétegen. Az internetszolgáltatói bérlet megújítása egy esemény. Az újracsatlakozott PPPoE-munkamenet egy másik. Az újraindított optikai modem vagy az egyik feltöltési kapcsolatról a másikra történő WAN-átállás harmadik módon változtatja meg a külső címet vagy annak útvonalát. Nem ugyanaz az esemény, és nem ugyanazt a maradékot hagyják.

A VPN-napló újracsatlakozási sora sem bizonyíték a WAN változására. Az üresjárati időtúllépés, az újrahitelesítési intervallum és a halott partner észlelése mind újracsatlakozást eredményez címváltozás nélkül. Hasonlítsa össze a hozzáférési napló időbélyegeit a VPN-naplóval, mielőtt bármit megállapítana, és tartsa elég szélesen az összehasonlítási ablakot ahhoz, hogy elkapjon egy éjszaka történt változást.

A barangolás és az újracsatlakozás különböző protokollok

A WireGuardban hitelesített barangolás van beépítve a protokollba: amikor egy partner helyesen hitelesített csomagot kap egy új forráscímről, frissíti annak a partnernek a végpontját. A WireGuard gyors kezdete leírja azt a partnerkonfigurációt, amely ezt lehetővé teszi, ezért a változó címen lévő ügyfél gyakran látható újraindítás nélkül áll helyre.

Az OpenVPN alapértelmezés szerint másképp viselkedik. Egy UDP-munkamenet véget érhet és újracsatlakozhat, az opcionális float-viselkedés pedig lehetővé teszi egy hitelesített partner számára, hogy új címről folytassa ott, ahol a konfiguráció engedi. A TCP-alapú alagutak szigorúbbak, mert maga a kapcsolat a címpárhoz kötődik. Ez a különbség dönti el, hogy a helyreállás láthatatlannak tűnik-e, vagy minden alkalommal bejelenti magát a naplóban.

Egyik viselkedés sem mond semmit a belső alkalmazásokról. A helyreállt alagút nem állít helyre egy TCP-munkamenetet, amelyet a partner már halottnak tartott.

Az alagút nem birtokolja ezt az állapotot

A fordítási és útválasztási állapot meglepő módon túléli az újracsatlakozást. A régi forráshoz létrehozott conntrack-bejegyzés a válaszútvonalat egy már nem létező címhez rögzíti, és a saját ütemezése szerint jár le, nem akkor, amikor az alagút visszatért. Az alagútszolgáltatás újraindítása nem rövidíti meg ezt a várakozást, így a javított kapcsolat egy ideig még töröttnek tűnhet.

Az útvonalak és házirend-szabályok hivatkozhatnak a régi átjáróra vagy interfészre. Egy WAN-váltás előtt helyes szabálykészlet olyan eszközre mutathat, amely most leállt, ami olyan alagutat eredményez, amely kapcsolódottnak jelentkezik, és olyan forgalmat, amely sehova sem megy. A hosztolt kiszolgáló dinamikus DNS-e külön probléma az új forrást kapó ügyféltől. A rekordot frissíteni kell, hogy a távoli ügyfelek megtalálják Önt, és semmilyen ügyféloldali konfiguráció nem kompenzál egy címet, amelyet a felsőbb szintű fordítás nem továbbít.

Rendezze az ellenőrzéseket kívülről befelé

Az alábbi sorrend a külső kapcsolattól befelé halad, és az teszi hasznossá, hogy az első sikertelen lépésnél megáll: minden kör kizárja a fölötte lévő réteget. Tartsa ezt a sorrendet akkor is, ha a hiba nyilvánvalónak tűnik.

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

Az első parancs megmutatja az aktuális végpontot és a kézfogás korát minden partnernél. A második és a harmadik megmutatja, hogy a külső interfész és a végpont felé vezető útvonal még értelmes-e. A conntrack-szám durva ellenőrzés az előző címről visszamaradt állapotra, a napló pedig az a hely, ahol az újracsatlakozás okát rögzítik.

Ezután helyi hálózati ügyfélről teszteljen, ne az útválasztóról. A maga az útválasztó által küldött ping más útvonalat használ, mint a továbbított forgalom, így a sikeres útválasztói ping bizonyítja, hogy létezik az alagút, és semmit sem mond az ügyfél elérhetőségéről.

Döntse el az elvárt viselkedést, és írja le

Az újracsatlakozás a legtöbb telepítésnél helyes viselkedés, tehát a cél nem annak megakadályozása. Döntse el inkább, mi történjen a forgalommal a szünet alatt: állítsa le, tartsa vissza, vagy váltson át egy másik útvonalra. Ez a döntés a tűzfalhoz és az útválasztási házirendhez tartozik, nem a VPN-profilhoz.

Rögzítse a hozzáférési eseményeket és az újracsatlakozási időpontokat együtt egy hétig. Az ismétlődő változások megfelelő hozzáférési esemény nélkül a hozzáférési szolgáltatásra utalnak, és a VPN-profil cseréje nem javítja meg azt a feltöltési kapcsolatot, amely folyton újratárgyal. Egyetlen bejegyzéspár ugyanabban a percben eldönti a kérdést arra az esetre, és kiindulópontot ad a következőnek.