Hvordan skille en rutingsløkke fra rute-flapping på VPN-nettsteder

To nettsteder, én tunnel og et fjernprefiks som svarer en stund og så tier. Refleksen er å kalle det en rutingsløkke, og noen ganger er det nøyaktig det. Men en løkke og en flappende rute gir samme klage og krever motsatte reparasjoner: den ene er en videresendingsbeslutning som aldri avsluttes, den andre er et prefiks som stadig forlater tabellen. Tre observasjoner skiller dem, og du kan samle alle tre fra gatewayens kommandolinje før du rører et filter eller starter en tunnel på nytt.

En løkke avgjøres hopp for hopp. Nettsted A velger B som neste hopp for destinasjonen, B velger A for samme destinasjon, og pakken utløper på TTL etter to rundturer. En flapp avgjøres derimot av rutingsprotokollen: prefikset trekkes tilbake, installeres på nytt eller erstattes av et alternativt neste hopp, så noen pakker ikke har noen rute i det hele tatt mens andre følger en helt fin.

De tre kontrollene som avgjør spørsmålet

Du trenger ingen pakkefangst for å ta den første beslutningen. Du trenger prefiksets tilstand i begge ender, det neste hoppet hver side velger, og et hoppantall som enten gjentas eller ikke. Hvis prefikset blir stående installert med samme neste hopp mens trafikken feiler, bor løkken i videresendingsveien. Hvis prefikset forsvinner og kommer tilbake, ligger feilen over videresendingen, og reparasjonen hører til rutingsprotokollen, ikke til en statisk rute.

Én advarsel før du begynner. Hvis du leser dette over tunnelen som løkker, dør økten din i det øyeblikket du endrer ruten. Åpne en konsoll eller en administrasjonsvei som ikke avhenger av prefikset du er i ferd med å reparere.

Kontroll én: er prefikset stabilt eller koker det

Spør kjernen om hva den installerte, ikke hva konfigurasjonsfilen lover. På en Linux-gateway kjører ip route get 10.20.30.40 det samme oppslaget som videresendingsveien kjører, inkludert policy-tabeller, mens ip route show 10.20.30.0/24 viser selve oppføringen. ip monitor route strømmer hver endring i det øyeblikket den skjer, som er den raskeste måten å se et prefiks komme og gå.

På en ruter med FRR eller BIRD er det ikke videresendingstabellen som er interessant. show ip bgp 10.20.30.0/24 returnerer den valgte veien og dens oppetid; en oppetid som nullstilles hvert par minutter er en flapp du kan navngi, ikke en løkke. show ip bgp summary viser naboens tilstand og prefikstall, så en peer som stadig faller, tar skylden fra videresendingsveien.

Skriv ned svaret før du endrer noe. Stabilt i ti minutter mens ping feilet, og forsvunnet fire ganger på ti minutter, fører til ulike neste steg. Det andre gjør enhver teori om statisk rute irrelevant.

Kontroll to: peker det neste hoppet tilbake i ankomsttunnelen

En løkke krever at to gatewayer er enige. På nettstedet som mottar pakken, se på ruten pakken vil bruke for å gå ut: ip route get 10.20.30.40 from 10.10.5.20 med den riktige kildeadressen, fordi en policyregel kan svare annerledes enn hovedtabellen. Gjenta deretter oppslaget på nettstedet som sendte den. Hvis hver side velger den andre som neste hopp for samme prefiks, er løkken bevist, og ingen fangst vil tilføre noe.

Årsaken er nesten alltid en annonsering som ikke skulle ha krysset tunnelen. En standardrute som redistribueres inn i tunnelen, et aggregat som dekker fjernnettstedets eget subnett, eller en statisk rute mot peeren for sikkerhets skyld skaper alle det samme gjensidige neste hopp. Tunnelen kan være fullt etablert og likevel bære trafikk i en sirkel; strongSwans merknader om videresending beskriver rutingsiden av det kravet.

WireGuard fortjener sin egen merknad, fordi det ikke finnes noen annonsering å skylde på. wg show viser AllowedIPs for hver peer, og kjernen godtar bare en destinasjon for en peer hvis den faller innenfor det området. En løkke der er et overlappende AllowedIPs-område eller en statisk rute som peker tilbake over grensesnittet, så reparasjonen bor på de to stedene og ingen andre.

Kontroll tre: les hoppantallet, ikke stjernene

traceroute -n -I 10.20.30.40 og mtr -n -r -c 20 10.20.30.40 viser begge veien, og ICMP-modus overlever ofte filtrering som spiser UDP-prober. En løkke ser ut som en kort gjentatt sekvens av de samme to gatewayadressene med TTL som stiger hver gang. Et fall ser ut som stjerner etter den siste gatewayen som svarte, og et enkelt stille hopp er ikke bevis for noe.

Når veien er tvetydig, les TTL på ledningen. tcpdump -ni any -vv icmp på begge gatewayene viser TTL for hver pakke og kildeadressen for hvert svar om overskredet tid. Hvis en pakke når fjernnettstedet med lavere TTL enn antallet hopp veien kan inneholde, legger noe til hopp som traceroute ikke viser deg, og det skjer når brannmuren på det ene nettstedet svarer på prober på vegne av det andre.

Reparer prefiksets eier, og verifiser deretter begge retninger

Avgjør hvilket nettsted som oppretter destinasjonen og hvilke transitveier som er tillatt, og endre deretter annonseringen eller den statiske ruten hos den eieren. Å rette det mottakende nettstedet er fristende og vanligvis feil: det skjuler løkken for ett prefiks og lar den dårlige annonseringen stå for det neste. Rutetagger, distribusjonslister og split-horizon-regler finnes for å stoppe dette ved kilden, og de er billigere enn et filter som matcher ett enkelt prefiks.

Etter endringen, verifiser frem og tilbake hver for seg, fordi en løkke kan erstattes av et svart hull uten noen synlig bedring av symptomet. Kjør ip route get fra begge ender, send trafikk fra en vert som ikke er gatewayen, og la ip monitor route kjøre i minst én holde-timer, så en flapp ikke forveksles med en reparasjon.

Før du endrer noe, bekreft disse fem punktene: prefikset er stabilt eller koker, det neste hoppet i begge ender peker på en tunnel, hoppantallet gjentas eller ikke, ett nettsted eier prefikset, og du har en administrasjonsvei som overlever endringen. Hvis ett av de fem er ukjent, er de fire andre gjetninger.