DNS dell'endpoint AWS Client VPN: perché fissare l'IP risolto non funziona

La settimana scorsa dig +short ti ha dato un indirizzo per il nome dell'endpoint nel tuo profilo AWS Client VPN, e il tunnel si è connesso. Questa settimana lo stesso profilo resta su 'Connecting' sul tuo portatile mentre la copia intatta di un collega funziona ancora. Nulla è stato bloccato e il certificato non è scaduto. Qualcuno ha sostituito il nome host dell'endpoint con quell'indirizzo risolto, e il servizio non risponde più lì. Il nome esportato è la parte costruita per sopravvivere a quel cambiamento.

Il nome nel tuo profilo potrebbe non essere il nome interrogato

I profili esportati da Client VPN contengono spesso remote-random-hostname. Con quell'opzione attiva, il client costruisce un'etichetta usa e getta, la unisce al nome dell'endpoint con un punto e risolve il nome combinato. Un record wildcard nella zona dell'endpoint risponde a qualsiasi etichetta, per questo un prefisso inventato si risolve ancora e per questo il trucco resta invisibile quando provi a riprodurre la query a mano.

Quindi, quando incolli il nome dell'endpoint in un terminale e ottieni una risposta, hai risolto un nome diverso da quello che il client usa al momento della connessione. Questa discrepanza non è un difetto da correggere nel profilo. L'etichetta viene rigenerata di proposito: l'opzione impedisce alle cache di conservare una risposta obsoleta e non identifica mai la tua macchina né la tua sessione.

Ho incontrato il caso di compatibilità in cui un client ignora del tutto l'opzione. AWS documenta la soluzione: conserva il nome reale dell'endpoint e anteponi una stringa casuale più un punto, trattandolo come uno schema di denominazione e non come un valore da incollare. Applicarlo a un client vecchio è ragionevole; codificare la stringa con prefisso come endpoint non lo è.

Perché una risposta salvata non può restare corretta

Gli indirizzi dell'endpoint di Client VPN sono gestiti da AWS e cambiano nel tempo, come dice chiaramente la documentazione sulle best practice. Una risposta catturata è un'istantanea di una risoluzione. Un profilo che la codifica diventa un profilo puntato a un host dismesso appena il servizio si sposta, e il guasto raramente sembra DNS: ottieni un timeout di connessione o un handshake bloccato, così le persone inseguono routing e certificati.

La stessa risposta in /etc/hosts eredita la stessa scadenza con un problema in più. Una voce hosts sopravvive a riavvii, riesportazioni e correzioni 'reinstalla il client', quindi il guasto torna ogni volta che l'indirizzo si sposta. Ne ho visto uno restare innocuo per settimane, poi mettere fuori uso ogni macchina che lo portava mentre le installazioni nuove si connettevano normalmente. Quella divisione, un gruppo che fallisce e un altro a posto sullo stesso account, è l'indizio più economico che otterrai.

Delimita correttamente la randomizzazione. Avviene per singolo tentativo di connessione. Un tunnel stabilito non risolve di nuovo il suo endpoint, non cambia server a metà sessione, e le singole richieste delle applicazioni non scelgono ciascuna un nuovo host VPN. Solo il tentativo successivo risolve di nuovo, per questo una sessione che funziona tutto il pomeriggio non dice nulla sul domani mattina.

Che cosa controlla il servizio quando il tunnel sale

Client VPN richiede che l'indirizzo a cui sei connesso corrisponda a un indirizzo risolto per il nome DNS dell'endpoint. Questo unico requisito spiega diversi guasti che sembrano scollegati: un record DNS personalizzato che punta altrove, un frontend personalizzato che inoltra all'indirizzo reale dell'endpoint e un profilo riscritto su un indirizzo grezzo. AWS documenta la combinazione record personalizzato più inoltro come un guasto con i client AWS recenti. Il controllo è ristretto; non è una sentenza che ogni alias sia vietato.

Non è nemmeno una regola generale sui protocolli VPN. Un remote numerico è del tutto valido in un normale deployment OpenVPN, e molti funzionano così. Il vincolo viene dall'assetto gestito, non dal protocollo sottostante.

Il che rende l'allentamento della verifica del certificato il riflesso sbagliato. Se un profilo fallisce dopo un cambio di indirizzo, disattivare la verifica del server sposta l'errore invece di correggere la risoluzione o il requisito di corrispondenza dell'indirizzo, e lascia un client che si fiderà di qualsiasi cosa. Mantieni la CA esportata, la verifica del server e le impostazioni di autenticazione reciproca esattamente come sono arrivate.

Liste di autorizzazione, uscita e DNS privato sono tre problemi distinti

Una regola del firewall che deve consentire una destinazione prima che un portatile si connetta riguarda il listener esterno. Dai al proprietario della rete il nome dell'endpoint, il trasporto e la porta configurata, poi chiedi se il loro controllo può seguire il comportamento DNS del servizio. Una regola che trattiene un indirizzo catturato è un'istantanea con una scadenza non scritta. Se il controllo accetta solo destinazioni immutabili, risolvi quel divario prima del rilascio invece di codificare una risposta in silenzio.

Un partner che ha bisogno di un indirizzo sorgente fisso per le richieste fatte dopo l'apertura del tunnel ha un altro requisito: l'uscita. Ciò che un sito web osserva dipende dalla rotta dell'applicazione e dalla politica di split tunnel, non dall'indirizzo a cui si è connesso il client. Il traffico in split tunnel potrebbe non toccare mai AWS.

Il DNS privato dentro il tunnel è un terzo livello. Il resolver fornito ai client risponde ai nomi interni dopo la connessione; non può risolvere l'endpoint pubblico prima che il tunnel esista. Il guasto di risoluzione dell'endpoint e quello di risoluzione di un'applicazione interna avvengono in fasi diverse, e mescolarli ti manda al log sbagliato.

La famiglia di indirizzi appartiene alla stessa lista. Una risposta IPv4 non dice nulla sul percorso consentito di un endpoint IPv6 o dual stack, quindi un'istantanea presa in una famiglia non è una prova per l'altra.

Verifica una connessione senza fissare nulla

Parti dal profilo così com'è esportato e leggi che cosa chiede davvero:

grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'

Poi confronta tre cose: il nome dell'endpoint che il profilo contiene, l'indirizzo che il client riporta per un nuovo tentativo e ciò a cui il nome si risolve adesso. Un nome che si risolve prova solo che il record risponde; trasporto e autenticazione sono separati, e l'endpoint non deve rispondere a un ping. Il log del client è l'unica fonte per l'elemento centrale, quindi catturalo durante il tentativo e non dopo.

Un indirizzo che risponde oggi è una prova su oggi; il nome è ciò che il servizio mantiene valido. Annota l'osservazione, inviala a chi possiede l'endpoint e lascia il profilo puntato al nome.

Due abitudini da abbandonare: disattivare i controlli dei certificati per superare un handshake bloccato, e impilare etichette davanti al nome dell'endpoint sperando che una tenga. Un'etichetta si risolve tramite il record wildcard, altrimenti il problema è altrove. Se un profilo configurato correttamente fallisce ancora, invia la query esatta e l'evento di connessione, non un nome host più lungo.

Prima di chiudere: il profilo porta ancora il nome esportato dell'endpoint, nessun file hosts fissa l'indirizzo, il remote nel log del client corrisponde a una risoluzione attuale e la regola del firewall nomina l'endpoint invece di un indirizzo. È anche lo stato da consegnare alla persona successiva.