Quale indirizzo va nel DNS per un server connesso tramite VPN?
Un server ospitato detiene tre indirizzi e non sono intercambiabili. Scegli il valore che serve a ciascun servizio, poi confermalo dall’esterno della macchina.
Un server ospitato con una VPN installata finisce per detenere tre indirizzi, e solo uno di essi ha il suo posto in ogni punto che stai per configurare. Copiare il numero da un pannello del provider nel DNS, in un listener o in una allowlist è il modo in cui un tunnel funzionante diventa un servizio che nessuno riesce a raggiungere. Questa guida ordina il lavoro perché ogni indirizzo sia scelto per uno scopo dichiarato. Elenca anche i comandi che confermano ciò che hai realmente pubblicato.
Mappa i tre indirizzi prima di pubblicare qualsiasi cosa
Chiamali per funzione. L’indirizzo di underlay è quello che la macchina usa per raggiungere l’endpoint VPN attraverso internet, ed è spesso privato dietro il NAT del provider. L’indirizzo di tunnel vive dentro la VPN, assegnato dal server o dal client a seconda del prodotto. L’uscita pubblica è l’indirizzo che un sito remoto registra dopo la traduzione, e non deve esistere su nessuna interfaccia che tu possa interrogare.
Un pannello che mostra un solo indirizzo pubblico per una macchina ti dice molto poco sugli altri due ruoli. La raggiungibilità dell’underlay è un requisito, non un acquisto: un portatile dietro un router domestico può raggiungere un endpoint VPN ospitato senza possedere un indirizzo IPv4 pubblico. Quello che non puoi fare è inventare un percorso in ingresso scrivendo un nome che risolve verso un indirizzo che nessuno inoltra.
Scegli l’indirizzo in base al servizio, non all’etichetta
Annota cosa deve fare il server prima di scegliere un numero. Le chiamate API in uscita hanno bisogno di un’uscita stabile quando la controparte mantiene una allowlist. L’accesso privato ha bisogno di un indirizzo di tunnel verso cui i client possano instradare e di un listener legato a esso. L’hosting pubblico ha bisogno di una mappatura in ingresso che il provider offra davvero, e il solo indirizzo di uscita non la fornisce.
Una singola macchina può servire tutti e tre gli scopi e usare comunque tre indirizzi diversi. Quello che si rompe è l’assunzione che un valore li copra tutti:
| Requirement | Value that belongs there | What you see when the roles are swapped |
|---|---|---|
| Outbound allowlisting | Public exit | Requests reach the service but are rejected |
| Private client access | Tunnel address | Client connects, nothing answers |
| Inbound web service | Provider mapping | Name resolves, connection times out |
La riga in ingresso è quella su cui la gente discute. Un record che punta all’indirizzo di uscita non crea listener, né apertura del firewall, né mappatura di porta, e aspettare non cambia le cose. Quando il provider vende un indirizzo dedicato insieme a una regola in ingresso, quel pacchetto è la capacità che hai comprato; l’indirizzo da solo non è il diritto.
Comandi che mostrano quale indirizzo è quale
Leggi la macchina, non il pannello. I nomi delle interfacce cambiano tra sistemi, quindi abbina gli indirizzi ai dispositivi invece di fidarti di un’etichetta.
La prima riga elenca ogni indirizzo IPv4 e il suo dispositivo, e la seconda chiede al kernel quale dispositivo userebbe per una destinazione esterna nota:
ip -brief -4 addr show
ip -4 route get 198.51.100.10
curl -4 -s https://ifconfig.me
ss -lntp | grep -E ':(443|1194)'Se la ricerca di rotta risponde con un dispositivo di tunnel per il traffico pubblico, il tuo tunnel completo è in vigore. Il controllo del listener conta altrettanto, perché un processo legato solo a 127.0.0.1 non risponderà mai sull’indirizzo di tunnel, qualunque nome tu pubblichi.
Pubblicalo, poi verifica dall’esterno
Pubblica il valore che serve al servizio e nulla di più: un record A o AAAA per l’hosting, una voce della allowlist per le chiamate in uscita, un profilo client per l’accesso privato. Poi prova dalla posizione che conta, e quella non è mai la macchina che hai appena modificato.
Due verifiche coprono la maggior parte dei casi, ed entrambe sono abbastanza economiche da restare in uno script:
dig +short vpn.example.net A
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/healthUna risposta DNS che prova che il tuo record esiste non è prova che una richiesta arrivi, e una richiesta riuscita prova solo che un percorso funziona da una rete. Ripeti la verifica da una connessione mobile quando è coinvolta una allowlist, perché l’uscita che osservi può dipendere dalla famiglia di indirizzi e dalla rotta seguita. Annota quale famiglia hai verificato; un percorso IPv4 funzionante non dice assolutamente nulla su IPv6.
Se il servizio è in ingresso, l’indirizzo di uscita non basta
L’accesso in ingresso richiede quattro cose allineate: un nome o un indirizzo che un client possa raggiungere, una rotta che consegni il pacchetto alla macchina, un listener che lo accetti e una politica che non lo scarti. Una VPN cambia il secondo elemento e a volte il primo, e non fa nulla per il terzo e il quarto. Quando il tunnel è la via di consegna, i client si collegano all’indirizzo di tunnel, non all’uscita.
Registra da quale indirizzo dipende ogni servizio, poi rivedi quella nota ogni volta che il provider cambia il suo modello di routing. Un server che risponde in privato e fallisce in pubblico di solito non è rotto; sta rispondendo con l’identità sbagliata, e la riparazione è una decisione di mappatura e non una modifica al firewall.