Los clientes VPN se conectan pero no tienen internet: tres piezas que faltan

El cliente obtiene una dirección, el servidor responde a los ping y, aun así, cada página termina agotando el tiempo. La mayoría de la gente empieza a editar el perfil del cliente en este punto, lo que suele ser un esfuerzo perdido: una vez levantado el túnel, el servidor tiene que comportarse como un enrutador. Tres condiciones deben cumplirse a la vez antes de que un paquete salga y vuelva una respuesta, y el síntoma es idéntico sea cual sea la que falta.

Por qué un túnel que funciona sigue sin tener salida

El núcleo debe reenviar paquetes entre interfaces, lo que está desactivado por defecto en la mayoría de distribuciones de Linux. El tráfico debe traducirse a una dirección que el mundo exterior pueda responder, salvo que cada enrutador ascendente ya conozca la ruta de vuelta a la subred del túnel. La ruta de reenvío del cortafuegos debe permitir el tráfico en ambos sentidos, incluidas las respuestas.

Cada una de ellas puede corregirse por separado, y ahí está la trampa. Activar el reenvío sin una regla de traducción deja los paquetes saliendo con una fuente privada y sin ruta de vuelta. Añadir la traducción sin una regla de reenvío deja al núcleo descartando el paquete un paso después.

Así que pruebe las tres capas en lugar del cliente, y cambie una cada vez para que el resultado signifique algo.

El reenvío es un interruptor del núcleo que hay que hacer persistente

Compruebe el valor actual antes de cambiarlo, luego establézcalo y confirme que el cambio surtió efecto.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

El primer comando informa del valor actual, el segundo lo establece en tiempo de ejecución y el tercero demuestra que la escritura funcionó. El valor en tiempo de ejecución desaparece en el siguiente reinicio, y por eso una sesión que funciona puede romperse tras un mantenimiento sin ningún cambio de configuración.

Hágalo permanente en un archivo bajo /etc/sysctl.d/, y luego aplique ese archivo en lugar de reiniciar para averiguarlo. En FreeBSD el equivalente es net.inet.ip.forwarding, con gateway_enable=YES en rc.conf para la persistencia. Un equipo que informa del reenvío desactivado explica toda una clase de informes de «llegan paquetes y no vuelve nada». Revise el ajuste después de cada actualización también, porque un núcleo reconstruido o una imagen de equipo sustituida pueden restablecerlo sin avisar a nadie.

Elija masquerade o una dirección de traducción fija

Con una dirección exterior dinámica, masquerading es la forma correcta más sencilla. Nombre la subred del túnel como origen y la interfaz exterior como salida.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

Con una dirección pública estática, la traducción de origen a esa dirección exacta es más predecible y más fácil de auditar.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

La segunda forma lleva una trampa de mantenimiento: una dirección codificada de forma fija que luego cambia mantiene el túnel funcionando mientras el acceso a internet se detiene en silencio. O use masquerade o actualice la regla cada vez que el proveedor lo mueva. La interfaz también importa, porque un enrutador que comparte su propio túnel ascendente tiene que traducir por ese túnel y no por la WAN física.

La tabla de filtros es la tercera puerta

El reenvío y la traducción pueden ser ambos correctos mientras el paquete sigue muriendo en la tabla de filtros. ufw es un culpable frecuente: su política de reenvío llega como DROP, y el resto de la configuración puede parecer perfectamente correcta mientras ese único ajuste mata el tráfico. Subirla es una decisión de seguridad deliberada y no una casilla de verificación.

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

La primera regla permite tráfico nuevo del túnel hacia fuera, y la segunda solo las respuestas de vuelta. Estreche ambas a la subred del túnel y al destino que pretende, porque una aceptación general en la interfaz del túnel convierte la VPN en un punto de salida abierto para cualquiera que pueda autenticarse.

Un túnel puenteado necesita otra respuesta. La dirección pertenece al puente, no al puerto físico, así que esclavizar la interfaz elimina la dirección que antes tenía y el anfitrión parece inalcanzable hasta que el propio puente recibe una, que dhclient br0 puede proporcionar. Ese fallo parece un problema de VPN y es un problema de capa dos. Revise la dirección propia del puente antes de tocar el cortafuegos, porque un cambio de filtro no puede arreglar un anfitrión que ya no tiene dirección desde la que enviar.

Dónde mirar cuando una página nunca carga

Haga ping a la dirección del túnel del servidor para demostrar que el túnel existe. Luego ejecute un traceroute desde el cliente hacia una dirección pública y lea dónde se detiene: en el servidor el paquete llega pero no se reenvía ni se traduce; más allá del servidor el problema está aguas arriba y fuera de sus manos.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

El primer comando demuestra que el túnel lleva tráfico al propio servidor, y el segundo muestra hasta dónde llega un paquete hacia fuera. Una traza que termina en la dirección del túnel apunta al reenvío o a la traducción en el servidor, mientras que una traza que se detiene un salto después apunta al proveedor o a la ruta de vuelta del enrutador ascendente.

En el servidor, observe la interfaz exterior mientras un cliente carga una página. El tráfico que sale con una dirección de origen privada significa que falta la traducción, y la ausencia total de respuesta significa que la ruta de reenvío o la ruta de vuelta ascendente lo está descartando.

Si los clientes remotos también deben llegar a anfitriones de la LAN del servidor, recuerde que la LAN necesita una ruta de vuelta a la subred del túnel. Eso es enrutamiento y no traducción, y es el paso que más a menudo se olvida cuando la ruta a internet por fin funciona.