Cum distingi o buclă de rutare de o rută care clipește pe site-uri VPN
O buclă de rutare și o rută instabilă provoacă aceeași pierdere intermitentă. Trei verificări la gateway-uri le disting înainte să schimbi ceva.
Două site-uri, un tunel și un prefix îndepărtat care răspunde o vreme și apoi tace. Reflexul este să numim asta buclă de rutare, și uneori exact asta este. Dar o buclă și o rută instabilă produc aceeași plângere și cer reparații opuse: una este o decizie de forwarding care nu se termină niciodată, cealaltă este un prefix care tot părăsește tabela. Trei observații le separă, și le poți colecta pe toate trei din linia de comandă a gateway-ului înainte să atingi un filtru sau să repornești un tunel.
O buclă se decide hop cu hop. Site-ul A alege B ca următor hop pentru destinație, B alege A pentru aceeași destinație, iar pachetul expiră pe TTL după două dus-întorsuri. Clipirea este decisă în schimb de protocolul de rutare: prefixul este retras, reinstalat sau înlocuit cu un următor hop alternativ, așa că unele pachete nu au niciun fel de rută, în timp ce altele urmează una perfect bună.
Cele trei verificări care lămuresc întrebarea
Nu ai nevoie de captură de pachete pentru prima decizie. Ai nevoie de starea prefixului la ambele capete, de următorul hop pe care îl alege fiecare parte și de un număr de hopuri care fie se repetă, fie nu. Dacă prefixul rămâne instalat cu același următor hop în timp ce traficul eșuează, bucla trăiește în calea de forwarding. Dacă prefixul dispare și revine, defectul este deasupra forwarding-ului și reparația aparține protocolului de rutare, nu unei rute statice.
| Observation | Routing loop | Route flapping |
|---|---|---|
| Prefix in the table | Installed, same next hop throughout | Withdrawn and reinstalled, or next hop alternates |
| Hop count | Reaches zero at the same two gateways | Expires only while the prefix is missing |
| Failure shape | Consistent loss for that prefix from every source | Bursts, often after a link or peer event |
| Where the fix belongs | The site that owns the prefix, plus filters on the transit path | Advertisement, hold timers, or the flapping link |
Un avertisment înainte de început. Dacă citești asta prin tunelul care face buclă, sesiunea ta moare în momentul în care schimbi ruta. Deschide o consolă sau o cale de administrare care nu depinde de prefixul pe care urmează să îl repari.
Verificarea unu: prefixul este stabil sau clocotește
Întreabă kernelul ce a instalat, nu ce promite fișierul de configurare. Pe un gateway Linux, ip route get 10.20.30.40 execută aceeași căutare pe care o execută calea de forwarding, inclusiv tabelele de politici, în timp ce ip route show 10.20.30.0/24 arată intrarea în sine. ip monitor route transmite fiecare schimbare în momentul în care apare, ceea ce este cel mai rapid mod de a vedea un prefix venind și plecând.
Pe un router cu FRR sau BIRD, tabela de forwarding nu este cea interesantă. show ip bgp 10.20.30.0/24 returnează calea selectată și timpul ei de funcționare; un timp de funcționare care se resetează la fiecare câteva minute este o clipire pe care o poți numi, nu o buclă. show ip bgp summary arată starea vecinilor și numărul de prefixe, așa că un peer care cade continuu ia vina de pe calea de forwarding.
Notează răspunsul înainte să schimbi ceva. Stabil zece minute cât timp pingurile eșuau, și dispărut de patru ori în zece minute, duc la pași următori diferiți. Al doilea caz face irelevantă orice teorie despre ruta statică.
Verificarea doi: următorul hop arată înapoi în tunelul de sosire
O buclă cere ca două gateway-uri să fie de acord. Pe site-ul care primește pachetul, uită-te la ruta pe care pachetul o va folosi ca să iasă: ip route get 10.20.30.40 from 10.10.5.20 cu adresa reală de sursă, pentru că o regulă de politică poate răspunde altfel decât tabela principală. Apoi repetă căutarea pe site-ul care l-a trimis. Dacă fiecare parte o alege pe cealaltă ca următor hop pentru același prefix, bucla este dovedită și nicio captură nu va adăuga nimic.
Cauza este aproape întotdeauna un anunț care nu ar fi trebuit să traverseze tunelul. O rută implicită redistribuită în tunel, un agregat care acoperă propria subrețea a site-ului îndepărtat sau o rută statică spre peer pentru orice eventualitate creează toate același următor hop reciproc. Tunelul poate fi pe deplin stabilit și totuși să poarte traficul în cerc; notele despre forwarding ale strongSwan descriu partea de rutare a acelei cerințe.
WireGuard merită o notă proprie, pentru că nu există niciun anunț de învinuit. wg show listează AllowedIPs pentru fiecare peer, iar kernelul acceptă o destinație pentru un peer doar dacă se încadrează în acel interval. O buclă acolo este un interval AllowedIPs suprapus sau o rută statică ce arată înapoi prin interfață, așa că reparația trăiește doar în acele două locuri.
Verificarea trei: citește numărul de hopuri, nu stelele
traceroute -n -I 10.20.30.40 și mtr -n -r -c 20 10.20.30.40 arată amândouă calea, iar modul ICMP supraviețuiește adesea unei filtrări care mănâncă sondale UDP. O buclă arată ca o secvență scurtă repetată a acelorași două adrese de gateway, cu TTL crescând de fiecare dată. O cădere arată ca niște stele după ultimul gateway care a răspuns, iar un singur hop tăcut nu este dovada nimic.
Când calea este ambiguă, citește TTL-ul pe fir. tcpdump -ni any -vv icmp pe ambele gateway-uri arată TTL-ul fiecărui pachet și adresa de sursă a fiecărui răspuns de timp depășit. Dacă un pachet ajunge la site-ul îndepărtat cu un TTL mai mic decât numărul de hopuri pe care calea le poate conține, ceva adaugă hopuri pe care traceroute nu ți le arată, și asta se întâmplă când firewall-ul unui site răspunde la sondale în numele altuia.
Repară proprietarul prefixului, apoi verifică ambele direcții
Decide care site originează destinația și ce căi de tranzit sunt permise, apoi schimbă anunțul sau ruta statică la acel proprietar. Corectarea site-ului receptor este tentantă și de obicei greșită: ascunde bucla pentru un prefix și lasă anunțul prost la locul lui pentru următorul. Etichetele de rută, listele de distribuție și regulile split-horizon există ca să oprească asta la sursă, și sunt mai ieftine decât un filtru care se potrivește cu un singur prefix.
După schimbare, verifică separat dusul și întorsul, pentru că o buclă poate fi înlocuită de o gaură neagră fără nicio îmbunătățire vizibilă a simptomului. Rulează ip route get de la ambele capete, trimite trafic de pe un host care nu este gateway-ul și lasă ip monitor route să ruleze cel puțin un timer de menținere, ca o clipire să nu fie confundată cu o reparație.
Înainte să schimbi ceva, confirmă aceste cinci puncte: prefixul este stabil sau clocotește, următorul hop la ambele capete arată spre un tunel, numărul de hopuri se repetă sau nu, un singur site deține prefixul și ai o cale de administrare care supraviețuiește schimbării. Dacă unul dintre cele cinci este necunoscut, celelalte patru sunt presupuneri.