Kaip atskirti maršrutizavimo kilpą nuo maršruto plazdėjimo VPN svetainėse
Maršrutizavimo kilpa ir plazdantis maršrutas sukelia tą patį protarpinį praradimą. Trys patikros šliuzuose atskiria juos prieš ką nors keičiant.
Dvi svetainės, vienas tunelis ir tolimas prefiksas, kuris kurį laiką atsako ir tada nutyla. Refleksas yra pavadinti tai maršrutizavimo kilpa, ir kartais tai būtent taip ir yra. Tačiau kilpa ir plazdantis maršrutas kelia tą patį nusiskundimą ir reikalauja priešingų taisymų: vienas yra persiuntimo sprendimas, kuris niekada nesibaigia, kitas yra prefiksas, kuris nuolat palieka lentelę. Trys stebėjimai juos atskiria, ir visus tris galite surinkti iš šliuzo komandinės eilutės prieš liesdami filtrą ar iš naujo paleisdami tunelį.
Kilpa sprendžiama šuolis po šuolio. Svetainė A pasirenka B kaip kitą šuolį tikslui, B pasirenka A tam pačiam tikslui, ir paketas baigiasi TTL po dviejų kelionių pirmyn ir atgal. Plazdėjimą vietoj to sprendžia maršrutizavimo protokolas: prefiksas atšaukiamas, įdiegiamas iš naujo arba pakeičiamas alternatyviu kitu šuoliu, todėl kai kurie paketai neturi jokio maršruto, o kiti seka visiškai gerą.
Trys patikros, kurios išsprendžia klausimą
Pirmam sprendimui nereikia paketų įrašymo. Jums reikia prefikso būsenos abiejuose galuose, kiekvienos pusės pasirenkamo kito šuolio ir šuolių skaičiaus, kuris arba kartojasi, arba ne. Jei prefiksas lieka įdiegtas su tuo pačiu kitu šuoliu, kol srautas nepavyksta, kilpa gyvena persiuntimo kelyje. Jei prefiksas dingsta ir grįžta, gedimas yra aukščiau persiuntimo, ir taisymas priklauso maršrutizavimo protokolui, o ne statiniam maršrutui.
| 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 |
Vienas įspėjimas prieš pradedant. Jei skaitote tai per tunelį, kuris kilpina, jūsų sesija miršta tą akimirką, kai pakeisite maršrutą. Atidarykite konsolę ar valdymo kelią, kuris nepriklauso nuo prefikso, kurį ketinate taisyti.
Pirma patikra: ar prefiksas stabilus, ar kruta
Klauskite branduolio, ką jis įdiegė, o ne ką žada konfigūracijos failas. Linux šliuze ip route get 10.20.30.40 atlieka tą pačią paiešką kaip persiuntimo kelias, įskaitant politikos lenteles, o ip route show 10.20.30.0/24 rodo patį įrašą. ip monitor route perduoda kiekvieną pakeitimą jo atsiradimo momentu, ir tai yra greičiausias būdas stebėti prefiksą ateinant ir išeinant.
Maršrutizatoriuje su FRR ar BIRD įdomi ne persiuntimo lentelė. show ip bgp 10.20.30.0/24 grąžina pasirinktą kelią ir jo veikimo laiką; veikimo laikas, kuris atsinaujina kas kelias minutes, yra plazdėjimas, kurį galite pavadinti, o ne kilpa. show ip bgp summary rodo kaimynų būseną ir prefiksų skaičių, todėl nuolat krintantis partneris nuima kaltę nuo persiuntimo kelio.
Užrašykite atsakymą prieš ką nors keisdami. Stabilumas dešimt minučių, kol pingai nepavykdavo, ir dingimas keturis kartus per dešimt minučių veda prie skirtingų tolesnių žingsnių. Antrasis atvejis daro bet kokią statinio maršruto teoriją neaktualią.
Antra patikra: ar kitas šuolis rodo atgal į atvykimo tunelį
Kilpai reikia, kad du šliuzai sutartų. Svetainėje, kuri gauna paketą, pažiūrėkite į maršrutą, kurį paketas naudos išeidamas: ip route get 10.20.30.40 from 10.10.5.20 su tikruoju šaltinio adresu, nes politikos taisyklė gali atsakyti kitaip nei pagrindinė lentelė. Tada pakartokite paiešką svetainėje, kuri jį išsiuntė. Jei kiekviena pusė pasirenka kitą kaip kitą šuolį tam pačiam prefiksui, kilpa įrodyta ir joks įrašymas nieko nepridės.
Priežastis beveik visada yra skelbimas, kuris neturėjo kirsti tunelio. Į tunelį perskirstytas numatytasis maršrutas, agregatas, apimantis pačios tolimos svetainės potinklį, arba statinis maršrutas į partnerį dėl saugumo — visi sukuria tą patį abipusį kitą šuolį. Tunelis gali būti visiškai sukurtas ir vis tiek nešti srautą ratu; strongSwan persiuntimo pastabos aprašo maršrutizavimo pusę to reikalavimo.
WireGuard nusipelno atskiros pastabos, nes nėra skelbimo, kurį būtų galima kaltinti. wg show išvardija kiekvieno partnerio AllowedIPs, ir branduolys priima paskirties adresą partneriui tik jei jis patenka į tą intervalą. Kilpa ten yra persidengiantis AllowedIPs intervalas arba statinis maršrutas, rodantis atgal per sąsają, todėl taisymas gyvena tik tose dviejose vietose.
Trečia patikra: skaitykite šuolių skaičių, o ne žvaigždutes
traceroute -n -I 10.20.30.40 ir mtr -n -r -c 20 10.20.30.40 abu rodo kelią, o ICMP režimas dažnai išgyvena filtravimą, kuris suvalgo UDP zondus. Kilpa atrodo kaip trumpa pasikartojanti tų pačių dviejų šliuzų adresų seka, o TTL kaskart kyla. Kritimas atrodo kaip žvaigždutės po paskutinio atsakiusio šliuzo, ir vienas tylus šuolis nėra nieko įrodymas.
Kai kelias dviprasmiškas, skaitykite TTL laide. tcpdump -ni any -vv icmp abiejuose šliuzuose rodo kiekvieno paketo TTL ir kiekvieno laiko viršijimo atsakymo šaltinio adresą. Jei paketas pasiekia tolimą svetainę su mažesniu TTL nei šuolių, kuriuos kelias gali turėti, skaičius, kažkas prideda šuolių, kurių traceroute jums nerodo, ir tai atsitinka, kai vienos svetainės užkarda atsako į zondus kitos vardu.
Sutaisykite prefikso savininką, tada patikrinkite abi kryptis
Nuspręskite, kuri svetainė sukuria paskirties adresą ir kokie tranzito keliai leidžiami, tada pakeiskite skelbimą arba statinį maršrutą tame savininke. Priimančios svetainės taisymas vilioja ir dažniausiai yra neteisingas: jis paslepia kilpą vienam prefiksui ir palieka blogą skelbimą kitam. Maršruto žymos, platinimo sąrašai ir split-horizon taisyklės egzistuoja tam, kad tai sustabdytų šaltinyje, ir jos yra pigesnės už filtrą, atitinkantį vieną prefiksą.
Po pakeitimo patikrinkite pirmyn ir atgal atskirai, nes kilpa gali būti pakeista juoda skyle be jokio matomo simptomo pagerėjimo. Paleiskite ip route get iš abiejų galų, siųskite srautą iš prieglobos, kuri nėra šliuzas, ir palikite ip monitor route veikti bent vieną laikymo laikmatį, kad plazdėjimas nebūtų palaikytas taisymu.
Prieš ką nors keisdami patvirtinkite šiuos penkis punktus: prefiksas stabilus ar kruta, kitas šuolis abiejuose galuose rodo į tunelį, šuolių skaičius kartojasi ar ne, viena svetainė valdo prefiksą, ir turite valdymo kelią, kuris išgyvena pakeitimą. Jei bent vienas iš penkių nežinomas, kiti keturi yra spėlionės.