Miért jön vissza egy törölt VPN-útvonal újracsatlakozás után

Egy útvonal, amelyet kézzel törölt, a következő újracsatlakozás után visszatér, és a tábla pontosan úgy néz ki, mint korábban. Ez nem útvonalválasztási hiba: valami újra létrehozza a bejegyzést a konfigurációból vagy a kapcsolat életciklusának egy műveletéből. A legtöbb runbook az élő táblánál megáll, ezért tűnik úgy, hogy a törlés egy percig működik, majd meghiúsul. Azonosítsa a tulajdonost, változtassa meg, és bizonyítsa újracsatlakozáskor.

Ki telepítette az útvonalat

Kezdje a jelöltek listájával, ne egy javítással. A VPN-profil saját útvonalakat hordozhat, a szerver küldheti őket csatlakozáskor, a hálózatkezelő profil deklarálhatja őket, egy boot egység vagy szkript hozzáadhatja őket, és az IPsec-megvalósítások útvonalakat telepítenek az általuk tárgyalt forgalomválasztókhoz. A házirend-alapú útválasztási szabályok a forgalmat teljesen egy másik táblába is átirányíthatják.

Az időzítés gyorsabban választja szét őket, mint a konfiguráció régészete. A bejegyzés, amely abban a pillanatban jelenik meg, amikor az interfész feljön, az ügyfélé; az, amely egy másodperccel később érkezik, általában szerver-pushból jön; az, amely bootkor létezik, a mentett konfigurációé. Rögzítse a táblát csatlakozás, leválasztás és újraindítás előtt és után, és a minta megnevezi a tulajdonost. Az az útvonal, amely csak a szolgáltatás újraindításakor tér vissza, egységre utal, nem a VPN-re.

Olvassa el a táblát, mielőtt szerkeszti

A kernel saját nézetét nézze, ne egy mentett fájlt. A protokoll oszlop megmutatja, mi telepítette az egyes bejegyzéseket:

ip route show
ip route show table all
ip rule show

A protokoll mező, a metrika és a táblaszám megmondja, hogy statikus bejegyzést, a kernel által létrehozott bejegyzést vagy egy démon által hozzáadott dolgot néz-e. A szabálylista azért fontos, mert egy keresés teljesen elhagyhatja a fő táblát, ami ott egy szerkesztést láthatatlanná tesz a hibakeresett alkalmazás számára. Olvassa a sort balról jobbra: cél, átjáró, eszköz, protokoll és metrika.

Ezután kérdezze meg a kernelt, melyik útvonalat használná valójában. A védett cím jobb próba, mint egy nyilvános:

ip route get 10.20.5.7

A tulajdonost változtassa meg, ne a tünetet

Ha a tulajdonos ismert, a változtatás ahhoz a tulajdonoshoz tartozik. Távolítsa el az útvonalat az ügyfélprofilból, javítsa a küldött útvonalat a szerveren, vagy szerkessze a hálózatkezelő kapcsolatát ahelyett, hogy egy versengő állandó útvonalat adna hozzá, amely metrika szerint nyer. Két egymással harcoló szabály olyan táblát hoz létre, amelyet később senki sem tud megmagyarázni.

Tartsa meg a végpont kizárását. Az a hostútvonal, amely a VPN-szerver saját nyilvános címét a fizikai átjárón keresztül küldi, az tartja áramlásban a külső alagútcsomagokat; törölje, és az alagút megpróbálja önmagát vinni. Split-tunnel profilban ugyanez a gondosság vonatkozik azokra a helyi alhálózatokra, amelyeknek meg kell kerülniük az alagutat.

Csatlakozzon újra, és ellenőrizze mindkét utat

Csatlakozzon újra, majd ellenőrizze mindkét célt egy menetben. A védett cím és a kizárt végpont különböző kérdésekre válaszol:

ip route get 10.20.5.7
ip route get 198.51.100.20

Az elsőnek az alagút interfészén, a másodiknak a fizikai átjárón keresztül kell feloldódnia. Ha mindkettő az alagúton keresztül oldódik fel, hiányzik a kizárás; ha egyik sem, a profilváltozás nem lépett életbe, és más tulajdonost néz, mint gondolta.

Írja fel az útvonal célját, tulajdonosát és azt, hogy meddig kell élnie. Ez a jegyzet az, ami megakadályozza, hogy a következő ember megismételje ugyanazt a törlés-és-újracsatlakozás ciklust.