Nome dell’endpoint VPN contro nome di un servizio privato: due responsabili

Due nomi possono descrivere la stessa filiale e rispondere a domande completamente diverse. vpn.branch.example indica a un peer remoto dove trovare l’endpoint VPN, e deve essere risolto prima che esista qualsiasi tunnel. inventory.branch.example indica a un utente autorizzato dove vive un’applicazione privata, e conta solo quando il tunnel è attivo. Mantenere uno dei due non fa nulla per l’altro.

Nominate i due record prima di fare debug di uno dei due

Annotate entrambi con i loro responsabili. Per l’endpoint, registrate chi aggiorna l’indirizzo pubblico e come il client VPN aggiorna la propria risposta. Per il servizio, registrate chi possiede l’indirizzo privato, quale zona contiene il record e quali resolver dovrebbero rispondere per esso.

Questo breve elenco evita la diagnosi errata più comune in questo ambito: riavviare un tunnel di filiale funzionante per riparare un record che vive interamente al suo interno. Il tunnel è il trasporto per il nome del servizio; non ne è l’autorità.

Quando viene proposto un cambiamento, chiedete quale dei due record tocca. Se nessuno sa rispondere, il cambiamento non è pronto per la pianificazione.

L’endpoint deve essere risolto prima che esista qualsiasi tunnel

Supponete che la connessione internet della filiale riceva un nuovo indirizzo pubblico. L’aggiornatore dell’endpoint pubblica il nuovo indirizzo, e l’implementazione VPN remota deve poter leggere la risposta modificata. Qualunque resolver fornisca quella risposta deve essere raggiungibile senza il tunnel, altrimenti il client insegue un nome che può risolvere solo dopo essersi connesso a ciò che non riesce a trovare.

Vale la pena dire chiaramente questa dipendenza di avvio, perché è facile crearla per errore quando tutti i resolver interni stanno dietro la VPN. Mantenete un percorso pre-tunnel per la ricerca dell’endpoint e confermate il comportamento di riconnessione del client invece di dare per scontato che una nuova risposta venga raccolta subito.

Anche il DNS dinamico ha limiti che l’aggiornamento del record non può superare. Aggiornare un record non apre alcuna porta del firewall, non crea alcuna mappatura NAT e non dimostra alcuna identità del peer. Un indirizzo pubblicato con una porta chiusa produce un client che risolve correttamente e comunque non riesce a connettersi a nulla.

Infine, un client in esecuzione può continuare a usare un endpoint in cache finché non si riconnette. Separate pubblicazione, cache e politica di riconnessione nelle vostre note, così che un peer obsoleto non venga scambiato per un aggiornatore guasto.

Il nome del servizio descrive dove vive l’applicazione

Ora supponete che il tunnel resti sano ma che il server di inventario passi da 172.26.14.20 a 172.26.14.35. Il record pubblico dell’endpoint non è interessato, mentre il record privato del servizio deve cambiare. Usare un indirizzo riservato a quel servizio, o un’assegnazione statica, rende questo più raro; un percorso di aggiornamento autorizzato gestisce i casi in cui ciò è intenzionale.

Qui si confondono due meccanismi di aggiornamento. RFC 2136 definisce un protocollo per aggiungere ed eliminare record DNS in una zona, mentre un fornitore commerciale di DNS dinamico può esporre un’API HTTP completamente diversa per un altro scopo. Usarne uno non implica che l’altro esista nel vostro ambiente. Verificate quale meccanismo la vostra zona accetta davvero prima di scrivere un aggiornatore contro di esso.

Una risposta privata corretta è solo la prima condizione. Perché un chiamante remoto la usi, il client ha bisogno di un resolver che porti la zona privata, di una politica che consenta query verso quel resolver e di inoltro per l’indirizzo che ritorna. Un nome che risolve verso un indirizzo che il client non può raggiungere produce un timeout che sembra un guasto del server.

Provate i due percorsi separatamente

Controllate l’endpoint da fuori del tunnel e il servizio da dentro, e conservate i risultati come due fatti indipendenti:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

Se la prima query fallisce, il problema è la pubblicazione pubblica o il percorso di risoluzione pre-tunnel, e nessun cambiamento interno aiuterà. Se la seconda restituisce un indirizzo ma la terza non mostra alcuna rotta attraverso il tunnel, lo strato DNS è a posto e la politica di inoltro non lo è.

Eseguite la coppia dopo ogni cambio di indirizzo e annotate quale record si è spostato. Un passaggio di consegne che dice solo «il DNS è stato aggiornato» lascia l’ingegnere successivo a indovinare quale dei due cicli di vita sia stato davvero eseguito.