Kan DHCP-rutter skicka din trafik runt VPN-tunneln?

Kryptering börjar vid en gräns, och den gränsen är ett routingbeslut som slutpunkten fattar innan något paket kapslas in. Ett nätverk som aldrig ser dina nycklar kan ändå ge din maskin en rutt det tycker bättre om än tunneln egen. Två fel blandas ihop här: att läsa ett paket som redan ligger i tunneln, och att styra ett paket som aldrig lades där.

Skillnaden spelar roll eftersom det andra felet är billigare att ordna och mycket lättare att missa. Det visar sig som en begäran som gick ut via fel gränssnitt medan klienten fortfarande rapporterade en frisk anslutning.

Två sätt ett nätverk kan påverka dig

Ett paket som når tunneln har sin nyttolast dold för varje hopp det passerar, och det skyddet håller även när vägen överraskar dig. Ett paket som aldrig når tunneln är en vanlig begäran från din adress, skickad dit rutttabellen pekade. Det första felet kräver ett brutet chiffer eller en komprometterad motpart, medan det andra bara kräver ett konfigurationsmeddelande som din maskin valde att lita på. Den asymmetrin är skälet till att routinghalvan förtjänar en egen granskning.

Utrustning på vägen behöver inte dina nycklar för att påverka det andra fallet. Den behöver bara att din slutpunkt accepterar en rutt, en resolver eller en policyregel som ger en.

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

Varifrån en rutt kan komma innan tunneln finns

DHCP delar ut mer än ett adresslån. Alternativet för klasslösa statiska rutter kan bära destinationsprefix och nästa hopp, och RFC 3442 diskuterar säkerhetskonsekvenserna av en felaktig routeradress: trafik som skickas fel, en överbelastningsattack eller en observatör som sitter på vägen. En klient som accepterar dessa rutter innan tunneln är uppe kan hamna på en föredragen väg som inte har något med din leverantör att göra.

Inget av detta gör ruttinjektion universell. Klienten måste acceptera alternativet, prefixet måste täcka trafiken du bryr dig om, nästa hopp måste vara nåbart och genomdrivandepolicyn måste tillåta paketet ut den vägen. Ta bort något av dessa och samma svar är ofarligt. Det är också därför två maskiner i samma nätverk kan bete sig olika, eftersom de inte kör samma klient, samma policy eller ens samma adressfamilj.

IPv6 förtjänar en egen omgång, eftersom routerannonser bär en standardrutt genom annan kod än DHCPv4-alternativet gör. Ett test som bara inspekterar v4-tabellen har inte täckt det.

Kontrollera vägen som kärnan faktiskt väljer

Ruttuppslag kan besvaras, så fråga dem i stället för att sluta dig till något från en statuslampa. Kommandona nedan visar den valda rutten och källan för en destination, plus reglerna som kan åsidosätta huvudtabellen. Kör dem medan du är ansluten och igen efter en återanslutning, eftersom ett förnyat lån kan ändra 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 utdata för två saker: gränssnittet som nämns i rutten och den valda källadressen. En tunnelrutt namnger tunnelenheten, en läckt rutt namnger den fysiska, och skillnaden syns utan att dekryptera något. Om svaret ändras mellan körningarna, spara båda utdata och jämför reglerna som gav dem.

Stanna inte vid standardrutten. Ett appundantag, ett prefix för delad tunnel eller en andra policyregel kan föra en specifik destination runt tunneln medan standarden fortfarande pekar in i den.

Bestäm var genomdrivandet ska ligga

Tre villkor avgör om genomdrivande på klientsidan räcker eller om du behöver något utanför det. Om klienten installerar och försvarar rutter för varje adressfamilj du använder, räcker oftast en tunnel som äger standardrutten. Om maskinen måste nå lokala resurser medan allt annat stannar i tunneln, måste de undantagen räknas upp och ägas i stället för att lämnas åt det åtkomstnätverket annonserade. Och om plattformen kan binda trafik till ett gränssnitt per app, är den bindningen en starkare garanti än en rutt som vad som helst kan åsidosätta.

Vad du än väljer, skriv beslutet där konfigurationen bor. En regel som finns för att någon skrev den under en incident överlever inte nästa omstart, så håll lokala undantag och startundantag smala och anteckna varför varje finns.

Kör uppslagskommandona igen efter varje klientuppgradering och varje nätverksändring, och jämför med senast registrerade utdata. Rutttabellen är genomdrivandets gräns, så behandla den som en sådan.