ICMP-omdirigeringer mot VPN-rutene dine: hva som faktisk endres

En strøm som skulle gå gjennom tunnelen, velger en annen neste hopp, og noen finner en ICMP-omdirigering i en capture. Det er en hypotese, ikke en diagnose. En omdirigering er et forslag fra en ruter om en bedre neste hopp, og om verten handler på det, avhenger av innstillinger som varierer per plattform, per grensesnitt og per adressefamilie.

En omdirigering er et forslag fra en ruter

IPv4 ICMP-omdirigeringer har sin egen meldingstype og et smalt sett vilkår: ruteren sender en pakke ut gjennom grensesnittet den kom inn på, og den kjenner en neste hopp på samme lenke som ligger nærmere målet. Deretter sier den til avsenderen at hoppet skal brukes direkte. Meldingen navngir den nye gatewayen og inneholder en del av den opprinnelige pakken, slik at avsenderen kan koble den til en strøm. Det er en høflig melding om den lokale topologien, og den forutsetter at avsenderen deler lenke med gatewayen som foreslås.

Avsenderen står fritt til å se bort fra den. Protokollen krever ikke at en vert endrer tabellen sin, og en fanget omdirigering beviser bare at en ruter sendte en.

Det er på denne forskjellen de fleste omdirigeringsundersøkelser går feil.

IPv4 og IPv6 leverer det ulikt

IPv6 har en tilsvarende mekanisme inne i nabo-oppdagelsen i stedet for i ICMPv4, med andre meldingsformater og andre valideringsregler. Begrepene rimer, pakkene gjør det ikke. Et capture-filter skrevet for ICMP-type 5 viser ingenting på et IPv6-nett, noe som noen ganger leses som bevis på at ingen omdirigering har skjedd.

Policy-bryterne er også atskilt, så en vert kan godta IPv4-omdirigeringer og se bort fra IPv6-omdirigeringer, eller omvendt.

Sjekk begge familiene hvis strømmen det gjelder kan bruke hvilken som helst av dem.

Aksept er vertspolicy, ikke et nettverksfaktum

På Linux styres aksept av omdirigeringer per grensesnitt og globalt, og standardverdiene varierer mellom verts- og ruterrollen. Et tunnelgrensesnitt som godtar omdirigeringer er et rart design, fordi det i en punkt-til-punkt-tunnel ikke finnes noen meningsfull alternativ neste hopp på samme lenke. Derfor er denne innstillingen verdt å lese i stedet for å gå ut fra.

Innstillinger for secure redirects begrenser videre hvilke gatewayer som kan gis tillit.

Hvis du strammer inn en vert, er det disse bryterne du skal gå gjennom, og de er også grunnen til at to maskiner på samme nett kan oppføre seg ulikt. Endre dem som policy, ikke som en snarvei for feilsøking.

Hva en omdirigering ikke kan forklare

Spesifikke ruter, policyrutingsregler og lokale grensesnitt forklarer de fleste uventede stier uten noen omdirigering. Et mer spesifikt prefiks, en regel som passer til kildeadressen, eller en andre standardrute i en annen tabell hver av dem overstyrer ruten du forventet. Sjekk dem først, fordi de er deterministiske og synlige.

En gammel capture er den andre fellen, fordi en klient som har byttet nett har en annen lokal gateway.

En gammel omdirigering fra forrige tilkobling forklarer ingenting om den nåværende stien, så noter hvilket grensesnitt som mottar kontrolltrafikken nå.

Sjekk ruten før du gir tunnelen skylden

Spør kjernen hvilken rute den ville bruke for målet, sammenlign den så med tabellen du mente. Hvis svaret stemmer med tabellen, har ingen omdirigering endret noe, og undersøkelsen hører hjemme et annet sted. Hvis det ikke stemmer, let etter en bufret omdirigering, en policyregel eller en andre tabell før du går ut fra at tunnelen er skyld i noe. Ruteoppslaget er grunnsannheten, og alt annet er en fortelling om hvordan det ble slik.

En omdirigering skal aldri være grunnen til at en beskyttet sti stille blir en ubeskyttet en, og derfor hører akseptpolicyen hjemme i designgjennomgangen. RFC 792-definisjonen står fortsatt som referansen for hva IPv4-meldingen kan si.

Skriv ruteoppslaget og tidsstempelet for capture sammen, så kan neste person reprodusere konklusjonen din.