Verificare che un tunnel diviso funzioni: un solo risultato IP non è un test

Una sola pagina del browser che mostra un indirizzo IP non dimostra quasi nulla di un tunnel diviso. Un indirizzo visibile può essere quello giusto per il motivo sbagliato, e un flusso escluso non viene mai esercitato da essa. Annotate il risultato atteso prima di testare: quale applicazione o destinazione deve usare il tunnel, quale deve restare diretta e che cosa deve fermarsi quando il tunnel fallisce. Senza quel piano, qualsiasi numero plausibile sembra un successo.

Il mito: una ricerca dell'indirizzo dimostra la copertura

Il controllo dell'IP risponde a una domanda: che cosa vede il mondo esterno da un'applicazione in un dato momento. Non dice nulla su un prefisso interno, su un secondo profilo del browser o su un nome che dovrebbe essere risolto in privato. Non dice nulla nemmeno sul guasto, e questa è la metà di un progetto di tunnel diviso che si rompe in produzione.

Una pagina dell'indirizzo non può mostrare nemmeno la rotta, il resolver o la politica di guasto. Trattatela come una singola osservazione, non come un verdetto.

Esercitate un flusso incluso e uno escluso

Inviate una richiesta innocua dall'applicazione che dovrebbe essere inclusa, o verso il prefisso che vi aspettate venga instradato dal tunnel, e registrate l'origine, la destinazione, la famiglia di indirizzi e il percorso osservato. Fate lo stesso per un flusso che deve restare diretto. Il lato escluso è quello che la gente salta, ed è l'unica prova che la divisione è voluta e non accidentale. Un processo ausiliario può portare un'identità di policy separata, quindi testate nel processo che possiede il socket.

flow: Firefox to intranet.example:443, IPv4, source 10.8.0.6, tunneled
flow: Firefox to 1.1.1.1, IPv4, source 192.0.2.20, direct

Per questo un test eseguito nell'applicazione sbagliata può mostrare l'opposto di ciò che il progetto intende. Annotate i quattro campi per entrambi i lati prima di trarre qualsiasi conclusione.

Aggiungete il DNS e il caso di guasto

Interrogate il resolver di sistema e il resolver usato dall'app, poi confrontate quelle risposte con l'indirizzo di uscita riportato dal sito. I due livelli possono divergere per progetto, e una singola ricerca del browser non esercita la policy del sistema operativo. Una shell rende il confronto ripetibile: Spezzate il tunnel di proposito, poi fate una richiesta che il browser non ha in cache; una pagina servita dalla cache non vi dice nulla su quale direzione abbia preso il ripiego. Registrate ciò che è realmente accaduto invece di ciò che il progetto prevedeva.

curl -s https://ifconfig.me
nslookup intranet.example

Un tunnel diviso che fallisce chiuso e uno che fallisce aperto sembrano identici finché non spezzate il tunnel di proposito. Registrate il comportamento che avete osservato, non quello che vi aspettavate.

Ripetete dopo il cambio di stato

Ripetete le stesse osservazioni dopo una riconnessione, un cambio di rete e un aggiornamento applicativo rilevante. Un'esclusione memorizzata può continuare a puntare a un percorso o a un'identità applicativa che non esiste più, e il progetto smette silenziosamente di corrispondere alla sua documentazione. Quei tre eventi sono dove i tunnel divisi vanno alla deriva, e ciascuno è economico da ritestare. Un test che gira una volta sola al rilascio descrive una configurazione che non esiste più.

Se un risultato differisce, trovate il proprietario della regola e la fase di elaborazione prima di cambiare più impostazioni insieme. Cambiare cinque cose e osservare un risultato non è una diagnosi, è una nuova configurazione.

Che cosa deve stabilire il risultato

Collegate le osservazioni alla policy e alla versione del client che avete realmente testato. L'obiettivo è mostrare che questo rilascio corrisponde alla copertura che dichiara, non che ogni futura applicazione sarà privata. È un'affermazione più stretta, ed è quella che potete davvero sostenere con prove. Scrivete l'affermazione, la versione e i risultati a quattro campi nel registro delle modifiche.

Così il revisore successivo può capire se è cambiato il progetto o il test. Un tunnel diviso è verificato quando entrambi i lati, la separazione del resolver e il comportamento in caso di guasto corrispondono a ciò che avete annotato all'inizio. Un solo risultato IP non ne verifica nessuno.