Kan DHCP-ruter sende din trafik uden om VPN-tunnelen?

Kryptering begynder ved en grænse, og den grænse er en routingbeslutning, som endepunktet træffer, før nogen pakke bliver indkapslet. Et netværk, der aldrig ser dine nøgler, kan stadig give din maskine en rute, det bedre kan lide end tunnelens egen. To fejl forveksles her: at læse en pakke, der allerede er inde i tunnelen, og at styre en pakke, der aldrig blev sat derind.

Forskellen betyder noget, fordi den anden fejl er billigere at arrangere og meget lettere at overse. Den viser sig som en anmodning, der forlod gennem den forkerte grænseflade, mens klienten stadig rapporterede en sund forbindelse.

To måder et netværk kan påvirke dig på

En pakke, der når tunnelen, har sin nyttelast skjult for hvert hop, den krydser, og den beskyttelse holder, selv når ruten overrasker dig. En pakke, der aldrig når tunnelen, er en almindelig anmodning fra din adresse, sendt hvorhen rutetabellen pegede. Den første fejl kræver en brudt cipher eller en kompromitteret peer, mens den anden kun kræver en konfigurationsbesked, som din maskine valgte at stole på. Den asymmetri er grunden til, at routinghalvdelen fortjener sin egen gennemgang.

Udstyr på vejen behøver ikke dine nøgler for at påvirke det andet tilfælde. Det behøver kun, at dit endepunkt accepterer en rute, en resolver eller en politikregel, der frembringer en.

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

Hvor en rute kan komme fra, før tunnelen findes

DHCP uddeler mere end en adresseleasing. Muligheden for klasseløse statiske ruter kan bære destinationspræfikser og næste hop, og RFC 3442 drøfter sikkerhedskonsekvenserne af en forkert routeradresse: fejlstyret trafik, et tjenestenægtelse eller en observatør placeret på vejen. En klient, der accepterer disse ruter, før tunnelen er oppe, kan ende med en foretrukken vej, der intet har at gøre med din udbyder.

Intet af det gør ruteinjektion universel. Klienten skal acceptere muligheden, præfikset skal dække den trafik, du bekymrer dig om, det valgte næste hop skal være nåbart, og håndhævelsespolitikken skal tillade pakken at gå ud den vej. Fjern en af dem, og det samme svar er uskadeligt. Det er også derfor, at to maskiner på samme netværk kan opføre sig forskelligt, da de ikke kører samme klient, samme politik eller endda samme adressefamilie.

IPv6 fortjener sin egen gennemgang, fordi routerannonceringer bærer en standardrute gennem en anden kode end DHCPv4-muligheden gør. En test, der kun undersøger v4-tabellen, har ikke dækket det.

Kontrollér den vej, kernen faktisk vælger

Ruteopslag kan besvares, så spørg dem i stedet for at slutte fra en statuslampe. Kommandoerne nedenfor viser den valgte rute og kilde for én destination samt de regler, der kan tilsidesætte hovedtabellen. Kør dem, mens du er forbundet, og igen efter en genopkobling, fordi en fornyelse af leasingen kan ændre 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

Læs outputtet efter to ting: den grænseflade, der nævnes i ruten, og den valgte kildeadresse. En tunnelrute nævner tunnelanordningen, en lækket rute nævner den fysiske, og forskellen er synlig uden at dekryptere noget. Hvis svaret ændrer sig mellem kørsler, så gem begge output og sammenlign de regler, der frembragte dem.

Stop ikke ved standardruten. En applikationsundtagelse, et splittunnel-præfiks eller en anden politikregel kan føre en bestemt destination uden om tunnelen, mens standarden stadig peger ind i den.

Beslut, hvor håndhævelsen skal ligge

Tre betingelser afgør, om håndhævelse på klientsiden er nok, eller om du har brug for noget uden for den. Hvis klienten installerer og forsvarer ruter for enhver adressefamilie, du bruger, er en tunnel, der ejer standardruten, normalt tilstrækkelig. Hvis maskinen skal nå lokale ressourcer, mens alt andet bliver inde i tunnelen, skal disse undtagelser opregnes og ejes i stedet for at overlades til, hvad adgangsnetværket annoncerede. Og hvis platformen kan binde trafik til en grænseflade pr. applikation, er den binding en stærkere garanti end en rute, som hvad som helst kan tilsidesætte.

Uanset hvad du vælger, så skriv beslutningen, hvor konfigurationen ligger. En regel, der findes, fordi nogen skrev den under en hændelse, overlever ikke den næste genstart, så hold lokale undtagelser og bootstrap-undtagelser snævre og notér, hvorfor hver af dem findes.

Kør opslagskommandoerne igen efter hver klientopdatering og hver netværksændring, og sammenlign med det sidst registrerede output. Rutetabellen er håndhævelsesgrænsen, så behandl den som sådan.