DNS su AWS Client VPN: usa il resolver del VPC, non la subnet

L’endpoint si trova in 10.0.8.0/24, quindi il resolver deve essere 10.0.8.2. È il ragionamento che sento più spesso, ed è sbagliato due volte. Route 53 Resolver risponde sull’intervallo IPv4 principale del VPC più due, che per un VPC di 10.0.0.0/16 è 10.0.0.2, qualunque subnet usi l’endpoint. Il secondo errore è più silenzioso: mettere l’indirizzo corretto nell’endpoint non significa che il sistema operativo del client glielo chieda mai. Entrambi gli errori producono lo stesso sintomo: la risoluzione dei nomi funziona per alcuni client e fallisce per altri.

Il mito inizia dall’associazione della subnet

L’associazione riguarda dove vivono le interfacce di rete elastiche delle connessioni client, non quale indirizzo di resolver esista. Le subnet dell’endpoint danno ai client un indirizzo dentro il VPC, e nessuna porta un resolver proprio.

Una volta separate queste due idee, l’aritmetica smette di essere misteriosa e la diagnosi passa al client, dove la maggior parte di questi casi finisce davvero.

Calcola l’indirizzo dall’intervallo principale del VPC

Prendi il CIDR IPv4 principale del VPC e aggiungi due all’indirizzo di rete. 10.0.0.0/16 dà 10.0.0.2, 172.31.0.0/16 dà 172.31.0.2, e un VPC con un intervallo secondario mantiene il resolver su quello principale. Una subnet di 10.0.8.0/24 dentro quel VPC non lo sposta. Annota l’indirizzo accanto all’ID del VPC prima di toccare l’endpoint, perché il numero è una proprietà del VPC e non della connessione.

Il VPC risponde anche sull’indirizzo link-local 169.254.169.253. Quell’indirizzo è raggiungibile dall’interno del VPC, ma non è una destinazione instradata generica per un portatile all’altro capo di un tunnel.

Quindi ci sono due indirizzi di resolver validi, e nessuno dei due è la subnet più due.

Cosa fa e cosa non fa l’impostazione dell’endpoint

L’endpoint Client VPN ha campi per il server DNS, e dove la console offre un’opzione resolver del VPC inserisce la stessa idea. Impostarli cambia ciò che il servizio consegna ai client durante l’instaurazione della connessione. Non cambia ciò che un client OpenVPN non gestito fa con quel valore, perché il client deve comunque applicarlo al sistema operativo. Da questo divario nasce «funziona sul mio Mac ma non sulla macchina Linux».

Su Linux l’integrazione del resolver è del gestore delle connessioni e non dell’utente. Modificare /etc/resolv.conf a mano dimostra che l’indirizzo funziona per una sessione e poi svanisce alla riconnessione: ecco perché tanti casi risolti tornano la mattina dopo.

Controlla il resolver attivo sul client dopo la connessione, non la pagina di configurazione dell’endpoint.

Il tunneling diviso può annullare un resolver corretto

Con il tunneling diviso si usano solo le rotte spinte nel tunnel. Se l’indirizzo del resolver non è coperto da una rotta, la query esce dall’interfaccia locale e risponde il router di casa. L’indirizzo nell’endpoint resta corretto e la risoluzione continua a fallire. Aggiungi la rotta per il resolver, poi prova di nuovo.

Intervalli locali sovrapposti danno lo stesso risultato in modo più fastidioso: la query riceve risposta, ma dal server sbagliato.

Non aprire i security group per l’indirizzo Amazon DNS

L’istinto, quando le risoluzioni vanno in timeout, è aggiungere una regola che consenta UDP 53 verso l’indirizzo del resolver. AWS documenta che i security group e le ACL di rete non filtrano il traffico Amazon DNS come filtrano il traffico verso un’istanza DNS propria. Aprire quelle regole non cambia nulla per il resolver del VPC e allarga il perimetro senza motivo. Un resolver che gestisci tu è un altro caso e ha davvero bisogno delle sue regole.

Se entrambi compaiono nel tuo progetto, controlla verso quale il client punta davvero prima di modificare qualsiasi regola.

Verifica il percorso, poi misura qualcos’altro

Risolvi un nome pubblico, risolvi un nome privato registrato in una zona ospitata privata associata al VPC, e leggi tra i due il resolver attivo del client. Quella sequenza separa «l’indirizzo del resolver è sbagliato» da «la zona non è associata» e da «il client ha ignorato l’impostazione». Ognuno ha una correzione diversa, e nessuno è un problema di throughput.

Una risoluzione riuscita non dice nulla sulla velocità di trasferimento sostenuta, quindi tieni separate queste due conversazioni quando riferisci.