Le rotte DHCP possono far uscire il tuo traffico dal tunnel VPN?

La crittografia inizia a un confine, e quel confine è una decisione di instradamento che l'endpoint prende prima che qualsiasi pacchetto venga incapsulato. Una rete che non vede mai le tue chiavi può comunque consegnare alla tua macchina una rotta che preferisce a quella del tunnel stesso. Qui si confondono due guasti: leggere un pacchetto già dentro il tunnel e deviare un pacchetto che non vi è mai stato messo.

La distinzione conta perché il secondo guasto è più economico da organizzare e molto più facile da mancare. Si manifesta come una richiesta uscita dall'interfaccia sbagliata mentre il client segnalava ancora una connessione sana.

Due modi in cui una rete può influenzarti

Un pacchetto che raggiunge il tunnel ha il suo carico utile nascosto a ogni salto che attraversa, e quella protezione tiene anche quando il percorso ti sorprende. Un pacchetto che non raggiunge mai il tunnel è una richiesta ordinaria dal tuo indirizzo, inviata dove puntava la tabella di routing. Il primo guasto richiede un cifrario rotto o un peer compromesso, mentre il secondo richiede solo un messaggio di configurazione a cui la tua macchina ha scelto di credere. È quell'asimmetria il motivo per cui la metà dell'instradamento merita una revisione propria.

L'apparecchiatura lungo il percorso non ha bisogno delle tue chiavi per influenzare il secondo caso. Le basta che il tuo endpoint accetti una rotta, un resolver o una regola di policy che ne produca una.

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

Da dove può arrivare una rotta prima che il tunnel esista

DHCP distribuisce più di una concessione di indirizzo. L'opzione di rotta statica senza classi può portare prefissi di destinazione e salti successivi, e RFC 3442 esamina le conseguenze di sicurezza di un indirizzo del router errato: traffico deviato, un diniego di servizio o un osservatore appostato sul percorso. Un client che accetta quelle rotte prima che il tunnel sia su può ritrovarsi con un percorso preferito che non ha nulla a che fare con il tuo fornitore.

Niente di tutto ciò rende universale l'iniezione delle rotte. Il client deve accettare l'opzione, il prefisso deve coprire il traffico che ti interessa, il salto successivo scelto deve essere raggiungibile e la policy di applicazione deve permettere al pacchetto di uscire per quella via. Togli uno di questi elementi e la stessa risposta diventa innocua. È anche per questo che due macchine sulla stessa rete possono comportarsi diversamente, dato che non eseguono lo stesso client, la stessa policy né la stessa famiglia di indirizzi.

IPv6 merita un passaggio suo, perché gli annunci del router portano una rotta predefinita tramite un codice diverso da quello dell'opzione DHCPv4. Un test che ispeziona solo la tabella v4 non l'ha coperto.

Controlla il percorso che il kernel sceglie davvero

Le ricerche di rotta hanno una risposta, quindi conviene interrogarle invece di dedurre da una spia di stato. I comandi qui sotto mostrano la rotta e la sorgente scelte per una destinazione, oltre alle regole che possono prevalere sulla tabella principale. Eseguili mentre sei connesso e di nuovo dopo una riconnessione, perché un rinnovo della concessione può cambiare la risposta.

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

Leggi l'output cercando due cose: l'interfaccia nominata nella rotta e l'indirizzo di origine scelto. Una rotta del tunnel nomina il dispositivo del tunnel, una rotta che perde nomina quello fisico, e la differenza è visibile senza decifrare nulla. Se la risposta cambia tra un'esecuzione e l'altra, conserva entrambi gli output e confronta le regole che li hanno prodotti.

Non fermarti alla rotta predefinita. Un'eccezione applicativa, un prefisso di tunnel diviso o una seconda regola di policy possono portare una destinazione specifica attorno al tunnel mentre la predefinita punta ancora dentro.

Decidi dove deve vivere l'applicazione

Tre condizioni decidono se l'applicazione lato client basta o se serve qualcosa fuori. Se il client installa e difende rotte per ogni famiglia di indirizzi che usi, un tunnel che possiede la rotta predefinita di solito è sufficiente. Se la macchina deve raggiungere risorse locali mentre tutto il resto resta nel tunnel, quelle eccezioni vanno elencate e possedute invece di lasciarle a ciò che la rete di accesso ha annunciato. E se la piattaforma può legare il traffico a un'interfaccia per applicazione, quel legame è una garanzia più forte di una rotta che qualunque cosa può prevalere.

Qualunque cosa scegli, scrivi la decisione dove vive la configurazione. Una regola che esiste perché qualcuno l'ha digitata durante un incidente non sopravviverà al prossimo riavvio, quindi tieni strette le eccezioni locali e quelle di avvio e annota perché ciascuna esiste.

Riesegui i comandi di ricerca dopo ogni aggiornamento del client e ogni cambio di rete, e confronta con l'ultimo output registrato. La tabella di routing è il confine dell'applicazione, quindi trattala come tale.