ICMP-omdirigeringer kontra dine VPN-ruter: hvad der reelt ændrer sig

Et flow, der burde krydse tunnelen, tager et andet næste hop, og nogen finder en ICMP-omdirigering i en optagelse. Det er en hypotese, ikke en diagnose. En omdirigering er routerens forslag om et bedre næste hop, og om værten handler på den afhænger af indstillinger, der varierer efter platform, interface og adressefamilie.

En omdirigering er et forslag fra en router

IPv4 ICMP-omdirigeringer har deres egen meddelelsestype og et snævert sæt betingelser: routeren videresender en pakke ud ad det interface, den kom ind ad, og den kender et næste hop på samme link, der er tættere på destinationen. Derefter fortæller den afsenderen at bruge det næste hop direkte. Meddelelsen navngiver den nye gateway og indeholder en del af den oprindelige pakke, så afsenderen kan matche den til et flow. Det er en høflighedsmeddelelse om lokal topologi, og den forudsætter, at afsenderen deler et link med den foreslåede gateway.

Afsenderen er fri til at ignorere den. Intet i protokollen kræver, at en vært ændrer sin tabel, og en opsnappet omdirigering beviser kun, at en router sendte en.

Det er netop i denne sondring, at de fleste undersøgelser af omdirigeringer går galt.

IPv4 og IPv6 leverer det forskelligt

IPv6 har en tilsvarende mekanisme inde i neighbor discovery i stedet for i ICMPv4, med andre meddelelsesformater og andre valideringsregler. Begreberne rimer, og pakkerne gør ikke. Et optagelsesfilter skrevet til ICMP type 5 vil ikke vise noget på et IPv6-netværk, hvilket nogle gange læses som bevis for, at der ikke skete nogen omdirigering.

Politikknapperne er også adskilte, så en vært kan acceptere IPv4-omdirigeringer og ignorere IPv6-dem, eller omvendt.

Kontroller begge familier, hvis det pågældende flow kan bruge en af dem.

Accept er værtspolitik, ikke en netværkskendsgerning

På Linux styres accept af omdirigeringer pr. interface og globalt, og standardværdierne er forskellige for værts- og routerroller. Et tunnelinterface, der accepterer omdirigeringer, er et mærkeligt design, da der ikke findes noget meningsfuldt alternativt næste hop på samme link inde i en punkt-til-punkt-tunnel. Det gør indstillingen værd at læse frem for at antage.

Indstillinger for sikker omdirigering begrænser yderligere, hvilke gateways der kan troes.

Hvis du strammer en vært, er det de knapper, der skal gennemgås, og de er også grunden til, at to maskiner på samme netværk kan opføre sig forskelligt. Ændr dem som politik, ikke som en fejlretningsgenvej.

Hvad en omdirigering ikke kan forklare

Specifikke ruter, policy routing-regler og lokale interfaces forklarer de fleste uventede stier helt uden en omdirigering. Et mere specifikt præfiks, en regel, der matcher kildeaddressen, eller en anden standard i en anden tabel vil hver især overtrumfe den rute, du forventede. Kontroller dem først, fordi de er deterministiske og synlige.

Forældede optagelser er den anden fælde, da en klient, der har skiftet netværk, har en anden lokal gateway.

En gammel omdirigering fra den tidligere tilslutning forklarer intet om den aktuelle sti, så noter, hvilket interface der modtager kontroltrafikken nu.

Kontroller ruten, før du bebrejder tunnelen

Spørg kernen, hvilken rute den ville bruge til destinationen, og sammenlign det derefter med den tabel, du havde tænkt dig. Hvis svaret passer med tabellen, har ingen omdirigering ændret noget, og undersøgelsen hører til et andet sted. Hvis det ikke passer, så led efter en cachelagret omdirigering, en politikregel eller en anden tabel, før du antager, at tunnelen er skyldneren. Opslaget er grundsandheden, og alt andet er en historie om, hvordan det kom dertil.

En omdirigering bør aldrig være grunden til, at en beskyttet sti stille bliver en ubeskyttet, og derfor hører acceptpolitikken hjemme i designgennemgangen. Definitionen i RFC 792 forbliver reference for, hvad IPv4-meddelelsen må sige.

Skriv ruteopslaget og optagelsens tidsstempel sammen, så kan den næste person genskabe din konklusion.