Tunnelen er stadig oppe, ruten er væk: at skille to VPN-fejl ad

Én vært bliver utilgængelig, mens tunnelinterfacet stadig rapporterer sig som etableret, og de to observationer er ikke i konflikt. Noget fjernede den vej, trafikken brugte: en nabo trak sit præfiks tilbage, en sporet statisk rute blev fjernet, eller en anden rute blev foretrukket. Sikkerhedsassocieringen kan forblive helt sund gennem alle tre. At skille begivenhederne ad betyder at spørge, hvilket lag der ændrede sig først, frem for om VPN’en fejlede.

Tre faser, der ligner én begivenhed

En routingbeslutning har tre faser. Præfikset modtages, det vælges som det bedste, og det installeres i videresendingstabellen. Hver fase kan fejle alene, og fejlen ser identisk ud fra applikationens side. Et præfiks, der blev lært, men tabte udvælgelsen, kan ikke skelnes fra et, der aldrig nåede frem, når det eneste bevis, du ser på, er videresendingstabellen.

Derfor er det første spørgsmål, hvilken fase der brød sammen, ikke hvilken protokol der er skyld i det. Svaret afgør, hvem der ejer hændelsen, og hvilket værktøj den næste kontrol bruger.

Læs den installerede rute først

Spørg kernen, hvor trafikken til den fejlende destination faktisk går hen. ip route get udskriver det næste hop, interfacet og kildeadressen, som kernen ville bruge, og den svarer for én destination frem for hele tabellen. Hvis svaret angiver tunnelen, tror videresendingstabellen stadig, at vejen findes, og problemet ligger over den.

ip route get 10.20.5.10
ip route show 10.20.0.0/16

Et svar »unreachable« betyder, at der slet ikke er nogen installeret rute, hvilket peger på en tilbagetrækning eller en manglende installation. Et svar, der angiver et fysisk interface, betyder, at trafikken forlod tunnelen, uden at nogen besluttede det, og den næste kontrol er den præference, der vandt. Et svar, der angiver tunnelen, mens pakker stadig forsvinder, peger længere nede ad vejen, på filtrering eller på den fjerne side.

Se derefter protokollens eget billede

En routingdæmon holder mere end én tabel, og den interessante sammenligning er mellem dem. For BGP er nabasesionens tilstand, den modtagne annoncering og den installerede rute tre separate beviser. Et præfiks kan ligge i den modtagne tabel og aldrig nå kernen, fordi en rute med kortere administrativ afstand vinder. Kontrollér alle tre, før du konkluderer, at den anden side holdt op med at annoncere.

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

Oversigten fortæller, om sessionen er etableret, visningen pr. præfiks fortæller, om præfikset blev accepteret, og kernens opslag fortæller, om det blev installeret. At læse dem i den rækkefølge forhindrer, at en session, der blafrer, forveksles med en tilbagetrækning, og en tilbagetrækning med en afvisning på grund af politik.

Når urene er uenige

Sæt tunnel-loggen, routing-loggen og den første applikationsfejl på én tidslinje ved hjælp af deres rigtige tidszoner. Hvis naboens tab kommer først, tog tunnelen ruten ned med sig. Hvis tilbagetrækningen kommer først, ændrede routing sig, og tunnelen reagerede bagefter. Det er forskellige hændelser med forskellige ejere, og rækkefølgen er hele fundet.

Et minut af urforskydning er nok til at vende den konklusion, så bekræft tidszonen og forskydningen, før du stoler på rækkefølgen. Enheder, der logger i lokal tid uden forskydning, er den sædvanlige kilde til en selvsikker, men forkert tidslinje.

Genopretning uden en løkke

To veje kan være kvalificerede efter en tilbagetrækning: den, protokollen vælger, og den, du fastgør manuelt. Kun den første er en beslutning, netværket bliver ved med at træffe for dig, og derfor er en manuel rute en nødløsning frem for en genopretningsplan. En alternativ annoncering bevarer heller ikke firewall- eller NAT-tilstand for en session, der allerede er etableret, så nye flows kan virke, mens det oprindelige forbliver brudt. Bekræft, hvilken backup der skal blive aktiv, og om det fjerne sted vil acceptere en returvej gennem den.

Installer ikke en permanent statisk tilsidesættelse, før du forstår, hvorfor tilbagetrækningen skete. Den genvej kan fastgøre trafikken til en fejlet vej eller stille omgå en bevidst routingpolitik og begraver den oprindelige årsag under en ny konfiguration. Test applikationen igen, når ruten er genoprettet, og bekræft, at det valgte præfiks har en fungerende datavej og ikke kun en post i en tabel.