Si të dallojmë një lak rrugëtimi nga një rrugë që dridhet në sajtet VPN
Një lak rrugëtimi dhe një rrugë e paqëndrueshme shkaktojnë të njëjtin humbje me ndërprerje. Tre kontrolle në porta i dallojnë ato para se të ndryshoni çdo gjë.
Dy sajte, një tunel dhe një prefiks i largët që përgjigjet për një kohë dhe pastaj hesht. Refleksi është ta quajmë lak rrugëtimi, dhe ndonjëherë është pikërisht ajo. Por një lak dhe një rrugë që dridhet prodhojnë të njëjtin ankese dhe kërkojnë riparime të kundërta: njëri është një vendim përcjelljeje që nuk përfundon kurrë, tjetri është një prefiks që vazhdimisht largohet nga tabela. Tre vëzhgime i ndajnë ato, dhe të treja mund t'i mblidhni nga rreshti i komandave i portës para se të prekni një filtër ose të rinisni një tunel.
Një lak vendoset hap pas hapi. Sajti A zgjedh B si hapin tjetër për destinacionin, B zgjedh A për të njëjtin destinacion, dhe paketa skadon në TTL pas dy udhëtimeve vajtje-ardhje. Dridhja vendoset nga ana tjetër nga protokolli i rrugëtimit: prefiksi tërhiqet, riinstalohet ose zëvendësohet nga një hap tjetër alternativ, kështu që disa paketa nuk kanë fare rrugë ndërsa të tjerat ndjekin një të mirë plotësisht.
Tre kontrollet që zgjidhin pyetjen
Nuk ju nevojitet kapje paketash për vendimin e parë. Ju nevojitet gjendja e prefiksit në të dy skajet, hapi tjetër që zgjedh secila anë, dhe një numërim hapash që ose përsëritet ose jo. Nëse prefiksi mbetet i instaluar me të njëjtin hap tjetër ndërsa trafiku dështon, laku jeton në rrugën e përcjelljes. Nëse prefiksi zhduket dhe kthehet, defekti është mbi përcjelljen dhe riparimi i përket protokollit të rrugëtimit, jo një rruge statike.
| 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 |
Një paralajmërim para se të filloni. Nëse po e lexoni këtë përmes tunelit që bën lak, sesioni juaj vdes në momentin që ndryshoni rrugën. Hapni një konsolë ose një rrugë administrimi që nuk varet nga prefiksi që jeni gati të riparoni.
Kontrolli i parë: a është prefiksi i qëndrueshëm apo zie
Pyetni kernelin se çfarë instaloi, jo çfarë premton skedari i konfigurimit. Në një portë Linux, ip route get 10.20.30.40 ekzekuton të njëjtin kërkim që ekzekuton rruga e përcjelljes, përfshirë tabelat e politikave, ndërsa ip route show 10.20.30.0/24 shfaq vetë hyrjen. ip monitor route transmeton çdo ndryshim në momentin që ndodh, dhe ky është mënyra më e shpejtë për të parë një prefiks që vjen dhe shkon.
Në një ruter me FRR ose BIRD, tabela e përcjelljes nuk është ajo interesante. show ip bgp 10.20.30.0/24 kthen rrugën e zgjedhur dhe kohën e saj të punës; një kohë pune që riniset çdo pak minuta është një dridhje që mund ta emërtoni, jo një lak. show ip bgp summary tregon gjendjen e fqinjëve dhe numrin e prefiksave, kështu që një partner që bie vazhdimisht e heq fajin nga rruga e përcjelljes.
Shkruani përgjigjen para se të ndryshoni çdo gjë. Të qenit i qëndrueshëm dhjetë minuta ndërsa ping-ët dështonin, dhe zhdukja katër herë në dhjetë minuta çojnë në hapa të ndryshëm të mëtejshëm. I dyti e bën të parëndësishme çdo teori për rrugën statike.
Kontrolli i dytë: a tregon hapi tjetër përsëri në tunelin e mbërritjes
Një lak kërkon që dy porta të bien dakord. Në sajtin që e merr paketën, shikoni rrugën që paketa do të përdorë për të dalë: ip route get 10.20.30.40 from 10.10.5.20 me adresën e vërtetë të burimit, sepse një rregull politike mund të përgjigjet ndryshe nga tabela kryesore. Pastaj përsëritni kërkimin në sajtin që e dërgoi. Nëse secila anë zgjedh tjetrën si hap tjetër për të njëjtin prefiks, laku është provuar dhe asnjë kapje nuk do të shtojë gjë.
Shkaku është pothuajse gjithmonë një njoftim që nuk duhej të kishte kaluar tunelin. Një rrugë e paracaktuar e rishpërndarë në tunel, një agregat që mbulon vetë nënrrjetin e sajtit të largët, ose një rrugë statike drejt partnerit për çdo rast krijojnë të gjitha të njëjtin hap tjetër të ndërsjellë. Tuneli mund të jetë plotësisht i vendosur dhe gjithsesi të mbajë trafik në rreth; shënimet për përcjelljen të strongSwan përshkruajnë anën e rrugëtimit të atij kushti.
WireGuard meriton një shënim të vetin, sepse nuk ka njoftim për të fajësuar. wg show liston AllowedIPs për secilin partner, dhe kerneli pranon një destinacion për një partner vetëm nëse bie brenda atij diapazoni. Një lak atje është një diapazon AllowedIPs që mbivendoset ose një rrugë statike që tregon prapa përmes ndërfaqes, kështu që riparimi jeton vetëm në ato dy vende.
Kontrolli i tretë: lexoni numrin e hapave, jo yjet
traceroute -n -I 10.20.30.40 dhe mtr -n -r -c 20 10.20.30.40 të dyja tregojnë rrugën, dhe modaliteti ICMP shpesh i mbijeton një filtrimi që ha sondat UDP. Një lak duket si një sekuencë e shkurtër e përsëritur e të njëjtave dy adresa portash me TTL që rritet çdo herë. Një rënie duket si yje pas portës së fundit që u përgjigj, dhe një hap i vetëm i qetë nuk është provë për asgjë.
Kur rruga është e paqartë, lexoni TTL në tel. tcpdump -ni any -vv icmp në të dyja portat tregon TTL e secilës paketë dhe adresën e burimit të secilës përgjigje për kohë të tejkaluar. Nëse një paketë arrin në sajtin e largët me një TTL më të vogël se numri i hapave që rruga mund të përmbajë, diçka po shton hapa që traceroute nuk ju tregon, dhe kjo ndodh kur muri i zjarrit i një sajti përgjigjet për sondat në emër të tjetrit.
Riparoni pronarin e prefiksit, pastaj verifikoni të dy drejtimet
Vendosni cili sajt e krijon destinacionin dhe cilat rrugë tranziti lejohen, pastaj ndryshoni njoftimin ose rrugën statike te ai pronar. Të korrigjosh sajtin pritës është joshëse dhe zakonisht e gabuar: fsheh lakin për një prefiks dhe e lë njoftimin e keq në vend për tjetrin. Etiketat e rrugës, listat e shpërndarjes dhe rregullat split-horizon ekzistojnë për ta ndalur këtë në burim, dhe janë më të lira se një filtër që përputhet me një prefiks të vetëm.
Pas ndryshimit, verifikoni veçmas shkuarjen dhe kthimin, sepse një lak mund të zëvendësohet nga një vrimë e zezë pa asnjë përmirësim të dukshëm të simptomës. Ekzekutoni ip route get nga të dy skajet, dërgoni trafik nga një host që nuk është porta, dhe lini ip monitor route të punojë të paktën një kohëmatës mbajtjeje që dridhja të mos merret për riparim.
Përpara se të ndryshoni çdo gjë, konfirmoni këto pesë pika: prefiksi është i qëndrueshëm ose zie, hapi tjetër në të dy skajet tregon drejt një tuneli, numri i hapave përsëritet ose jo, një sajt e zotëron prefiksin, dhe ju keni një rrugë administrimi që i mbijeton ndryshimit. Nëse ndonjëra nga të pesë është e panjohur, katër të tjerat janë hamendje.