La mayoría de los problemas con una VPN se reducen a unas pocas causas, y revisarlas en el orden correcto te ahorra una tarde. Ejecuta los comandos en el servidor salvo que un paso diga otra cosa. Los ejemplos usan WireGuard en su puerto por defecto 51820/udp; para OpenVPN o Xray, sustituye el nombre del servicio y el puerto por los tuyos.
Última verificación 2026-11-13.
1. ¿Está el servidor en un plan con IPv4 propia?
Un cliente VPN se conecta hacia tu servidor. Un plan NAT solo deja entrar desde fuera un puerto, tu puerto SSH personal, así que ninguna VPN puede funcionar en él. Si el panel muestra una dirección con un puerto del tipo 20xxx, estás en NAT. Pasar a una IPv4 propia conserva tus datos y no requiere reinstalar; consulta Cambiar la dirección IP.
2. ¿Está el servicio en marcha?
systemctl status wg-quick@wg0
journalctl -u wg-quick@wg0 -n 30 --no-pager
En OpenVPN la unidad suele ser openvpn-server@server; en Xray, xray. Un servicio que no arrancó casi siempre indica el motivo en las últimas líneas de su registro: una errata en la configuración, un archivo de clave que falta, un puerto ya en uso.
3. ¿Escucha en el puerto que esperas?
ss -ulpn | grep 51820 # UDP: WireGuard, OpenVPN por UDP
ss -tlpn | grep 443 # TCP: Xray / VLESS, OpenVPN por TCP
Si no hay salida, el servicio no escucha ahí, diga lo que diga la configuración. Compara el puerto con el de tu cliente.
4. ¿Lo deja pasar el firewall?
ufw status verbose
Si el firewall está activo y tu puerto no aparece, ábrelo:
ufw allow 51820/udp
Fíjate en el protocolo: WireGuard necesita UDP, y una regla 51820/tcp no le sirve de nada. Deja tu regla de SSH en su sitio antes de activar o recargar el firewall, o te quedarás fuera. Si aun así ocurre, la consola del navegador en el panel te devuelve el acceso.
5. ¿Llega realmente el cliente al servidor?
En WireGuard te lo dice el handshake:
wg show
latest handshake: N seconds ago en un peer significa que el cliente llegó al servidor y que las claves coinciden. Si no hay ninguna línea de handshake, nunca llegó. Entonces revisa, en este orden: la IP y el puerto del endpoint en la configuración del cliente, el firewall del paso 4 y si la clave pública del cliente está en el bloque [Peer] del servidor (y al revés).
6. ¿Conecta, pero no se abre nada?
El túnel funciona, pero el servidor no deja salir el tráfico a internet. Comprueba el reenvío:
sysctl net.ipv4.ip_forward
Debe mostrar 1. Si no, actívalo de forma permanente:
echo 'net.ipv4.ip_forward=1' > /etc/sysctl.d/99-vpn.conf
sysctl --system
Después revisa la regla NAT. En una configuración de WireGuard es la línea PostUp con MASQUERADE, y el nombre de la interfaz que aparece debe ser el real de tu servidor:
ip -br addr
Si la línea dice -o eth0 pero tu interfaz se llama de otra forma, corrige la configuración y reinicia el servicio.
7. Prueba desde otra red
Conéctate con datos móviles en lugar del Wi-Fi de casa, o pide a alguien en otro país que lo intente. Si la VPN funciona allí pero no desde tu red habitual, el servidor está bien y algo intermedio bloquea la conexión.
- Para ver si tu servidor es accesible desde un país concreto: Cómo comprobar si la IP de tu VPS es accesible desde Rusia e Irán.
- Donde WireGuard y OpenVPN se detectan y bloquean, VLESS + Reality parece HTTPS normal y es mucho más difícil de bloquear.
8. ¿Sigue sin funcionar?
Abre un ticket e incluye lo que has comprobado: la salida de los pasos 2–5 y el nombre de tu cliente VPN. Con eso normalmente podemos decirte dónde falla en una sola respuesta.
Comentarios
Aún no hay comentarios. Sé el primero.