VPN annidata: quale tunnel trasporta la connessione esterna?

Due client VPN in esecuzione contemporaneamente non producono un tunnel annidato; producono due tunnel e una discussione sull’instradamento. Un tunnel annidato esiste quando la connessione del client interno al proprio server è essa stessa trasportata dal tunnel esterno, e questa è una configurazione che si costruisce di proposito. Se è fatta bene, il server interno vede l’indirizzo del server esterno; se è fatta male, un client si riconnette silenziosamente attorno all’altro. Tre condizioni decidono se l’annidamento è reale o accidentale.

Tre condizioni decidono l’annidamento

La prima è quale endpoint ha bisogno di quale percorso. Indica l’indirizzo del server interno, indica quello del server esterno e afferma esplicitamente che il server interno è raggiungibile solo attraverso il tunnel esterno. Tutto il resto discende da quella frase, comprese quali rotte stanno in quale tabella.

La seconda è se riesci a vedere il percorso a ogni livello. Se non puoi chiedere al kernel quale rotta userebbe una certa destinazione, stai deducendo la catena da un IP di uscita finale, ed è esattamente la prova che non sa distinguere un annidamento da una coincidenza.

La terza è che cosa succede quando il tunnel esterno cade. Il tunnel interno può fermarsi con lui, riconnettersi sulla rete ordinaria o restare bloccato finché il percorso esterno non torna, e tutte e tre sono politiche difendibili. Non sono la stessa politica, e il comportamento predefinito della maggior parte dei client è il secondo. Un client che riconnette il proprio endpoint sulla rete fisica mentre mostra una connessione sana è il modo più comune in cui una catena voluta diventa silenziosamente due tunnel scollegati.

Prima condizione: quale endpoint ha bisogno di quale percorso

ip route get 203.0.113.10 risponde direttamente a questa domanda: stampa la rotta, l’indirizzo sorgente e l’interfaccia che il kernel userebbe per quella destinazione in questo momento.

Eseguilo per il server interno prima che il client interno parta e di nuovo dopo, poi confronta. Se la risposta passa dall’interfaccia fisica all’interfaccia del tunnel esterno, l’annidamento è reale in quel momento. Se non cambia, il client interno si sta connettendo direttamente, qualunque cosa dica il pannello. Ripeti per l’indirizzo del server esterno, che deve ancora risolversi tramite l’interfaccia fisica, perché una rotta che cattura entrambi gli endpoint in modo ricorsivo è il guasto che toglie del tutto la macchina dalla rete.

Seconda condizione: ispeziona il percorso a ogni livello

La selezione della rotta è più della tabella principale su un client moderno. Le regole di policy possono mandare pacchetti marcati in un’altra tabella, un client può legare la propria socket a un’interfaccia, e un container o un namespace ha tabelle del tutto proprie. ip rule e ip route show table all sono il modo per scoprire quale di questi meccanismi è in gioco.

Un client che imposta SO_MARK sulla propria socket, o che è configurato per legarsi a un dispositivo specifico, aggira la rotta predefinita che pensavi di avere predisposto. È una funzionalità e non un difetto, e significa che l’unico controllo affidabile è quello che gira nello stesso namespace del client. Se i client girano in container, esegui i controlli dentro quei container invece che sull’host.

Terza condizione: che cosa succede quando il tunnel esterno cade

Il comportamento in caso di guasto richiede una decisione, non un valore predefinito. Scrivi che cosa deve succedere al tunnel interno quando quello esterno sparisce, poi fai in modo che i client lo facciano.

Le opzioni sono concrete. Fermare il client interno quando il percorso esterno sparisce dà una catena pulita e un’interruzione evidente. Lasciarlo riconnettere direttamente dà disponibilità e toglie silenziosamente la proprietà per cui la catena era stata costruita. Bloccare finché il percorso esterno non torna è la più rigorosa e la più fastidiosa da gestire, perché ogni oscillazione del tunnel esterno diventa un incidente visibile.

Prova tutte e tre con traffico innocuo e un guasto provocato del tunnel esterno, perché leggere la configurazione non ti dirà quale hai. Interrompi il tunnel esterno, osserva che cosa fa il client interno e ricontrolla la rotta mentre è giù. Poi riporta su il tunnel esterno e conferma che la catena si riformi invece di lasciare il client interno sul percorso diretto che ha scelto nel frattempo.

Che cosa la catena non ti dà

I livelli extra aggiungono endpoint, chiavi e modalità di guasto; non aggiungono alcuna garanzia di anonimato e non rendono l’operatore esterno incapace di vedere che esiste un tunnel. Qualsiasi affermazione su che cosa protegge l’annidamento deve nominare l’osservatore da cui protegge.

Il risultato è un documento breve e non una connessione funzionante: quale endpoint usa quale percorso, che cosa succede in caso di guasto esterno e i tre comandi che mostrano lo stato attuale. La documentazione di strongSwan sull’inoltro è un riferimento utile per come il traffico di tunnel viene inoltrato tra interfacce su un host Linux. Riesegui i controlli dopo ogni aggiornamento del client, perché i valori predefiniti che hanno prodotto la tua catena non sono un contratto. Un tunnel annidato che non puoi ispezionare è una voce con una spia di stato.