Rekursiv ruting: når tunnelen fangar sine eigne pakkar

Tunnelen kjem opp, loggen viser eit fullført handtrykk, og eitt sekund seinare døyr den same økta og koplar til på nytt i ei løkke. Det mønsteret har ei bestemt årsak: ruta til tenaren peikar no inn i tunnelen, så pakkane som ber tunnelen, blir sende gjennom tunnelen. Ingenting er endra i autentiseringa, og difor hjelper det ikkje å skrive inn påloggingsinformasjonen på nytt. Samanlikn den ytre vegen før og etter ruteendringa, så blir rekursjonen synleg.

Kontroller den ytre vegen først

Det er to pakkar i spel, ikkje éin. Den indre pakken høyrer til programmet og bør vere kryptert, medan den ytre pakken er adressert til tenaren og må nå han over ein veg som ikkje er avhengig av 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ør kjernen om ruta til adressa til tenaren etter at tunnelen er oppe, og igjen etter at standardruta er endra. Eit neste hopp som landar på eininga til tunnelen, er sjølve rekursjonen, og han er synleg utan noka pakkefangst. Interfacebinding, merke eller eit nettverksnamnerom kan gjere eit vanleg oppslag ufullstendig, så bruk konteksten klienten sjølv brukar. Når svaret ser rett ut, men økta framleis går i løkke, les reglane for rutingpolitikken og ikkje berre hovudtabellen.

Kvifor økta overlever eit augneblink

Handtrykket blir fullført før den nye ruta blir installert, så dei første sekunda ser friske ut. Straks klienten legg til standardruta, følgjer den neste ytre pakken henne inn i grensesnittet som den pakken må reise gjennom. Tenaren ser ingenting, klienten sender på nytt, og forsøket renn anten ut eller drep økta og startar på nytt.

Den rekkjefølgja forklarer kvifor ein tunnel kan verke på ein berbar og svikte på ein ruter, og kvifor feilen ofte byrjar når trafikken startar og ikkje ved tilkopling. Ho forklarer òg løkka: kvar omstart gjenopprettar økta før ruta gjer det umogeleg.

Finn ut kven som eig unntaket for endepunktet

Støtta klientar ordnar sitt eige unntak: ei vertsrute til tenaren gjennom den opphavlege gatewayen, eller eit merke som held den ytre sockelen utanfor tunnelen. Spørsmålet er om noko anna har fjerna eller overstyrt det.

For rutebasert IPsec, undersøk policyveljarane som avgjer kva pakkar som kjem inn i tunnelen, og stadfest at peer-adressa er utelaten frå dei. For WireGuard held brannmurmerket til grensesnittet og policyreglane transportpakkane utanfor tunnelen, så ei manuelt lagt til standardrute kan øydeleggje den ordninga. Ein andre VPN-profil eller eit administrasjonsskript som skriv om standardruta er ein vanleg skuldig. Breie omgåingsreglar lagde til éin om gongen er det vanlege resultatet, og dei gjer ein rutefeil om til ein tabell ingen kan vedlikehalde.

Kontroller på nytt etter ei nettverksendring

Ei vertsrute gjennom ein Wi-Fi-gateway er rett heilt til maskinen flyttar til eit anna nettverk. Då kjem det same symptomet tilbake utan noka konfigurasjonsendring.

Noter adressa til endepunktet, ruta før og etter tilkopling, og grensesnittet kvar av dei brukte. Desse tre fakta skil vanlegvis ein klientfeil frå ei overstyring, og dei overlever personen som samla dei.

Kopla til på nytt i det nye nettverket og gjenta lesinga. Viss unntaket manglar igjen, høyrer rettinga heime i profilen som eig det, ikkje i ein eingongskommando skriven inn under eit avbrot.