Kan DHCP-ruter sende trafikken din rundt VPN-tunnelen?

Kryptering starter ved en grense, og den grensen er en rutbeslutning endepunktet tar før noen pakke blir innkapslet. Et nettverk som aldri ser nøklene dine, kan likevel gi maskinen din en rute det liker bedre enn tunnelens egen. To feil forveksles her: å lese en pakke som allerede er inne i tunnelen, og å styre en pakke som aldri ble lagt der.

Forskjellen betyr noe fordi den andre feilen er billigere å arrangere og mye lettere å overse. Den viser seg som en forespørsel som gikk ut via feil grensesnitt mens klienten fortsatt rapporterte en sunn tilkobling.

To måter et nettverk kan påvirke deg på

En pakke som når tunnelen, har nyttelasten sin skjult for hvert hopp den passerer, og den beskyttelsen holder selv når veien overrasker deg. En pakke som aldri når tunnelen, er en vanlig forespørsel fra adressen din, sendt dit rutetabellen pekte. Den første feilen krever et brutt chiffer eller en kompromittert motpart, mens den andre bare krever en konfigurasjonsmelding maskinen din valgte å stole på. Den asymmetrien er grunnen til at rutingshalvdelen fortjener sin egen gjennomgang.

Utstyr på veien trenger ikke nøklene dine for å påvirke det andre tilfellet. Det trenger at endepunktet ditt godtar en rute, en resolver eller en policyregel som produserer en.

expected:  app -> tunnel device -> encapsulation -> internet
observed:  app -> wlan0        -> plaintext     -> internet

Hvor en rute kan komme fra før tunnelen finnes

DHCP deler ut mer enn en adresseleie. Alternativet for klasseløse statiske ruter kan bære destinasjonsprefikser og neste hopp, og RFC 3442 drøfter sikkerhetskonsekvensene av en feil ruteradresse: feilsendt trafikk, tjenestenekt eller en observatør som sitter på veien. En klient som godtar disse rutene før tunnelen er oppe, kan ende med en foretrukket vei som ikke har noe med leverandøren din å gjøre.

Ingenting av dette gjør ruteinjeksjon universelt. Klienten må godta alternativet, prefikset må dekke trafikken du bryr deg om, det valgte neste hoppet må være nåbart, og håndhevingspolicyen må tillate pakken ut den veien. Fjern én av disse, og den samme responsen er harmløs. Det er også derfor to maskiner på ett nettverk kan oppføre seg ulikt, siden de ikke kjører samme klient, samme policy eller samme adressefamilie.

IPv6 fortjener sin egen runde, fordi ruterkunngjøringer bærer en standardrute gjennom annen kode enn DHCPv4-alternativet gjør. En test som bare undersøker v4-tabellen, har ikke dekket det.

Sjekk veien kjernen faktisk velger

Ruteoppslag kan besvares, så spør dem i stedet for å slutte fra et statuslys. Kommandoene nedenfor viser den valgte ruten og kilden for én destinasjon, pluss reglene som kan overstyre hovedtabellen. Kjør dem mens du er tilkoblet og igjen etter en ny tilkobling, fordi en fornyelse av leien kan endre svaret.

ip route get 203.0.113.10
ip route show table all | grep -E '^(default|203\.0\.113)'
ip rule show
resolvectl query example.com

Les utdata for to ting: grensesnittet som nevnes i ruten, og kildeadressen som velges. En tunnelrute nevner tunnel-enheten, en lekket rute nevner den fysiske, og forskjellen er synlig uten å dekryptere noe. Hvis svaret endrer seg mellom kjøringer, ta vare på begge utdataene og sammenlign reglene som produserte dem.

Ikke stopp ved standardruten. Et appunntak, et prefiks for delt tunnel eller en andre policyregel kan føre en bestemt destinasjon rundt tunnelen mens standarden fortsatt peker inn i den.

Avgjør hvor håndhevingen skal ligge

Tre forhold avgjør om håndheving på klientsiden er nok, eller om du trenger noe utenfor den. Hvis klienten installerer og forsvarer ruter for hver adressefamilie du bruker, er en tunnel som eier standardruten, vanligvis tilstrekkelig. Hvis maskinen må nå lokale ressurser mens alt annet blir inne i tunnelen, må disse unntakene listes opp og eies i stedet for å overlates til det aksessnettverket annonserte. Og hvis plattformen kan binde trafikk til et grensesnitt per app, er den bindingen en sterkere garanti enn en rute som hva som helst kan overstyre.

Uansett hva du velger, skriv beslutningen der konfigurasjonen bor. En regel som finnes fordi noen skrev den under en hendelse, overlever ikke neste omstart, så hold lokale unntak og oppstartsunntak smale og noter hvorfor hvert enkelt finnes.

Kjør oppslagskommandoene på nytt etter hver klientoppgradering og hver nettverksendring, og sammenlign med siste registrerte utdata. Rutetabellen er håndhevingsgrensen, så behandl den som en.