Rekursiv routing: når tunnelen fanger sine egne pakker

Tunnelen kommer op, loggen viser et fuldført håndtryk, og et sekund senere dør den samme session og genopretter forbindelsen i en løkke. Det mønster har en bestemt årsag: ruten til serveren peger nu ind i tunnelen, så de pakker, der bærer tunnelen, sendes gennem tunnelen. Der er ikke ændret noget i godkendelsen, og derfor gør det ingen forskel at indtaste legitimationsoplysningerne igen. Sammenlign den ydre vej før og efter ruteændringen, så bliver rekursionen synlig.

Kontroller den ydre vej først

Der er to pakker i spil, ikke én. Den indre pakke tilhører applikationen og bør være krypteret, mens den ydre pakke er adresseret til serveren og skal nå den ad en vej, der ikke afhænger af tunnelen.

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

Spørg kernen om ruten til serverens adresse, når tunnelen er oppe, og igen efter at standardruten er ændret. Et næste hop, der lander på tunneleenheden, er selve rekursionen, og den er synlig uden nogen pakkefangst. Interfacebinding, mærker eller et netværksnavnerum kan gøre et almindeligt opslag ufuldstændigt, så brug den kontekst, klienten selv bruger. Når svaret ser rigtigt ud, men sessionen stadig kører i løkke, læs routingpolitikkens regler i stedet for kun hovedtabellen.

Hvorfor sessionen overlever et øjeblik

Håndtrykket fuldføres, før den nye rute installeres, så de første sekunder ser sunde ud. Så snart klienten tilføjer standardruten, følger den næste ydre pakke den ind i det interface, som den ydre pakke skal rejse igennem. Serveren ser intet, klienten sender igen, og forsøget løber enten ud eller dræber sessionen og starter forfra.

Den rækkefølge forklarer, hvorfor en tunnel kan virke på en bærbar og fejle på en router, og hvorfor fejlen ofte begynder, når trafikken starter, og ikke ved forbindelsen. Den forklarer også løkken: hver genstart genopretter sessionen, før ruten gør det umuligt.

Find ud af, hvem der ejer undtagelsen for endepunktet

Understøttede klienter sørger selv for deres undtagelse: en værtsrute til serveren gennem den oprindelige gateway eller et mærke, der holder den ydre socket uden for tunnelen. Spørgsmålet er, om noget andet har fjernet eller tilsidesat den.

For rutebaseret IPsec skal du undersøge de policyvælgere, der afgør, hvilke pakker der kommer ind i tunnelen, og bekræfte, at peer-adressen er udelukket fra dem. For WireGuard holder interfacets firewallmærke og dets policyregler transportpakkerne uden for tunnelen, så en manuelt tilføjet standardrute kan ødelægge den ordning. En anden VPN-profil eller et administrationsscript, der omskriver standardruten, er en hyppig synder. Brede omgåelsesregler tilføjet én ad gangen er det sædvanlige resultat, og de gør en routingfejl til en tabel, som ingen kan vedligeholde.

Kontroller igen efter en netværksændring

En værtsrute gennem en Wi-Fi-gateway er korrekt, indtil maskinen flytter til et andet netværk. Så vender det samme symptom tilbage uden nogen konfigurationsændring.

Notér endepunktets adresse, ruten før og efter forbindelsen og det interface, hver af dem brugte. De tre fakta skiller normalt en klientfejl fra en tilsidesættelse, og de overlever den person, der indsamlede dem.

Opret forbindelse igen på det nye netværk, og gentag læsningen. Hvis undtagelsen mangler igen, hører rettelsen hjemme i den profil, der ejer den, og ikke i en engangskommando, der blev skrevet under et udfald.