Tunel stojí, trasa zmizla: oddelenie dvoch zlyhaní VPN

Jeden hostiteľ sa stane nedostupným, hoci rozhranie tunela sa stále hlási ako vytvorené, a tieto dve pozorovania si neodporujú. Niečo odstránilo cestu, ktorú premávka používala: sused stiahol svoj prefix, sledovaná statická trasa bola odstránená, alebo sa iná trasa stala preferovanou. Bezpečnostná asociácia môže zostať vo všetkých troch prípadoch úplne zdravá. Oddeliť udalosti znamená pýtať sa, ktorá vrstva sa zmenila prvá, a nie či VPN zlyhalo.

Tri fázy, ktoré vyzerajú ako jedna udalosť

Rozhodnutie o smerovaní má tri fázy. Prefix sa prijme, vyberie ako najlepší a nainštaluje do tabuľky preposielania. Každá fáza môže zlyhať sama, a zlyhanie vyzerá z pohľadu aplikácie rovnako. Prefix, ktorý sa naučil, ale prehral výber, nemožno odlíšiť od toho, ktorý nikdy neprišiel, keď je jediným dôkazom, na ktorý sa pozeráte, tabuľka preposielania.

Preto je prvou otázkou, ktorá fáza sa zlomila, nie ktorý protokol je na vine. Odpoveď určuje, komu incident patrí a ktorý nástroj použije ďalšia kontrola.

Najprv si prečítajte nainštalovanú trasu

Spýtajte sa jadra, kam premávka k zlyhávajúcemu cieľu skutočne ide. ip route get vypíše ďalší skok, rozhranie a zdrojovú adresu, ktorú by jadro použilo, a odpovedá pre jeden cieľ, nie pre celú tabuľku. Ak odpoveď menuje tunel, tabuľka preposielania stále verí, že cesta existuje, a problém je nad ňou.

ip route get 10.20.5.10
ip route show 10.20.0.0/16

Odpoveď «unreachable» znamená, že nie je nainštalovaná žiadna trasa, čo ukazuje na stiahnutie alebo chýbajúcu inštaláciu. Odpoveď, ktorá menuje fyzické rozhranie, znamená, že premávka opustila tunel bez toho, aby o tom niekto rozhodol, a ďalšou kontrolou je preferencia, ktorá vyhrala. Odpoveď, ktorá menuje tunel, kým pakety stále miznú, ukazuje ďalej po ceste, na filtrovanie alebo na druhú stranu.

Potom sa pozrite na vlastný pohľad protokolu

Démon smerovania drží viac než jednu tabuľku, a zaujímavé porovnanie je medzi nimi. Pri BGP sú stav susednej relácie, prijaté oznámenie a nainštalovaná trasa tri oddelené dôkazy. Prefix môže sedieť v prijatej tabuľke a nikdy sa nedostať do jadra, pretože vyhrá trasa s kratšou administratívnou vzdialenosťou. Skontrolujte všetky tri, kým usúdite, že druhá strana prestala oznamovať.

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

Súhrn vám povie, či je relácia vytvorená, pohľad podľa prefixu, či bol prefix prijatý, a dopyt do jadra, či bol nainštalovaný. Ich čítanie v tomto poradí zabráni tomu, aby bolo blikanie relácie zamenené za stiahnutie a stiahnutie za odmietnutie podľa politiky.

Keď sa hodiny nezhodujú

Umiestnite protokol tunela, smerovací protokol a prvé zlyhanie aplikácie na jednu časovú os s použitím ich skutočných časových pásiem. Ak strata suseda prichádza prvá, tunel stiahol trasu so sebou. Ak prvé prichádza stiahnutie, smerovanie sa zmenilo a tunel reagoval až potom. To sú rôzne incidenty s rôznymi vlastníkmi a poradie je celý nález.

Jedna minúta odchýlky hodín stačí na to, aby tento záver obrátila, preto pred dôverou v postupnosť potvrďte časové pásmo a posun. Zariadenia, ktoré logujú v miestnom čase bez posunu, sú obvyklým zdrojom sebavedomej, ale nesprávnej časovej osi.

Obnova bez slučky

Po stiahnutí môžu byť vhodné dve cesty: tá, ktorú vyberá protokol, a tá, ktorú pripnete ručne. Len prvá je rozhodnutie, ktoré za vás sieť stále robí, a preto je ručná trasa provizórne riešenie, nie plán obnovy. Náhradné oznámenie tiež nezachováva stav firewallu ani NAT pre reláciu, ktorá už je vytvorená, takže nové toky môžu fungovať, kým pôvodný zostáva pokazený. Potvrďte, ktorá záloha má byť aktívna a či vzdialené pracovisko prijme spätnú cestu cez ňu.

Neinštalujte trvalé statické prepísanie, kým nepochopíte, prečo k stiahnutiu došlo. Táto skratka môže pripnúť premávku na zlyhanú cestu alebo potichu obísť zámernú smerovaciu politiku a pochová pôvodnú príčinu pod novou konfiguráciou. Po obnovení trasy aplikáciu znova otestujte a potvrďte, že zvolený prefix má funkčnú dátovú cestu, nielen záznam v tabuľke.