OpenVPN sulla porta 53: tre conversazioni che si confondono
La risoluzione dell’endpoint, il trasporto cifrato e il DNS dopo il tunnel sono tre conversazioni. Individua quale fase ha fallito prima di cambiare porta o resolver.
I resoconti che dicono che la VPN è bloccata sulla porta 53 mescolano tre osservazioni che falliscono per motivi diversi. La risoluzione del nome dell’endpoint avviene prima che esista un tunnel, il trasporto cifrato è una conversazione separata e le query DNS effettuate dopo sono la terza. Ognuna ha la propria firma di guasto, e solo una di esse riguarda il DNS.
Ordina i pacchetti per scopo prima di cambiare qualsiasi cosa, perché la correzione segue la fase.
Tre conversazioni, un numero di porta
La prima conversazione è una ricerca di nome per l’endpoint: la tua macchina chiede al resolver configurato dove si trova vpn.example.com, e quella risposta arriva via DNS ordinario prima che il client invii un solo pacchetto di tunnel. La seconda è il trasporto OpenVPN stesso, che si connette all’indirizzo prodotto dalla ricerca sul protocollo e sulla porta indicati dal profilo. La terza avviene dopo che il tunnel è attivo, quando le applicazioni chiedono nomi e le impostazioni del resolver inviate decidono chi risponde.
Queste tre possono riuscire o fallire in modo indipendente. Un client può risolvere perfettamente il proprio endpoint e comunque non raggiungere il listener, e può stabilire un tunnel mentre ogni ricerca di nomi interni fallisce perché le impostazioni DNS non sono mai arrivate.
| Conversation | When it happens | What has to be true |
|---|---|---|
| Endpoint lookup | Before the client contacts a hostname | An underlying resolver path can answer for the endpoint name |
| OpenVPN transport | During tunnel establishment | The gateway listens on its configured transport, address and port, and nothing filters it |
| Application DNS | During or after the protected session | A resolver the client can reach, plus routing that carries its queries |
Leggi la tabella come una lista di controllo, non come una descrizione. Se il nome dell’endpoint non si risolve, nulla di successivo può funzionare, e il tunnel non parte mai.
Il numero di porta non dà un nome all’applicazione
La porta 53 trasporta DNS per convenzione, e un operatore OpenVPN può anche pubblicarvi un listener, ed è proprio per questo che il numero è un cattivo identificatore. Una sessione OpenVPN su UDP 53 è ancora una sessione OpenVPN, e una query DNS a un server sulla porta 53 non dice nulla sul fatto che un tunnel sia consentito. Le righe proto e remote del profilo definiscono l’endpoint esterno; il numero di porta non definisce nulla da solo.
Questo taglia in entrambe le direzioni in fase di diagnosi: una sonda UDP generica verso la porta 53 dimostra che una porta risponde, non che risponde il servizio VPN. Prova con il client reale e il profilo reale, perché solo così si esercita la stretta di mano che il servizio si aspetta.
Dimostra il listener prima di dare la colpa alla rete
Sul server, verifica cosa è in ascolto con ss -lunp | grep 53 e confrontalo con il protocollo e la porta del profilo. Dalla rete del client, esegui il client con maggiore verbosità in modo che il registro mostri quale indirizzo e trasporto ha tentato. Se il server è in ascolto e i pacchetti del client non arrivano, è il percorso o la policy a rifiutarli, e quella è una conversazione con il proprietario della rete, non un motivo per cambiare porta.
Una porta diversa aiuta solo quando il servizio è davvero in ascolto lì e la distribuzione lo consente. Spostare un listener per evitare il filtraggio di una rete gestita è una decisione di policy, non un passo di risoluzione dei problemi. Chiedi al proprietario della rete cosa è consentito prima di cambiare il servizio, perché una soluzione alternativa che viola la policy viene comunque chiusa più tardi. Annota quella risposta accanto al profilo, così la prossima persona non ripeterà la richiesta.
Controlla il DNS dopo il tunnel, separatamente
Una volta che il tunnel è attivo, ispeziona lo stato del resolver sull’interfaccia VPN e interroga un nome interno e un nome pubblico. Se i nomi interni falliscono mentre il tunnel trasporta traffico, le impostazioni DNS inviate non sono state applicate, il che è una questione di integrazione del client e non di trasporto. Se i nomi pubblici falliscono e quelli interni funzionano, la policy del tunnel diviso sta facendo ciò per cui è stata configurata.
Lascia le modifiche DNS al proprietario del resolver. Sovrascrivere una configurazione del resolver gestita per far passare un test può rompere i nomi privati per tutto il resto della macchina. Se il tunnel invia un resolver e il client lo ignora, correggi l’integrazione del client invece di aggiungere una voce statica altrove. Le voci statiche nascondono il guasto finché qualcuno non cambia rete. Annota quale resolver dovrebbe rispondere a ciascun namespace.