¿Qué dirección va en el DNS para un servidor conectado por VPN?
Un servidor alojado tiene tres direcciones y no son intercambiables. Elige el valor que cada servicio necesita y confírmalo después desde fuera de la máquina.
Un servidor alojado con un VPN instalado acaba teniendo tres direcciones, y solo una de ellas corresponde a cada sitio que estás a punto de configurar. Copiar el número de un panel del proveedor al DNS, a un escucha o a una lista de permitidos es la forma en que un túnel que funcionaba se convierte en un servicio que nadie puede alcanzar. Esta guía ordena el trabajo para que cada dirección se elija con un propósito declarado. También enumera los comandos que confirman lo que realmente publicaste.
Traza las tres direcciones antes de publicar nada
Nómbralas por función. La dirección de capa inferior es la que usa la máquina para alcanzar el extremo del VPN a través de internet, y a menudo es privada detrás del NAT del proveedor. La dirección de túnel vive dentro del VPN y la entrega el servidor o el cliente según el producto. La salida pública es la dirección que registra un sitio web remoto tras la traducción, y no necesita existir en ninguna interfaz que puedas consultar.
Un panel que muestra una dirección pública para una máquina te dice muy poco sobre los otros dos roles. La alcanzabilidad de la capa inferior es un requisito, no una compra: un portátil detrás de un router doméstico puede alcanzar un extremo VPN alojado sin poseer una dirección IPv4 pública. Lo que no puedes hacer es inventar una ruta de entrada escribiendo un nombre que resuelve a una dirección que nadie reenvía.
Elige la dirección por el servicio, no por la etiqueta
Anota lo que el servidor debe hacer antes de elegir un número. Las llamadas salientes a la API necesitan una salida estable cuando el otro lado mantiene una lista de permitidos. El acceso privado necesita una dirección de túnel a la que los clientes puedan enrutar y un escucha vinculado a ella. El alojamiento público necesita una correspondencia de entrada que el proveedor ofrezca de verdad, y la dirección de salida por sí sola no la aporta.
Una sola máquina puede servir los tres propósitos y aun así usar tres direcciones distintas. Lo que se rompe es la suposición de que un valor las cubre todas:
| 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 fila de entrada es la que la gente discute. Un registro que apunta a la dirección de salida no crea escucha, ni apertura de cortafuegos, ni redirección de puerto, y esperar no cambia eso. Cuando el proveedor vende una dirección dedicada junto con una regla de entrada, ese paquete es la capacidad que compraste; la dirección por sí sola no es el derecho.
Comandos que muestran qué dirección es cuál
Lee la máquina, no el panel. Los nombres de interfaz difieren entre sistemas, así que asocia las direcciones a los dispositivos en lugar de fiarte de una etiqueta.
La primera línea enumera cada dirección IPv4 y su dispositivo, y la segunda pregunta al núcleo qué dispositivo usaría para un destino externo conocido:
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)'Si la consulta de ruta responde con un dispositivo de túnel para el tráfico público, tu túnel completo está en vigor. La comprobación del escucha importa igual, porque un proceso vinculado solo a 127.0.0.1 nunca responderá en la dirección de túnel, publiques el nombre que publiques.
Publícala y luego verifica desde fuera
Publica el valor que el servicio necesita y nada más: un registro A o AAAA para el alojamiento, una entrada en la lista de permitidos para las llamadas salientes, un perfil de cliente para el acceso privado. Después prueba desde la posición que importa, y esa nunca es la máquina que acabas de editar.
Dos comprobaciones cubren casi todo, y ambas son lo bastante baratas para mantenerlas en un script:
dig +short vpn.example.net A
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/healthUna respuesta DNS que demuestra que tu registro existe no es prueba de que llegue una petición, y una petición correcta solo demuestra que una ruta funciona desde una red. Repite la comprobación desde una conexión móvil cuando haya una lista de permitidos de por medio, porque la salida que observas puede depender de la familia de direcciones y de la ruta tomada. Anota qué familia verificaste; una ruta IPv4 que funciona no dice absolutamente nada sobre IPv6.
Si el servicio es de entrada, la dirección de salida no basta
El acceso de entrada necesita cuatro cosas alineadas: un nombre o una dirección que un cliente pueda alcanzar, una ruta que entregue el paquete a la máquina, un escucha que lo acepte y una política que no lo descarte. Un VPN cambia el segundo elemento y a veces el primero, y no hace nada por el tercero y el cuarto. Cuando el túnel es la vía de entrega, los clientes se conectan a la dirección de túnel, no a la salida.
Anota de qué dirección depende cada servicio y revisa esa nota cada vez que el proveedor cambie su modelo de enrutamiento. Un servidor que responde en privado y falla en público normalmente no está roto; está respondiendo con la identidad equivocada, y la reparación es una decisión de correspondencia y no un cambio de cortafuegos.