Sådan skelner du en routingløkke fra rute-flapping på VPN-sites

To sites, én tunnel og et fjernpræfiks, der svarer et stykke tid og så tier. Refleksen er at kalde det en routingløkke, og undertiden er det præcis, hvad det er. Men en løkke og en flappende rute giver samme klage og kræver modsatte reparationer: den ene er en videresendelsesbeslutning, der aldrig terminerer, den anden er et præfiks, der bliver ved med at forlade tabellen. Tre observationer skiller dem, og du kan indsamle alle tre fra gatewayens kommandolinje, før du rører et filter eller genstarter en tunnel.

En løkke afgøres hop for hop. Site A vælger B som næste hop for destinationen, B vælger A for samme destination, og pakken udløber på TTL efter to rundture. En flap afgøres derimod af routingprotokollen: præfikset trækkes tilbage, geninstalleres eller erstattes af et alternativt næste hop, så nogle pakker slet ikke har nogen rute, mens andre følger en helt fin.

De tre kontroller, der afgør spørgsmålet

Du behøver ingen pakkefangst for at tage den første beslutning. Du har brug for præfiksets tilstand i begge ender, det næste hop hver side vælger, og et hopantal, der enten gentages eller ikke. Hvis præfikset bliver installeret med samme næste hop, mens trafikken fejler, bor løkken i videresendelsesvejen. Hvis præfikset forsvinder og vender tilbage, ligger fejlen over videresendelsen, og reparationen hører til routingprotokollen, ikke til en statisk rute.

Én advarsel, før du begynder. Hvis du læser dette over den tunnel, der løkker, dør din session i det øjeblik, du ændrer ruten. Åbn en konsol eller en administrationsvej, der ikke afhænger af det præfiks, du er ved at reparere.

Kontrol et: er præfikset stabilt eller koger det

Spørg kernen, hvad den installerede, ikke hvad konfigurationsfilen lover. På en Linux-gateway kører ip route get 10.20.30.40 det samme opslag, som videresendelsesvejen kører, inklusive policy-tabeller, mens ip route show 10.20.30.0/24 viser selve posten. ip monitor route streamer hver ændring, når den sker, hvilket er den hurtigste måde at se et præfiks komme og gå.

På en router med FRR eller BIRD er det ikke videresendelsestabellen, der er interessant. show ip bgp 10.20.30.0/24 returnerer den valgte vej og dens oppetid; en oppetid, der nulstilles hver få minutter, er en flap, du kan navngive, ikke en løkke. show ip bgp summary viser naboernes tilstand og præfikstal, så en peer, der bliver ved med at falde, tager skylden fra videresendelsesvejen.

Skriv svaret ned, før du ændrer noget. Stabilt i ti minutter, mens ping fejlede, og forsvundet fire gange på ti minutter fører til forskellige næste skridt. Det andet gør enhver teori om statisk rute irrelevant.

Kontrol to: peger det næste hop tilbage i ankomsttunnelen

En løkke kræver, at to gateways er enige. På det site, der modtager pakken, se på den rute, pakken vil bruge til at forlade: ip route get 10.20.30.40 from 10.10.5.20 med den rigtige kildeadresse, fordi en policyregel kan svare anderledes end hovedtabellen. Gentag derefter opslaget på det site, der sendte den. Hvis hver side vælger den anden som næste hop for samme præfiks, er løkken bevist, og ingen fangst vil tilføje noget.

Årsagen er næsten altid en annoncering, der ikke skulle have krydset tunnelen. En standardrute, der redistribueres ind i tunnelen, et aggregat, der dækker fjernsitets eget subnet, eller en statisk rute mod peeren for en sikkerheds skyld skaber alle det samme gensidige næste hop. Tunnelen kan være fuldt etableret og alligevel bære trafik i en cirkel; strongSwans noter om videresendelse beskriver routingsiden af det krav.

WireGuard fortjener sin egen note, fordi der ikke er nogen annoncering at bebrejde. wg show viser AllowedIPs for hver peer, og kernen accepterer kun en destination for en peer, hvis den falder inden for det interval. En løkke der er et overlappende AllowedIPs-interval eller en statisk rute, der peger tilbage over interfacet, så reparationen bor på de to steder og ingen andre.

Kontrol tre: læs hopantallet, ikke stjernerne

traceroute -n -I 10.20.30.40 og mtr -n -r -c 20 10.20.30.40 viser begge vejen, og ICMP-tilstand overlever ofte den filtrering, der spiser UDP-prober. En løkke ser ud som en kort gentagen sekvens af de samme to gatewayadresser med TTL, der stiger hver gang. Et tab ser ud som stjerner efter den sidste gateway, der svarede, og et enkelt tavst hop er ikke bevis på noget.

Når vejen er tvetydig, læs TTL på wiren. tcpdump -ni any -vv icmp på begge gateways viser TTL for hver pakke og kildeadressen for hvert svar om overskredet tid. Hvis en pakke når fjernsitet med en TTL, der er lavere end det antal hop, vejen kan indeholde, tilføjer noget hop, som traceroute ikke viser dig, og det sker, når det ene sites firewall svarer på prober på vegne af det andet.

Reparer præfiksets ejer, og verificer derefter begge retninger

Beslut, hvilket site der oprinder destinationen, og hvilke transitveje der er tilladte, og ændr derefter annonceringen eller den statiske rute hos den ejer. At rette det modtagende site er fristende og som regel forkert: det skjuler løkken for ét præfiks og efterlader den dårlige annoncering til det næste. Rutetags, distribueringslister og split-horizon-regler findes for at stoppe det ved kilden, og de er billigere end et filter, der matcher ét enkelt præfiks.

Efter ændringen skal du verificere frem og tilbage hver for sig, fordi en løkke kan erstattes af et sort hul uden nogen synlig forbedring af symptomet. Kør ip route get fra begge ender, send trafik fra en vært, der ikke er gatewayen, og lad ip monitor route køre i mindst én hold-timer, så en flap ikke forveksles med en reparation.

Før du ændrer noget, bekræft disse fem punkter: præfikset er stabilt eller koger, det næste hop i begge ender peger på en tunnel, hopantallet gentages eller ej, ét site ejer præfikset, og du har en administrationsvej, der overlever ændringen. Hvis bare ét af de fem er ukendt, er de fire andre gæt.