ICMP-omdirigeringar kontra dina VPN-rutter: vad som faktiskt ändras

Ett flöde som borde gå genom tunneln väljer en annan nästa hopp och någon hittar en ICMP-omdirigering i en capture. Det är en hypotes, inte en diagnos. En omdirigering är routerns förslag om ett bättre nästa hopp, och om värden agerar på det beror på inställningar som skiljer sig per plattform, per gränssnitt och per adressfamilj.

En omdirigering är ett förslag från en router

IPv4 ICMP-omdirigeringar har en egen meddelandetyp och en snäv uppsättning villkor: routern skickar ut ett paket genom det gränssnitt det kom in på, och den känner till ett nästa hopp på samma länk som ligger närmare målet. Sedan säger den till avsändaren att använda det hoppet direkt. Meddelandet namnger den nya gatewayen och innehåller en del av det ursprungliga paketet så att avsändaren kan matcha det mot ett flöde. Det är ett artigt meddelande om den lokala topologin, och det förutsätter att avsändaren delar länk med den föreslagna gatewayen.

Avsändaren står fritt att ignorera det. Protokollet kräver inte att en värd ändrar sin tabell, och en fångad omdirigering bevisar bara att en router skickade en.

Det är på den skillnaden de flesta omdirigeringsutredningar går fel.

IPv4 och IPv6 levererar det olika

IPv6 har en motsvarande mekanism inne i grannupptäckten i stället för i ICMPv4, med andra meddelandeformat och andra valideringsregler. Begreppen rimmar, paketen gör det inte. Ett capture-filter skrivet för ICMP-typ 5 visar ingenting på ett IPv6-nät, vilket ibland läses som bevis för att ingen omdirigering skett.

Policy-reglagen är också åtskilda, så en värd kan acceptera IPv4-omdirigeringar och ignorera IPv6, eller tvärtom.

Kontrollera båda familjerna om flödet i fråga kan använda någon av dem.

Acceptans är värdpolicy, inte ett nätverksfaktum

På Linux styrs acceptans av omdirigeringar per gränssnitt och globalt, och standardvärdena skiljer sig mellan värd- och routerrollen. Ett tunnelgränssnitt som accepterar omdirigeringar är en märklig design, eftersom det i en punkt-till-punkt-tunnel inte finns något meningsfullt alternativt nästa hopp på samma länk. Därför är inställningen värd att läsa i stället för att antas.

Inställningar för secure redirects begränsar dessutom vilka gatewayer som får tros på.

Om du skärper en värd är det dessa reglage du ska gå igenom, och de är också skälet till att två maskiner i samma nät kan bete sig olika. Ändra dem som policy, inte som genväg vid felsökning.

Vad en omdirigering inte kan förklara

Specifika rutter, policy-routingregler och lokala gränssnitt förklarar de flesta oväntade vägar utan någon omdirigering. Ett mer specifikt prefix, en regel som matchar källadressen, eller en andra standardrutt i en annan tabell var och en av dem åsidosätter rutten du förväntade dig. Kontrollera dem först, eftersom de är deterministiska och synliga.

En gammal capture är den andra fällan, eftersom en klient som bytt nät har en annan lokal gateway.

En gammal omdirigering från den tidigare anslutningen förklarar ingenting om den nuvarande vägen, så anteckna vilket gränssnitt som tar emot kontrolltrafiken nu.

Kontrollera rutten innan du skyller på tunneln

Fråga kärnan vilken rutt den skulle använda för målet, jämför den sedan med tabellen du menade. Om svaret stämmer med tabellen har ingen omdirigering ändrat något och utredningen hör hemma någon annanstans. Om det inte stämmer, leta efter en cachad omdirigering, en policyregel eller en andra tabell innan du antar att tunneln är skyldig. Ruttuppslaget är grundsanningen, och allt annat är en berättelse om hur det blev så.

En omdirigering bör aldrig vara skälet till att en skyddad väg tyst blir oskyddad, och därför hör acceptanspolicyn hemma i designgranskningen. Definitionen i RFC 792 står kvar som referens för vad IPv4-meddelandet får säga.

Skriv ner ruttuppslaget och tidsstämpeln för capture tillsammans, så kan nästa person återge din slutsats.