Rekursiv ruting: når tunnelen fanger sine egne pakker

Tunnelen kommer opp, loggen viser et fullført håndtrykk, og ett sekund senere dør den samme sesjonen og kobler til på nytt i en løkke. Det mønsteret har en bestemt årsak: ruten til serveren peker nå inn i tunnelen, så pakkene som bærer tunnelen, sendes gjennom tunnelen. Ingenting er endret i autentiseringen, og derfor hjelper det ikke å skrive inn påloggingsinformasjonen på nytt. Sammenlign den ytre veien før og etter ruteendringen, så blir rekursjonen synlig.

Kontroller den ytre veien først

Det er to pakker i spill, ikke én. Den indre pakken tilhører applikasjonen og bør være kryptert, mens den ytre pakken er adressert til serveren og må nå den over en vei som ikke avhenger 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 ruten til serverens adresse etter at tunnelen er oppe, og igjen etter at standardruten er endret. Et neste hopp som lander på tunnelens enhet, er selve rekursjonen, og den er synlig uten noen pakkefangst. Interfacebinding, merker eller et nettverksnavnerom kan gjøre et vanlig oppslag ufullstendig, så bruk konteksten klienten selv bruker. Når svaret ser riktig ut, men sesjonen fortsatt går i løkke, les reglene for rutingpolitikken og ikke bare hovedtabellen.

Hvorfor sesjonen overlever et øyeblikk

Håndtrykket fullføres før den nye ruten installeres, så de første sekundene ser friske ut. Straks klienten legger til standardruten, følger den neste ytre pakken den inn i grensesnittet som den pakken må reise gjennom. Serveren ser ingenting, klienten sender på nytt, og forsøket løper enten ut eller dreper sesjonen og starter på nytt.

Den rekkefølgen forklarer hvorfor en tunnel kan virke på en bærbar og svikte på en ruter, og hvorfor feilen ofte begynner når trafikken starter og ikke ved tilkobling. Den forklarer også løkken: hver omstart gjenoppretter sesjonen før ruten gjør det umulig.

Finn ut hvem som eier unntaket for endepunktet

Støttede klienter ordner sitt eget unntak: en vertsrute til serveren gjennom den opprinnelige gatewayen, eller et merke som holder den ytre sockelen utenfor tunnelen. Spørsmålet er om noe annet har fjernet eller overstyrt det.

For rutebasert IPsec, undersøk policyvelgerne som avgjør hvilke pakker som kommer inn i tunnelen, og bekreft at peer-adressen er utelatt fra dem. For WireGuard holder firewallmerket til grensesnittet og policyreglene transportpakkene utenfor tunnelen, så en manuelt lagt til standardrute kan ødelegge den ordningen. En andre VPN-profil eller et administrasjonsskript som skriver om standardruten er en vanlig skyldig. Brede omgåelsesregler lagt til én om gangen er det vanlige resultatet, og de gjør en rutingsfeil om til en tabell ingen kan vedlikeholde.

Kontroller på nytt etter en nettverksendring

En vertsrute gjennom en Wi-Fi-gateway er riktig helt til maskinen flytter til et annet nettverk. Da kommer det samme symptomet tilbake uten noen konfigurasjonsendring.

Noter endepunktets adresse, ruten før og etter tilkobling, og grensesnittet hver av dem brukte. Disse tre fakta skiller vanligvis en klientfeil fra en overstyring, og de overlever personen som samlet dem.

Koble til på nytt i det nye nettverket og gjenta lesingen. Hvis unntaket mangler igjen, hører rettelsen hjemme i profilen som eier det, ikke i en engangskommando skrevet inn under et avbrudd.