Rekursiv routning: när tunneln fångar sina egna paket

Tunneln kommer upp, loggen visar en slutförd handskakning, och en sekund senare dör samma session och återansluter i en slinga. Det mönstret har en bestämd orsak: vägen till servern pekar nu in i tunneln, så paketen som bär tunneln skickas genom tunneln. Inget har ändrats i autentiseringen, och därför hjälper det inte att ange inloggningsuppgifterna igen. Jämför den yttre vägen före och efter vägändringen och rekursionen blir synlig.

Kontrollera den yttre vägen först

Det är två paket i spel, inte ett. Det inre paketet tillhör applikationen och bör vara krypterat, medan det yttre paketet är adresserat till servern och måste nå den via en väg som inte beror av tunneln.

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

Fråga kärnan om vägen till serverns adress när tunneln är uppe, och igen efter att standardvägen ändrats. Ett nästa hopp som landar på tunnelns enhet är själva rekursionen, och den syns utan någon paketinsamling. En bindning till gränssnittet, märken eller ett nätverksnamnrymd kan göra en vanlig sökning ofullständig, så använd den kontext som klienten själv använder. När svaret ser rätt ut men sessionen fortsätter att slingra, läs reglerna för routningspolicyn och inte bara huvudtabellen.

Varför sessionen överlever ett ögonblick

Handskakningen slutförs innan den nya vägen installeras, så de första sekunderna ser friska ut. Så snart klienten lägger till standardvägen följer nästa yttre paket den in i det gränssnitt som paketet måste färdas genom. Servern ser ingenting, klienten skickar igen, och försöket antingen löper ut eller dödar sessionen och börjar om.

Den ordningen förklarar varför en tunnel kan fungera på en bärbar dator och misslyckas på en router, och varför felet ofta börjar när trafiken startar och inte vid anslutningen. Den förklarar också slingan: varje omstart återupprättar sessionen innan vägen gör det omöjligt.

Ta reda på vem som äger undantaget för slutpunkten

Klienter som stöds ordnar sitt eget undantag: en värdväg till servern via den ursprungliga gatewayen, eller ett märke som håller den yttre sockeln utanför tunneln. Frågan är om något annat har tagit bort eller skrivit över det.

För ruttbaserad IPsec, granska de policyväljare som avgör vilka paket som kommer in i tunneln och bekräfta att peer-adressen är utesluten från dem. För WireGuard håller gränssnittets brandväggsmärke och dess policyregler transportpaketen utanför tunneln, så en manuellt tillagd standardväg kan förstöra den ordningen. En andra VPN-profil eller ett administrationsskript som skriver om standardvägen är en vanlig skyldig. Breda kringgåenderegler som läggs till en i taget är det vanliga resultatet, och de förvandlar ett routningsfel till en tabell som ingen kan underhålla.

Kontrollera igen efter en nätverksändring

En värdväg via en Wi-Fi-gateway är korrekt tills maskinen flyttar till ett annat nätverk. Då kommer samma symptom tillbaka utan någon konfigurationsändring.

Notera slutpunktens adress, vägen före och efter anslutningen, och det gränssnitt som var och en använde. Dessa tre fakta skiljer oftast ett klientfel från en överskrivning, och de överlever personen som samlade in dem.

Anslut igen på det nya nätverket och upprepa läsningen. Om undantaget saknas igen hör rättelsen hemma i profilen som äger det, inte i ett engångskommando som skrivits in under ett avbrott.