DNS geografico e anycast: verificare l’ingresso VPN che si ottiene

Una risposta DNS vicina sembra un problema risolto finché la connessione non atterra altrove. Il DNS geografico e l’anycast cercano entrambi di accorciare il percorso, e prendono questa decisione da informazioni diverse. Nessuno dei due garantisce che il gateway raggiunto sia raggiungibile, che presenti l’identità attesa dal vostro client o che la vostra sessione sopravviva a un cambio di nodo. Le verifiche seguenti separano queste quattro domande.

Verificate di chi il resolutor riporta realmente la posizione

Un server autoritativo che risponde a una query sensibile alla topologia vede di norma l’indirizzo del resolutor ricorsivo che ha interrogato, non l’indirizzo della persona che ha digitato il nome. Un resolutor centralizzato può trovarsi lontano dai client che serve, e la risposta riflette il resolutor e non loro. Non è un difetto; è così che si comporta il protocollo salvo che siano fornite informazioni aggiuntive. Specifica di EDNS Client Subnet descrive sia la limitazione sia il rimedio opzionale.

EDNS Client Subnet può trasportare informazioni sulla rete di origine quando ogni partecipante lo supporta e lo abilita. È facoltativo, ha conseguenze sulla privacy e sulla cache, e non è il permesso di supporre che un resolutor pubblico riporti una posizione precisa dell’utente. Chiedete agli operatori dei resolutor prima di progettare su di esso.

dig +short vpn.example.com @1.1.1.1
dig +short vpn.example.com @9.9.9.9
dig +subnet=203.0.113.0/24 +short vpn.example.com

Verificate cosa ha deciso l’instradamento anycast

Con anycast, più località annunciano la raggiungibilità di un solo indirizzo di servizio, e la rete consegna ogni client al nodo che il suo instradamento preferisce. Questa scelta la fanno BGP e la politica circostante, non la distanza su una mappa. Anche la vicinanza topologica di solito non equivale a prestazioni migliori andata e ritorno, perché il percorso che sembra breve può essere congestionato o asimmetrico. L’indirizzo che avete ricevuto non dice nulla su quale nodo abbia risposto.

Confermate la località di servizio dal lato del servizio, o da una risposta che la nomina, e non solo dalla risposta DNS. traceroute -n 198.51.100.20 mostra il percorso seguito e continua a non nominare l’host alla sua estremità, quindi leggetelo come percorso e non come risposta.

Verificate che la sessione sopravviva a un cambio di nodo

Una query DNS è breve e una sessione VPN è lunga, e le due hanno requisiti di stato completamente diversi. L’instradamento può spostarsi a metà sessione, e quando succede i pacchetti successivi possono arrivare a un nodo che non ha mai visto il vostro tunnel. Se sia sopportabile dipende dall’implementazione: stato condiviso, una riconnessione deliberata o un guasto documentato. Il solo indirizzo non ne fornisce nessuno.

Osservate lo spostamento invece di presumerlo. sudo tcpdump -ni any -c 20 esp mostra i pacchetti esterni mentre il percorso cambia, e un cambiamento improvviso dell’indirizzo del peer è lo spostamento stesso. Definite esplicitamente il comportamento previsto per l’implementazione che gestite, poi provatelo forzando un cambio di percorso. Se il progetto presuppone la replica della sessione, nominate il meccanismo e nominate il guasto che non copre.

Verificate che l’identità corrisponda ancora

Ogni punto d’ingresso deve presentare l’identità attesa dal vostro profilo client. Un certificato emesso per il nome del servizio funziona su tutti i nodi, mentre i certificati per nodo obbligano il client ad accettare qualcosa di nuovo, ed è lì che gli utenti imparano a ignorare gli avvisi. Mantenete l’identità attesa e il profilo coerenti con il modello d’ingresso.

Verificatelo da un client che ha raggiunto un nodo insolito, perché è il caso in cui un certificato per nodo diventa visibile. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com stampa la catena e i nomi, ed è esattamente ciò che confronta il client. Poi decidete se restringere il profilo o cambiare il modello di certificato.

Verificate il registro, non solo la prima risposta

Valutate tre scenari e scrivete quattro fatti per ciascuno: ingresso normale, una località non disponibile e il caso di ripristino concordato. I quattro fatti sono il resolutor usato, l’indirizzo restituito, la località che ha servito e un risultato applicativo fresco. Quel registro separa un problema di selezione DNS da un problema di gateway, di instradamento o di stato della sessione. Senza di esso, tutti e quattro sembrano identici dal client.

dig +short vpn.example.com
getent hosts vpn.example.com
curl -s -o /dev/null -w "%{http_code}
" https://vpn.example.com/health

Eseguite gli scenari da reti di accesso rappresentative e non solo dall’ufficio, perché tutta la questione riguarda quale punto d’ingresso raggiungono realmente client diversi. Una rete è un campione di uno.