Tunelul stă, ruta a dispărut: separarea a două defecțiuni VPN

Un host devine inaccesibil în timp ce interfața tunelului încă raportează că este stabilită, iar cele două observații nu se contrazic. Ceva a eliminat calea pe care o folosea traficul: un vecin și-a retras prefixul, o rută statică urmărită a fost eliminată, sau o altă rută a devenit preferată. Asocierea de securitate poate rămâne perfect sănătoasă în toate cele trei cazuri. Separarea evenimentelor înseamnă să întrebăm ce strat s-a schimbat primul, nu dacă VPN-ul a eșuat.

Trei etape care par un singur eveniment

O decizie de rutare are trei etape. Prefixul este primit, selectat ca cel mai bun și instalat în tabela de redirecționare. Fiecare etapă poate eșua singură, iar defecțiunea arată identic din partea aplicației. Un prefix învățat, dar care a pierdut selecția, nu poate fi distins de unul care nu a ajuns niciodată când singura dovadă pe care o priviți este tabela de redirecționare.

De aceea prima întrebare este care etapă s-a rupt, nu care protocol este vinovat. Răspunsul decide cui aparține incidentul și ce instrument folosește următoarea verificare.

Citiți mai întâi ruta instalată

Întrebați kernelul unde merge de fapt traficul către destinația care eșuează. ip route get afișează următorul salt, interfața și adresa sursă pe care kernelul ar folosi-o, și răspunde pentru o singură destinație, nu pentru întreaga tabelă. Dacă răspunsul numește tunelul, tabela de redirecționare încă crede că calea există și problema se află deasupra ei.

ip route get 10.20.5.10
ip route show 10.20.0.0/16

Un răspuns «unreachable» înseamnă că nu există nicio rută instalată, ceea ce indică o retragere sau o instalare lipsă. Un răspuns care numește o interfață fizică înseamnă că traficul a părăsit tunelul fără ca cineva să fi decis asta, iar următoarea verificare este preferința care a câștigat. Un răspuns care numește tunelul în timp ce pachetele continuă să dispară indică mai departe pe cale, la filtrare sau la partea îndepărtată.

Apoi priviți viziunea protocolului însuși

Un demon de rutare ține mai mult de o tabelă, iar comparația interesantă este între ele. Pentru BGP, starea sesiunii vecine, anunțul primit și ruta instalată sunt trei dovezi separate. Un prefix poate sta în tabela primită și nu ajunge niciodată la kernel pentru că o rută cu distanță administrativă mai mică câștigă. Verificați toate trei înainte de a concluziona că cealaltă parte a încetat să anunțe.

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

Rezumatul spune dacă sesiunea este stabilită, vizualizarea pe prefix spune dacă prefixul a fost acceptat, iar căutarea în kernel spune dacă a fost instalat. Citirea lor în această ordine împiedică o clătinare de sesiune să fie confundată cu o retragere, iar o retragere cu o respingere pe bază de politică.

Când ceasurile nu sunt de acord

Puneți jurnalul tunelului, jurnalul de rutare și prima defecțiune a aplicației pe o singură linie temporală folosind fusurile orare reale. Dacă pierderea vecinului vine prima, tunelul a tras ruta în jos odată cu el. Dacă retragerea vine prima, rutarea s-a schimbat, iar tunelul a reacționat după aceea. Acestea sunt incidente diferite cu proprietari diferiți, iar ordinea este întreaga descoperire.

Un minut de abatere a ceasului este suficient pentru a inversa concluzia, așa că confirmați fusul orar și decalajul înainte de a avea încredere în succesiune. Dispozitivele care jurnalizează în ora locală fără decalaj sunt sursa obișnuită a unei linii temporale încrezătoare, dar greșite.

Recuperare fără buclă

După o retragere, două căi pot fi eligibile: cea pe care o selectează protocolul și cea pe care o fixați manual. Doar prima este o decizie pe care rețeaua continuă să o ia pentru dumneavoastră, de aceea o rută manuală este o soluție provizorie, nu un plan de recuperare. Un anunț alternativ nu păstrează nici starea firewall-ului sau NAT pentru o sesiune deja stabilită, așa că fluxurile noi pot funcționa în timp ce cel original rămâne rupt. Confirmați ce backup ar trebui să devină activ și dacă site-ul îndepărtat va accepta o cale de întoarcere prin el.

Nu instalați o suprascriere statică permanentă înainte de a înțelege de ce a avut loc retragerea. Acea scurtătură poate fixa traficul pe o cale eșuată sau poate ocoli în tăcere o politică de rutare deliberată, și îngroapă cauza originală sub o configurație nouă. Retestați aplicația după ce ruta este restaurată și confirmați că prefixul ales are o cale de date funcțională, nu doar o intrare într-o tabelă.