Tunnelen står, ruten er borte: skille to VPN-feil

Én vert blir utilgjengelig mens tunnelgrensesnittet fortsatt rapporterer at det er etablert, og de to observasjonene er ikke i konflikt. Noe fjernet veien trafikken brukte: en nabo trakk tilbake prefikset sitt, en overvåket statisk rute ble fjernet, eller en annen rute ble foretrukket. Sikkerhetsassosiasjonen kan forbli helt sunn gjennom alle tre. Å skille hendelsene betyr å spørre hvilket lag som endret seg først, ikke om VPN-en feilet.

Tre trinn som ser ut som én hendelse

En rutingsbeslutning har tre trinn. Prefikset mottas, velges som det beste og installeres i videresendingstabellen. Hvert trinn kan feile alene, og feilen ser identisk ut fra applikasjonssiden. Et prefiks som ble lært, men tapte utvelgelsen, kan ikke skilles fra et som aldri kom frem når det eneste beviset du ser på er videresendingstabellen.

Derfor er det første spørsmålet hvilket trinn som brøt sammen, ikke hvilken protokoll som har skylden. Svaret avgjør hvem som eier hendelsen og hvilket verktøy neste sjekk bruker.

Les den installerte ruten først

Spør kjernen hvor trafikken til den feilende destinasjonen faktisk går. ip route get skriver ut neste hopp, grensesnittet og kildeadressen kjernen ville brukt, og den svarer for én destinasjon i stedet for hele tabellen. Hvis svaret navngir tunnelen, tror videresendingstabellen fortsatt at veien finnes, og problemet ligger over den.

ip route get 10.20.5.10
ip route show 10.20.0.0/16

Et svar «unreachable» betyr at det ikke finnes noen installert rute i det hele tatt, noe som peker på en tilbaketrekking eller en manglende installasjon. Et svar som navngir et fysisk grensesnitt betyr at trafikken forlot tunnelen uten at noen bestemte det, og neste sjekk er preferansen som vant. Et svar som navngir tunnelen mens pakkene fortsatt forsvinner, peker lenger ned i veien, på filtrering eller på den andre siden.

Se deretter på protokollens eget bilde

En rutingsdaemon holder mer enn én tabell, og den interessante sammenligningen er mellom dem. For BGP er nabosesjonens tilstand, den mottatte annonseringen og den installerte ruten tre separate bevis. Et prefiks kan sitte i den mottatte tabellen og aldri nå kjernen fordi en rute med kortere administrativ avstand vinner. Sjekk alle tre før du konkluderer med at den andre siden sluttet å annonsere.

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

Sammendraget forteller om sesjonen er etablert, visningen per prefiks forteller om prefikset ble godtatt, og kernesøket forteller om det ble installert. Å lese dem i den rekkefølgen forhindrer at en sesjon som blafrer blir forvekslet med en tilbaketrekking, og en tilbaketrekking med en avvisning på grunn av policy.

Når klokkene er uenige

Sett tunnel-loggen, ruting-loggen og den første applikasjonsfeilen på én tidslinje ved hjelp av deres virkelige tidssoner. Hvis nabotapet kommer først, tok tunnelen ruten ned med seg. Hvis tilbaketrekkingen kommer først, endret rutingen seg, og tunnelen reagerte etterpå. Det er forskjellige hendelser med forskjellige eiere, og rekkefølgen er hele funnet.

Ett minutt med klokkeforskjell er nok til å snu den konklusjonen, så bekreft tidssonen og forskyvningen før du stoler på rekkefølgen. Enheter som logger i lokal tid uten forskyvning er den vanlige kilden til en selvsikker, men feil tidslinje.

Gjenoppretting uten løkke

To veier kan være kvalifiserte etter en tilbaketrekking: den protokollen velger, og den du fester for hånd. Bare den første er en beslutning nettverket fortsetter å ta for deg, og derfor er en manuell rute en nødløsning fremfor en gjenopprettingsplan. En alternativ annonsering bevarer heller ikke brannmur- eller NAT-tilstand for en sesjon som allerede er etablert, så nye flyter kan virke mens den opprinnelige forblir brutt. Bekreft hvilken reserve som skal bli aktiv, og om det eksterne stedet vil godta en returvei gjennom den.

Ikke installer en permanent statisk overstyring før du forstår hvorfor tilbaketrekkingen skjedde. Den snarveien kan feste trafikken til en feilet vei eller stille omgå en bevisst rutingspolicy, og den begraver den opprinnelige årsaken under en ny konfigurasjon. Test applikasjonen på nytt når ruten er gjenopprettet, og bekreft at det valgte prefikset har en fungerende datavei og ikke bare en oppføring i en tabell.