Tunel stojí, trasa zmizela: jak oddělit dvě selhání VPN

Jeden hostitel přestane být dostupný, zatímco rozhraní tunelu se stále hlásí jako navázané, a tato dvě pozorování si neodporují. Něco odstranilo cestu, kterou provoz používal: soused stáhl svůj prefix, sledovaná statická trasa byla odebrána nebo se jiná trasa stala preferovanou. Bezpečnostní asociace může zůstat ve všech třech případech zcela zdravá. Oddělit události znamená ptát se, která vrstva se změnila první, a ne zda VPN selhala.

Tři fáze, které vypadají jako jedna událost

Směrovací rozhodnutí má tři fáze. Prefix je přijat, vybrán jako nejlepší a nainstalován do předávací tabulky. Každá fáze může selhat sama o sobě a selhání vypadá z pohledu aplikace stejně. Prefix, který byl naučen, ale prohrál výběr, nelze odlišit od toho, který nikdy nedorazil, když jediným důkazem, na který se díváte, je předávací tabulka.

Proto je první otázkou, která fáze se rozbila, a ne který protokol je na vině. Odpověď rozhoduje o tom, komu incident patří a který nástroj použije další kontrola.

Nejprve si přečtěte nainstalovanou trasu

Zeptejte se jádra, kam provoz k selhávajícímu cíli skutečně jde. ip route get vypíše další skok, rozhraní a zdrojovou adresu, kterou by jádro použilo, a odpovídá pro jeden cíl, nikoli pro celou tabulku. Pokud odpověď jmenuje tunel, předávací tabulka stále věří, že cesta existuje, a problém je nad ní.

ip route get 10.20.5.10
ip route show 10.20.0.0/16

Odpověď „unreachable“ znamená, že není nainstalována žádná trasa, což ukazuje na stažení nebo chybějící instalaci. Odpověď, která jmenuje fyzické rozhraní, znamená, že provoz opustil tunel, aniž by o tom někdo rozhodl, a další kontrolou je preference, která vyhrála. Odpověď, která jmenuje tunel, zatímco pakety stále mizí, ukazuje dál po cestě, na filtrování nebo na vzdálenou stranu.

Potom se podívejte na vlastní pohled protokolu

Směrovací démon drží více než jednu tabulku a zajímavé srovnání je mezi nimi. U BGP jsou stav sousední relace, přijaté oznámení a nainstalovaná trasa tři oddělené důkazy. Prefix může sedět v přijaté tabulce a nikdy se nedostat do jádra, protože vyhraje trasa s kratší administrativní vzdáleností. Zkontrolujte všechny tři, než usoudíte, že druhá strana přestala oznamovat.

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

Souhrn vám řekne, zda je relace navázaná, pohled podle prefixu, zda byl prefix přijat, a dotaz do jádra, zda byl nainstalován. Čtení v tomto pořadí zabrání tomu, aby byly zákmity relace zaměněny za stažení a stažení za odmítnutí podle politiky.

Když se hodiny rozcházejí

Umístěte protokol tunelu, směrovací protokol a první selhání aplikace na jednu časovou osu s použitím jejich skutečných časových pásem. Pokud ztráta souseda přichází první, tunel s sebou stáhl i trasu. Pokud první přichází stažení, směrování se změnilo a tunel reagoval až potom. To jsou různé incidenty s různými vlastníky a pořadí je celý nález.

Jedna minuta odchylky hodin stačí k tomu, aby tento závěr obrátila, takže před důvěrou v posloupnost potvrďte časové pásmo a posun. Zařízení, která logují v místním čase bez posunu, jsou obvyklým zdrojem sebevědomé, ale chybné časové osy.

Obnova bez smyčky

Po stažení mohou být vhodné dvě cesty: ta, kterou vybírá protokol, a ta, kterou připnete ručně. Jen první je rozhodnutí, které za vás síť stále dělá, a proto je ruční trasa provizorní řešení, nikoli plán obnovy. Náhradní oznámení také nezachová stav firewallu ani NAT pro relaci, která už je navázaná, takže nové toky mohou fungovat, zatímco původní zůstává rozbitý. Potvrďte, která záloha má být aktivní a zda vzdálené pracoviště přijme zpětnou cestu přes ni.

Neinstalujte trvalé statické přepsání, dokud nepochopíte, proč ke stažení došlo. Tato zkratka může připnout provoz na selhanou cestu nebo tiše obejít záměrnou směrovací politiku a pohřbí původní příčinu pod novou konfiguraci. Po obnovení trasy aplikaci znovu otestujte a potvrďte, že zvolený prefix má funkční datovou cestu, ne jen záznam v tabulce.