ICMP-omdirigeringar mot VPN-rutene dine: kva som faktisk endrar seg

Ein straum som skulle gå gjennom tunnelen, vel ein annan neste hopp, og nokon finn ei ICMP-omdirigering i ein capture. Det er ein hypotese, ikkje ein diagnose. Ei omdirigering er eit framlegg frå ein ruter om ein betre neste hopp, og om verten gjer noko med det, kjem an på innstillingar som skil seg per plattform, per interface og per adressefamilie.

Ei omdirigering er eit framlegg frå ein ruter

IPv4 ICMP-omdirigeringar har sin eigen meldingstype og eit smalt sett vilkår: ruteren sender eit pakke ut gjennom interfacet det kom inn på, og han kjenner ein neste hopp på same lenkja som ligg nærare målet. Deretter seier han til avsendar at hoppet skal brukast direkte. Meldinga namngir den nye gatewayen og inneheld ein del av den opphavlege pakken, slik at avsendaren kan kople han til ein straum. Det er ei høfleg melding om den lokale topologien, og ho går ut frå at avsendaren deler lenkje med gatewayen som er føreslått.

Avsendaren står fritt til å sjå bort frå ho. Protokollen krev ikkje at ein vert endrar tabellen sin, og ei fanga omdirigering beviser berre at ein ruter sende ei.

Det er på denne skilnaden dei fleste omdirigeringsgranskingar går feil.

IPv4 og IPv6 leverer det ulikt

IPv6 har ein tilsvarande mekanisme inne i nabo-oppdaginga i staden for i ICMPv4, med andre meldingsformat og andre valideringsreglar. Omgrepa rimer, pakkane gjer det ikkje. Eit capture-filter skrive for ICMP-type 5 viser ingenting på eit IPv6-nett, noko som stundom blir lese som prov på at inga omdirigering har skjedd.

Politikk-brytane er også åtskilde, så ein vert kan ta imot IPv4-omdirigeringar og sjå bort frå IPv6-omdirigeringar, eller omvendt.

Sjekk begge familiane dersom straumen det gjeld kan bruke kven som helst av dei.

Aksept er vertspolitikk, ikkje eit nettverksfaktum

På Linux blir aksept av omdirigeringar styrt per interface og globalt, og standardverdiane skil seg mellom verts- og ruterrolla. Eit tunnel-interface som tek imot omdirigeringar er eit rart design, fordi det i ein punkt-til-punkt-tunnel ikkje finst noko meiningsfullt alternativ neste hopp på same lenkja. Derfor er denne innstillinga verd å lese i staden for å gå ut frå.

Innstillingar for secure redirects avgrensar vidare kva gatewayar som kan få tillit.

Viss du strammar inn ein vert, er det desse brytane du skal gå gjennom, og dei er også grunnen til at to maskinar på same nett kan oppføre seg ulikt. Endre dei som politikk, ikkje som ein snarveg for feilsøking.

Kva ei omdirigering ikkje kan forklare

Spesifikke ruter, politikkrutingsreglar og lokale interface forklarar dei fleste uventa stiane utan noka omdirigering. Eit meir spesifikt prefiks, ein regel som passar til kjeldeadressa, eller ei andre standardrute i ein annan tabell kvar av dei overstyrer ruta du venta. Sjekk dei først, fordi dei er deterministiske og synlege.

Ein gamal capture er den andre fella, fordi ein klient som har bytt nett har ein annan lokal gateway.

Ei gamal omdirigering frå den førre tilkoplinga forklarar ingenting om den noverande stien, så noter kva interface som tek imot kontrolltrafikken no.

Sjekk ruta før du gir tunnelen skulda

Spør kjernen kva rute han ville bruke for målet, samanlikn ho så med tabellen du meinte. Viss svaret stemmer med tabellen, har inga omdirigering endra noko, og granskinga høyrer heime ein annan stad. Viss det ikkje stemmer, leit etter ei cacha omdirigering, ein politikkregel eller ein annan tabell før du går ut frå at tunnelen er skuld i noko. Ruteoppslaget er grunnsanninga, og alt anna er ei forteljing om korleis det vart slik.

Ei omdirigering skal aldri vere grunnen til at ein verna sti stille blir ein uverna ein, og derfor høyrer akseptpolitikken heime i designgjennomgangen. RFC 792-definisjonen blir ståande som referansen for kva IPv4-meldinga kan seie.

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