Korleis skilje ein rutingsløkke frå ei flappande rute på VPN-nettstader

To nettstader, ein tunnel og eit fjernprefiks som svarar ei stund og så tier. Refleksen er å kalle det ei rutingsløkke, og nokre gonger er det nettopp det. Men ei løkke og ei flappande rute gjev same klage og krev motsette reparasjonar: den eine er eit vidaresendingsval som aldri blir avslutta, den andre er eit prefiks som stadig forlèt tabellen. Tre observasjonar skil dei, og du kan samle alle tre frå kommandolinja til gatewayen før du rører eit filter eller startar ein tunnel på nytt.

Ei løkke blir avgjord hopp for hopp. Nettstad A vel B som neste hopp for destinasjonen, B vel A for same destinasjon, og pakken går ut på TTL etter to rundturar. Ein flapp blir i staden avgjord av rutingsprotokollen: prefikset blir trekt tilbake, installert på nytt eller bytt ut med eit alternativt neste hopp, så nokre pakkar har ingen rute i det heile, medan andre følgjer ei heilt god.

Dei tre kontrollane som avgjer spørsmålet

Du treng ingen pakkefangst for den første avgjerda. Du treng tilstanden til prefikset i begge endar, det neste hoppet kvar side vel, og eit hopptal som anten blir gjenteke eller ikkje. Blir prefikset ståande installert med same neste hopp medan trafikken feilar, bur løkka i vidaresendingsvegen. Forsvinn prefikset og kjem tilbake, ligg feilen over vidaresendinga, og reparasjonen høyrer til rutingsprotokollen, ikkje til ei statisk rute.

Éi åtvaring før du byrjar. Les du dette over tunnelen som løkkar, døyr økta di i det augneblunken du endrar ruta. Opne ein konsoll eller ein administrasjonsveg som ikkje er avhengig av prefikset du er i ferd med å reparere.

Kontroll éin: er prefikset stabilt eller kokar det

Spør kjernen om kva han installerte, ikkje kva konfigurasjonsfila lovar. På ein Linux-gateway køyrer ip route get 10.20.30.40 det same oppslaget som vidaresendingsvegen køyrer, inkludert policy-tabellar, medan ip route show 10.20.30.0/24 viser sjølve oppføringa. ip monitor route strøymer kvar endring i det augneblunken ho skjer, som er den raskaste måten å sjå eit prefiks kome og gå.

På ein ruter med FRR eller BIRD er det ikkje vidaresendingstabellen som er interessant. show ip bgp 10.20.30.0/24 returnerer den valde vegen og oppetida hans; ei oppetid som blir nullstilt kvart par minutt er ein flapp du kan namngje, ikkje ei løkke. show ip bgp summary viser tilstanden til naboen og prefikstal, så ein peer som stadig fell, tek skulda frå vidaresendingsvegen.

Skriv ned svaret før du endrar noko. Stabilt i ti minutt medan ping feila, og forsvunne fire gonger på ti minutt, fører til ulike neste steg. Det andre gjer kvar teori om statisk rute irrelevant.

Kontroll to: peikar det neste hoppet tilbake i ankomsttunnelen

Ei løkke krev at to gatewayar er samde. På nettstaden som tek imot pakken, sjå på ruta pakken vil bruke for å gå ut: ip route get 10.20.30.40 from 10.10.5.20 med den rette kjeldeadressa, fordi ei policyregel kan svare annleis enn hovudtabellen. Gjenta så oppslaget på nettstaden som sende han. Vel kvar side den andre som neste hopp for same prefiks, er løkka prova, og ingen fangst vil leggje noko til.

Årsaka er nesten alltid ei annonsering som ikkje skulle ha kryssa tunnelen. Ei standardrute som blir redistribuert inn i tunnelen, eit aggregat som dekkjer fjernnettstaden sitt eige subnett, eller ei statisk rute mot peeren for sikkerheits skuld skapar alle det same gjensidige neste hoppet. Tunnelen kan vere fullt etablert og likevel bera trafikk i ein sirkel; merknadene om vidaresending frå strongSwan skildrar rutingsida av det kravet.

WireGuard fortener sin eigen merknad, fordi det finst inga annonsering å skylde på. wg show listar AllowedIPs for kvar peer, og kjernen godtek berre ein destinasjon for ein peer om han fell innanfor det området. Ei løkke der er eit overlappande AllowedIPs-område eller ei statisk rute som peikar tilbake over grensesnittet, så reparasjonen bur på dei to stadene og ingen andre.

Kontroll tre: les hopptalet, ikkje stjernene

traceroute -n -I 10.20.30.40 og mtr -n -r -c 20 10.20.30.40 viser begge vegen, og ICMP-modus overlever ofte filtrering som et UDP-provar. Ei løkke ser ut som ein kort gjenteken sekvens av dei same to gatewayadressene med TTL som stig kvar gong. Eit fall ser ut som stjerner etter den siste gatewayen som svara, og eitt stille hopp er ikkje prov for noko.

Når vegen er tvitydig, les TTL på leidningen. tcpdump -ni any -vv icmp på begge gatewayane viser TTL for kvar pakke og kjeldeadressa for kvart svar om overskriden tid. Når ein pakke fram til fjernnettstaden med lågare TTL enn talet på hopp vegen kan innehalde, legg noko til hopp som traceroute ikkje viser deg, og det skjer når brannmuren på den eine nettstaden svarar på provar på vegner av den andre.

Reparer eigaren av prefikset, og verifiser så begge retningar

Avgjer kva nettstad som skapar destinasjonen og kva transitvegar som er tillatne, og endre så annonseringa eller den statiske ruta hos den eigaren. Å rette den mottakande nettstaden er freistande og vanlegvis feil: det gøymer løkka for eitt prefiks og lèt den dårlege annonseringa stå for det neste. Rutetaggar, distribusjonslister og split-horizon-reglar finst for å stoppe dette ved kjelda, og dei er billegare enn eit filter som passar på eitt einskilt prefiks.

Etter endringa, verifiser fram og tilbake kvar for seg, fordi ei løkke kan bli erstatta av eit svart hol utan noka synleg betring av symptomet. Køyr ip route get frå begge endar, send trafikk frå ein vert som ikkje er gatewayen, og la ip monitor route gå i minst ein halde-timer, så ein flapp ikkje blir forveksla med ein reparasjon.

Før du endrar noko, stadfest desse fem punkta: prefikset er stabilt eller kokar, det neste hoppet i begge endar peikar på ein tunnel, hopptalet blir gjenteke eller ikkje, éin nettstad eig prefikset, og du har ein administrasjonsveg som overlever endringa. Er eitt av dei fem ukjent, er dei fire andre gjettingar.