Conectado a OpenVPN pero nada carga: un recorrido desde el cliente

La ventana del cliente dice Conectado, la dirección del túnel está ahí, y el navegador sigue girando. Esa combinación es normal, porque un handshake correcto solo demuestra que el túnel se construyó; no dice nada sobre si el servidor reenviará tus paquetes, reescribirá su origen o responderá tus consultas DNS. El error que comete la mayoría es abrir primero la configuración del servidor. En su lugar, avanza desde el cliente hacia fuera, porque cada paso de abajo te dice si el siguiente siquiera merece revisarse.

Empieza en el cliente y avanza hacia fuera

Haz tres pruebas en este orden y anota dónde falla la primera. Haz ping a la dirección del túnel del servidor, lo que demuestra que el túnel mismo transporta tráfico. Haz ping a una dirección pública por número, lo que demuestra el reenvío y la traducción sin involucrar la resolución de nombres. Luego intenta resolver un nombre de host, que es la única prueba que ejercita el DNS. Cada resultado quita una capa entera de sospecha.

No saltes a la tercera prueba porque el navegador se sienta más rápido. Una carga de página fallida cubre las tres capas a la vez, y por ahí empieza la gente que luego reconstruye un túnel que funcionaba. Una página que falla no te dice cuál de las tres se rompió.

Dos capturas muestran dónde se detienen los paquetes

Con un ping a una dirección pública corriendo desde el cliente, toma una captura en la interfaz del túnel y otra en el enlace ascendente que se supone llega a internet. Ejecuta ambas a la vez para que las marcas de tiempo coincidan.

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

Si las peticiones aparecen en el túnel y nunca en el enlace ascendente, el servidor las descartó entre el túnel y el cable, y la causa es el reenvío o la política de cortafuegos de reenvío, no el NAT. Si aparecen en ambos, el servidor hizo su parte y la respuesta falta más afuera, lo que apunta a la traducción, a un filtro aguas arriba o a una restricción del proveedor.

Toma el nombre del enlace ascendente de la tabla de rutas, no de un tutorial. Las imágenes de nube y los adaptadores renombrados rara vez coinciden con la interfaz de ejemplo de una guía, y una captura tomada en el dispositivo equivocado se ve exactamente como un servidor que no reenvía:

ip -4 route get 9.9.9.9

El campo dev de esa salida es el nombre que la regla NAT necesitará después, así que consérvalo.

El reenvío es un interruptor del núcleo y una política de cortafuegos

El núcleo tiene que aceptar reenviar, como mínimo. Lee el valor actual y luego haz permanente el ajuste en lugar de escribirlo solo en el núcleo en ejecución:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

El reenvío es solo la mitad. En un host con UFW la política de reenvío se define en /etc/default/ufw y debe ser ACCEPT antes de que una recarga surta efecto. Un descarte por defecto en la ruta de reenvío deja el handshake perfectamente sano mientras descarta en silencio cada paquete que intenta salir por el túnel, que es exactamente el síntoma con el que empezaste.

Los hosts que gestionan nftables directamente tienen la misma pregunta con otra sintaxis. Mira los contadores de la cadena de reenvío mientras corre una prueba desde el cliente, porque una cadena que se consulta y una cadena que descarta se ven idénticas en un archivo de configuración.

Nombra la interfaz de salida real en la regla NAT

La traducción de origen corresponde a la interfaz que realmente sale del host, con el pool que reparte el servidor. Ambas mitades de esa regla tienen que describir la realidad, y ninguna es opcional.

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

El fallo clásico es una regla copiada de una guía que dice -o eth0 en una máquina cuyo adaptador se llama de otra forma. La regla se instala sin aviso, no coincide con nada, y el cliente sigue sin internet. El pool es la otra mitad del mismo error: si el servidor reparte 10.44.0.0/24 y la regla cubre 10.8.0.0/24, nada coincidirá nunca.

Mira los contadores en lugar de confiar en el texto de la regla. El listado informa paquetes por regla, y una regla que nunca coincide se queda en cero por correcta que parezca. Dale un minuto de tráfico real del cliente antes de leer nada en ese número:

iptables -t nat -L POSTROUTING -v -n

Un recuento de paquetes cero tras una prueba real del cliente significa que la coincidencia está mal, no que el túnel esté roto. En cuanto coincida, guarda el conjunto de reglas para que sobreviva a un reinicio; un arreglo que solo vive en el historial de tu shell desaparece en el primer reinicio.

Si el servidor también es una instancia NAT en la nube, la plataforma también tiene voz. Una instancia que traduce direcciones suele necesitar la comprobación de origen y destino desactivada donde el proveedor ofrece ese ajuste, y el propio puerto VPN tiene que ser alcanzable desde fuera.

El DNS es el segundo fallo detrás del primero

Que el ping por dirección funcione mientras fallan los nombres es un problema del resolutor, y tiene su propia causa. Un cliente que conserva su resolutor local envía esas consultas dentro de un túnel completo y espera una respuesta que nunca llega, porque el resolutor local está ahora en el lado equivocado de la ruta.

Empuja un resolutor desde el servidor para que el cliente sepa dónde preguntar. Dos entradas dan al cliente una alternativa si la primera no es alcanzable, y ambas deberían ser resolutores que el túnel permita de verdad.

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Los clientes de Windows pueden volver igualmente al resolutor local, que es justo lo que block-outside-dns existe para evitar, a cambio de perder nombres que solo la red local puede resolver. Los clientes de Linux con systemd-resolved suelen ignorar un resolutor empujado salvo que un script lo instale, así que revisa resolvectl status para el dispositivo del túnel antes de concluir que se ignoró el empuje.

Termina el recorrido tal como lo vive un usuario. Carga una página real desde el cliente, confirma la dirección desde la que sale, reinicia el servidor, vuelve a conectar y repite las tres pruebas. Esa segunda pasada es la única que demuestra que las reglas guardadas, la política de cortafuegos y el resolutor empujado sobrevivieron todos juntos.