Az alagút áll, az útvonal eltűnt: két VPN-hiba szétválasztása

Egy gazdagép elérhetetlenné válik, miközben az alagút interfésze továbbra is létrehozottként jelenti magát, és a két megfigyelés nem ellentmondásos. Valami eltávolította az útvonalat, amelyet a forgalom használt: egy szomszéd visszavonta az előtagját, egy követett statikus útvonalat eltávolítottak, vagy egy másik útvonal lett előnyben. A biztonsági társulás mindhárom esetben teljesen egészséges maradhat. Az események szétválasztása azt jelenti, hogy azt kérdezzük, melyik réteg változott először, nem pedig azt, hogy meghibásodott-e a VPN.

Három szakasz, amely egyetlen eseménynek látszik

Egy útválasztási döntésnek három szakasza van. Az előtag fogadása, a legjobbnak választása és a továbbítási táblába telepítése. Mindegyik szakasz önmagában is meghiúsulhat, és a hiba az alkalmazás felől azonosnak látszik. Egy előtag, amelyet megtanultak, de elvesztette a kiválasztást, nem különböztethető meg attól, amely soha nem érkezett meg, ha az egyetlen bizonyíték, amelyet néz, a továbbítási tábla.

Ezért az első kérdés az, melyik szakasz tört el, nem az, melyik protokoll a hibás. A válasz dönti el, kié az esemény, és melyik eszközt használja a következő ellenőrzés.

Először a telepített útvonalat olvassa

Kérdezze meg a kerneltől, hová megy valójában a forgalom a meghibásodott cél felé. ip route get kiírja a következő ugrást, az interfészt és a forrás címet, amelyet a kernel használna, és egy célra válaszol, nem az egész táblára. Ha a válasz az alagutat nevezi meg, a továbbítási tábla még mindig hisz az útvonal létezésében, és a probléma fölötte van.

ip route get 10.20.5.10
ip route show 10.20.0.0/16

Az «unreachable» válasz azt jelenti, hogy egyáltalán nincs telepített útvonal, ami visszavonásra vagy hiányzó telepítésre utal. A fizikai interfészt megnevező válasz azt jelenti, hogy a forgalom elhagyta az alagutat anélkül, hogy bárki így döntött volna, és a következő ellenőrzés az a preferencia, amely nyert. Ha viszont a csomagok továbbra is eltűnnek, miközben a válasz az alagutat nevezi meg, az tovább mutat az útvonalon, a szűrésre vagy a túloldalra.

Aztán nézze meg a protokoll saját nézetét

Egy útválasztó démon több táblát is tart, és az érdekes összehasonlítás közöttük van. BGP esetén a szomszéd munkamenet állapota, a fogadott hirdetmény és a telepített útvonal három külön bizonyíték. Egy előtag ülhet a fogadott táblában, és soha nem érheti el a kernelt, mert egy rövidebb adminisztratív távolságú útvonal nyer. Ellenőrizze mindhármat, mielőtt arra következtetne, hogy a másik fél abbahagyta a hirdetést.

vtysh -c "show bgp summary"
vtysh -c "show bgp ipv4 unicast 10.20.0.0/16"

Az összegzés megmondja, hogy a munkamenet létrejött-e, az előtagonkénti nézet megmondja, hogy az előtagot elfogadták-e, a kernelkeresés pedig azt, hogy telepítették-e. Ebben a sorrendben olvasva elkerülhető, hogy egy munkamenet-rezgést visszavonással, a visszavonást pedig szabályzati elutasítással keverjenek össze.

Amikor az órák nem értenek egyet

Tegye az alagút naplóját, az útválasztási naplót és az alkalmazás első hibáját egy idővonalra, valódi időzónáik használatával. Ha a szomszéd elvesztése jön előbb, az alagút magával rántotta az útvonalat. Ha a visszavonás jön előbb, az útválasztás változott, és az alagút utána reagált. Ezek különböző események különböző tulajdonosokkal, és a sorrend maga a teljes lelet.

Egy perc óraeltérés is elég ahhoz, hogy megfordítsa ezt a következtetést, ezért erősítse meg az időzónát és az eltolást, mielőtt megbízik a sorrendben. Azok az eszközök, amelyek eltolás nélkül, helyi időben naplóznak, a magabiztos, de hibás idővonal szokásos forrása.

Helyreállítás hurok nélkül

Visszavonás után két útvonal lehet alkalmas: amelyet a protokoll kiválaszt, és amelyet kézzel rögzít. Csak az első olyan döntés, amelyet a hálózat továbbra is Ön helyett hoz, ezért a kézi útvonal ideiglenes megoldás, nem helyreállítási terv. A helyettesítő hirdetmény sem őrzi meg a tűzfal vagy a NAT állapotát egy már létrehozott munkamenethez, így az új folyamok működhetnek, miközben az eredeti törötten marad. Erősítse meg, melyik tartalék út váljon aktívvá, és hogy a távoli hely elfogad-e visszafelé útvonalat rajta keresztül.

Ne telepítsen állandó statikus felülírást, amíg meg nem értette, miért történt a visszavonás. Ez a rövidítés egy meghibásodott útvonalhoz rögzítheti a forgalmat, vagy csendesen megkerülhet egy szándékos útválasztási szabályzatot, és az eredeti okot egy új konfiguráció alá temeti. A helyreállítás után tesztelje újra az alkalmazást, és erősítse meg, hogy a kiválasztott előtag működő adatútvonallal rendelkezik, nem csak egy táblabeli bejegyzéssel.