Tunel stoji, pot je izginila: ločevanje dveh okvar VPN

Eno gostiteljsko ime postane nedosegljivo, medtem ko vmesnik tunela še vedno poroča, da je vzpostavljen, in ti dve opažanji si nista v nasprotju. Nekaj je odstranilo pot, ki jo je uporabljal promet: sosed je umaknil svojo predpono, sledena statična pot je bila odstranjena ali je druga pot postala prednostna. Varnostna povezava lahko v vseh treh primerih ostane popolnoma zdrava. Ločiti dogodke pomeni vprašati, kateri sloj se je spremenil prvi, in ne ali je VPN odpovedal.

Tri stopnje, ki so videti kot en dogodek

Odločitev o usmerjanju ima tri stopnje. Predpona se prejme, izbere kot najboljša in namesti v tabelo posredovanja. Vsaka stopnja lahko odpove sama, in okvara je z vidika aplikacije videti enako. Predpone, ki se je naučila, a je izgubila izbiro, ni mogoče ločiti od tiste, ki nikoli ni prispela, kadar je edini dokaz, ki ga gledate, tabela posredovanja.

Zato je prvo vprašanje, katera stopnja se je zlomila, in ne kateri protokol je kriv. Odgovor določi, komu pripada incident in katero orodje bo uporabil naslednji pregled.

Najprej preberite nameščeno pot

Vprašajte jedro, kam promet do nedelujočega cilja v resnici gre. ip route get izpiše naslednji skok, vmesnik in izvorni naslov, ki bi ga jedro uporabilo, in odgovori za en cilj, ne za celo tabelo. Če odgovor navaja tunel, tabela posredovanja še vedno verjame, da pot obstaja, in težava je nad njo.

ip route get 10.20.5.10
ip route show 10.20.0.0/16

Odgovor «unreachable» pomeni, da ni nameščene nobene poti, kar kaže na umik ali manjkajočo namestitev. Odgovor, ki navaja fizični vmesnik, pomeni, da je promet zapustil tunel, ne da bi kdo to odločil, in naslednji pregled je prednost, ki je zmagala. Odgovor, ki navaja tunel, medtem ko paketi še vedno izginjajo, kaže dlje po poti, na filtriranje ali na drugo stran.

Nato poglejte lasten pogled protokola

Démon usmerjanja hrani več kot eno tabelo, in zanimiva primerjava je med njimi. Pri BGP so stanje sosednje seje, prejeto obvestilo in nameščena pot trije ločeni dokazi. Predpona lahko sedi v prejeti tabeli in nikoli ne doseže jedra, ker zmaga pot s krajšo upravno razdaljo. Preverite vse tri, preden sklepate, da je druga stran prenehala oglaševati.

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

Povzetek pove, ali je seja vzpostavljena, pogled po predponi pove, ali je bila predpona sprejeta, iskanje v jedru pa, ali je bila nameščena. Branje v tem vrstnem redu prepreči, da bi utripanje seje zamenjali z umikom, umik pa z zavrnitvijo zaradi politike.

Ko se ure ne strinjajo

Postavite dnevnik tunela, dnevnik usmerjanja in prvo okvaro aplikacije na eno časovnico z uporabo njihovih resničnih časovnih pasov. Če izguba soseda pride prva, je tunel potegnil pot s seboj. Če prvi pride umik, se je usmerjanje spremenilo, tunel pa se je odzval zatem. To so različni incidenti z različnimi lastniki, in vrstni red je cela ugotovitev.

Ena minuta odstopanja ure zadostuje, da to ugotovitev obrne, zato pred zaupanjem zaporedju potrdite časovni pas in odmik. Naprave, ki beležijo v lokalnem času brez odmika, so običajen vir samozavestne, a napačne časovnice.

Obnovitev brez zanke

Po umiku sta lahko primerni dve poti: tista, ki jo izbere protokol, in tista, ki jo pritrdite ročno. Le prva je odločitev, ki jo omrežje še naprej sprejema za vas, zato je ročna pot provizorična rešitev, ne načrt obnovitve. Nadomestno obvestilo tudi ne ohrani stanja požarnega zidu ali NAT za sejo, ki je že vzpostavljena, zato lahko novi tokovi delujejo, medtem ko prvotni ostane pokvarjen. Potrdite, katera rezerva naj postane aktivna, in ali bo oddaljeno mesto sprejelo povratno pot skozi njo.

Ne nameščajte trajnega statičnega prepisa, dokler ne razumete, zakaj je prišlo do umika. Ta bližnjica lahko pripne promet na neuspešno pot ali tiho obide namerno usmerjevalno politiko in pokoplje prvotni vzrok pod novo konfiguracijo. Ko je pot obnovljena, znova preizkusite aplikacijo in potrdite, da ima izbrana predpona delujočo podatkovno pot, ne le vnosa v tabeli.