Rekurzív útválasztás: amikor az alagút elkapja a saját csomagjait

Az alagút feljön, a napló befejezett kézfogást mutat, és egy másodperccel később ugyanaz a munkamenet meghal, és hurokban újra csatlakozik. Ennek a mintának konkrét oka van: a kiszolgálóhoz vezető útvonal most az alagút belsejébe mutat, ezért az alagutat szállító csomagok az alagúton keresztül mennek. A hitelesítésben semmi nem változott, ezért a hitelesítő adatok újbóli megadása nem segít. Hasonlítsa össze a külső útvonalat az útvonalváltozás előtt és után, és a rekurzió láthatóvá válik.

Először a külső útvonalat ellenőrizze

Két csomag van játékban, nem egy. A belső csomag az alkalmazásé, és titkosítottnak kellene lennie, míg a külső csomag a kiszolgálónak van címezve, és olyan útvonalon kell elérnie, amely nem függ az alagúttól.

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

Kérdezze meg a kerneltől a kiszolgáló címéhez vezető útvonalat, miután az alagút feljött, majd újra, miután az alapértelmezett útvonal megváltozott. Az a következő ugrás, amely az alagút eszközén landol, maga a rekurzió, és csomagrögzítés nélkül is látható. Az interfészhez kötés, a jelölések vagy egy hálózati névtér hiányossá teheti az egyszerű keresést, ezért használja azt a környezetet, amelyet maga a kliens használ. Ha a válasz helyesnek tűnik, de a munkamenet továbbra is hurkol, olvassa el az útválasztási szabályzat szabályait, ne csak a fő táblázatot.

Miért él túl a munkamenet egy pillanatig

A kézfogás az új útvonal telepítése előtt befejeződik, ezért az első másodpercek egészségesnek tűnnek. Amint a kliens hozzáadja az alapértelmezett útvonalat, a következő külső csomag követi azt abba az interfészbe, amelyen keresztül ennek a külső csomagnak haladnia kell. A kiszolgáló nem lát semmit, a kliens újraküld, és a kísérlet vagy lejár, vagy megöli a munkamenetet, és elölről kezdi.

Ez a sorrend magyarázza, miért működhet egy alagút hordozható gépen, és miért vall kudarcot útválasztón, és miért indul a hiba gyakran a forgalom indulásakor, nem a csatlakozáskor. A hurkot is magyarázza: minden újraindítás helyreállítja a munkamenetet, mielőtt az útvonal lehetetlenné tenné.

Keresse meg, kié a végpont kivétele

A támogatott kliensek maguk rendezik a kivételüket: gazdagép-útvonal a kiszolgálóhoz az eredeti átjárón keresztül, vagy olyan jelölés, amely az alagúton kívül tartja a külső foglalatot. A kérdés az, hogy valami más eltávolította-e vagy felülírta-e.

Az útvonalalapú IPsec esetében vizsgálja meg azokat a házirend-választókat, amelyek eldöntik, mely csomagok lépnek be az alagútba, és erősítse meg, hogy a partner címe ki van zárva belőlük. A WireGuardnál az interfész tűzfaljelölése és házirend-szabályai az alagúton kívül tartják a szállítási csomagokat, ezért egy kézzel hozzáadott alapértelmezett útvonal tönkreteheti ezt az elrendezést. Egy második VPN-profil vagy az alapértelmezett útvonalat átíró felügyeleti szkript a gyakori bűnös. Az egyenként hozzáadott széles megkerülő szabályok a szokásos eredmény, és egy útválasztási hibát olyan táblázattá alakítanak, amelyet senki nem tud karbantartani.

Hálózatváltás után ellenőrizze újra

Egy Wi-Fi-átjárón át vezető gazdagép-útvonal addig helyes, amíg a gép át nem kerül egy másik hálózatba. Aztán ugyanaz a tünet visszatér minden konfigurációváltozás nélkül.

Jegyezze fel a végpont címét, az útvonalat csatlakozás előtt és után, valamint az interfészt, amelyet mindegyik használt. Ez a három tény általában elválasztja a kliens hibáját a felülírástól, és túlélik azt a személyt, aki összegyűjtötte őket.

Csatlakozzon újra az új hálózaton, és ismételje meg az olvasást. Ha a kivétel ismét hiányzik, a javítás abba a profilba tartozik, amelyik birtokolja, nem egy kimaradás alatt beírt egyszeri parancsba.