La documentazione del tunnel diviso richiede una regola DNS accanto a ogni rotta
Una rotta decide per indirizzo, un resolver decide per nome. Documentate entrambi i selettori per flusso, ciascuno con un test, altrimenti la nota fallisce quando il DNS si sposta.
Una nota sul tunnel diviso che dice «il traffico dell'ufficio passa per la VPN» ha documentato una decisione e ne ha implicite altre tre. A livello di pacchetti, una tabella di instradamento sceglie un'interfaccia in base all'indirizzo di destinazione; a livello di nomi, un resolver sceglie un server in base alla query, e le due scelte vengono fatte in modo indipendente. Per questo un prefisso documentato correttamente può ancora produrre una macchina che risolve un nome interno in un indirizzo pubblico, o che non risolve nulla mentre la rotta sembra perfetta.
Due selettori, un tentativo di connessione
Quando un'applicazione si connette a files.corp.example, avvengono due ricerche prima che esista un pacchetto. Il resolver decide quale server riceve la query, usando domini di ricerca, domini di instradamento per collegamento o una regola esplicita di profilo. La tabella di instradamento decide poi dove va l'indirizzo risultante, usando la corrispondenza di prefisso più lunga con la destinazione.
Niente collega queste due decisioni. Una zona privata può rispondere con 10.20.4.11 mentre la tabella di instradamento invia 10.20.0.0/16 nel tunnel, e la connessione funziona. Invertite una delle due e fallisce in un modo che sembra l'altra: una politica DNS corretta più una rotta mancante dà un nome risolto e un timeout, mentre una rotta corretta più un resolver pubblico dà un indirizzo che si instrada pulitamente nel posto sbagliato.
Il DNS a orizzonte diviso rende tutto più netto. Lo stesso nome può restituire un indirizzo privato dal resolver interno e uno pubblico da quello rivolto a Internet, quindi una nota che registra solo il prefisso non può prevedere quale indirizzo userà davvero il client. Scrivete il percorso del resolver, altrimenti l'indirizzo è una supposizione.
Cosa omette una nota solo sulla rotta
Un record solo sulla rotta è inutile per il guasto più comune del tunnel diviso: i nomi. L'utente segnala che l'intranet non si carica, il tunnel è attivo e il prefisso è presente. Chi prende il ticket non ha alcun record di quale resolver avrebbe dovuto rispondere, nessun modo di distinguere un suffisso di ricerca errato da un server bloccato e nessuna base di confronto.
La seconda omissione è l'elenco delle eccezioni. Un progetto di tunnel diviso è definito tanto da ciò che resta fuori dal tunnel quanto da ciò che vi entra, e gli intervalli esclusi sono di solito i primi a rompersi, perché una rotta locale più specifica o un filtro lato client possono annullare l'intento senza toccare il profilo.
La terza è il lato remoto del tunnel. Una rotta del client mette solo il pacchetto sul filo; il gateway deve ancora inoltrarlo e avere un percorso di ritorno. La guida all'inoltro di strongSwan ricorda che le regole di inoltro e firewall sul gateway fanno parte della funzionalità, non dell'idraulica che si può dare per scontata.
I campi che rendono la nota eseguibile
Una riga per flusso, e un flusso è una destinazione più un nome più un proprietario. Questi sono i campi che sopravvivono al contatto con un incidente reale:
| Field | Why it has to be written down |
|---|---|
| Destination prefix and address family | The route is per family; an IPv4 note says nothing about a AAAA answer |
| Selected tunnel or direct path | Names the decision, not the symptom |
| Private namespace and resolver | Which domain, which server, which search suffix |
| Public name path | Confirms public names do not accidentally use the private resolver |
| Where the rule lives | Client profile, server push, OS policy or management tool |
| Owner and review date | Namespaces change owner more often than routes change |
La riga "dove vive" è quella che la gente salta. Un prefisso spinto dal server, una rotta aggiunta da un profilo client e una rotta digitata in una shell differiscono per chi può modificarle e per se sopravvivono a una riconnessione. Senza quel campo, l'ingegnere successivo non può dire quale delle tre sta guardando.
Un test per regola, non uno per tunnel
Ogni riga richiede due controlli innocui: uno che esercita la rotta e uno che esercita il nome. Per la rotta, richiedete qualcosa che deve attraversare il tunnel e confermate il percorso invece della raggiungibilità, per esempio tracert -d 10.20.4.11 su Windows o ip route get 10.20.4.11 su Linux. Per il nome, interrogate il nome privato e registrate quale server ha risposto, usando resolvectl query files.corp.example o dig files.corp.example contro il resolver che la nota nomina.
Aggiungete anche un'aspettativa negativa: cosa dovrebbe succedere quando il tunnel è inattivo. Un'applicazione esclusa su un dispositivo Android o iOS con il blocco senza VPN attivo potrebbe non avere alcuna connettività, e un client desktop può lasciare la stessa applicazione funzionante mentre il tunnel si riconnette. Registrare la risposta prevista trasforma «la VPN ha rotto la mia applicazione» in un'affermazione verificabile.
Tenete il record con la configurazione
Archiviate la nota accanto al profilo che descrive e versionatela con quel profilo. Un documento su un wiki che nessuno aggiorna è una voce; una tabella nello stesso repository delle rotte spinte e della politica del resolver può essere rivista nella stessa modifica.
Quando qualcosa si rompe, confrontate la rotta applicata e il resolver effettivo con il record prima di aggiungere un'altra eccezione. Due delle tre cause comuni — una vecchia regola di spazio dei nomi e un processo ausiliario fuori dalla politica dell'applicazione — sembrano esattamente un guasto VPN e sono invisibili se la nota elenca solo prefissi.
Prima di dichiarare la nota finita, confermate che risponda per iscritto a questo: quale prefisso, per quale famiglia di indirizzi; quale spazio dei nomi privato, risposto da quale resolver; quali nomi restano deliberatamente pubblici; dove è configurata ogni regola e chi la possiede; e l'unico comando che dimostra la rotta e quello che dimostra il nome. Se manca qualcuno di questi, il prossimo incidente sarà diagnosticato da zero.