El cliente OpenVPN llega al servidor pero no a los equipos de la LAN: lista de comprobación

El cliente dice conectado, la dirección del túnel responde a un ping y nada en la LAN de la oficina responde. Lo veo tras casi cada actualización del cliente, y el primer instinto es abrir el cortafuegos, que suele ser el movimiento equivocado: el túnel está bien y la rotura está en uno de los tres saltos que el paquete debe cruzar. Recorra la ruta en el orden en que la toma el paquete, primero la ruta del cliente, luego el reenvío del servidor, luego el viaje de vuelta, y encontrará al culpable de la avería en un par de minutos.

Paso uno: observe la decisión de enrutamiento del cliente

Antes de tocar el servidor, demuestre que el cliente envía el paquete al túnel. Pregunte al núcleo qué interfaz usaría para un equipo LAN concreto, en lugar de leer toda la tabla:

ip route get 192.168.50.10

Si la respuesta nombra su adaptador físico y la puerta de enlace de la oficina, ningún cambio en el lado del servidor puede ayudar. OpenVPN solo reparte rutas cuando el servidor las empuja, así que busque push "route 192.168.50.0 255.255.255.0" en la configuración del servidor y vuelva a conectar el cliente después. La mayoría de los clientes aplican las rutas empujadas al conectar, no cuando recarga el perfil.

En Windows la misma pregunta tiene otro comando. Find-NetRoute -RemoteIPAddress 192.168.50.10 imprime la interfaz y el siguiente salto que elegiría la pila, y route print -4 muestra si el prefijo empujado existe siquiera.

Paso dos: confirme que el servidor reenviará el paquete

Si la ruta del cliente es correcta, el paquete llega al servidor y el servidor debe aceptar reenviarlo. El interruptor del núcleo es la primera puerta, y sysctl net.ipv4.ip_forward debe devolver 1. Ponerlo con echo 1 > /proc/sys/net/ipv4/ip_forward funciona hasta el siguiente reinicio, y es exactamente por eso que la misma queja vuelve semanas después.

Anótelo en un lugar que sobreviva a un reinicio:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

La segunda puerta es la tabla de filtros. Un equipo con Docker instalado suele llevar una política FORWARD de DROP, y el túnel hereda esa decisión. iptables -L FORWARD -v -n muestra tanto la política como los contadores de paquetes; si la política es DROP, el reenvío necesita una aceptación explícita para el sentido del túnel hacia la LAN y otra para la respuesta.

Paso tres: siga el paquete hasta la LAN y busque la respuesta

Vigile ambos lados del servidor a la vez. Capture en el túnel y en la interfaz LAN, filtrado a un cliente y un equipo para que la salida siga siendo legible:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

Las peticiones que aparecen en tun0 y de nuevo en eth0 con un origen 10.8.0.x, seguidas de silencio, significan que el paquete llegó y la respuesta se fue a otro sitio. El equipo LAN responde a su puerta de enlace predeterminada, esa puerta no tiene ruta para el grupo de VPN, y la respuesta muere en el router de la LAN. Hacer ping al equipo LAN desde el servidor no demuestra nada sobre este camino, porque ese tráfico nunca cruza el túnel.

Paso cuatro: elija entre traducción y una ruta de vuelta

Dos arreglos cierran el agujero, y la elección tiene consecuencias más allá de si el ping funciona. La traducción de origen hace que el servidor sea el remitente aparente:

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

Limite la regla al grupo y a la interfaz LAN, y luego hágalo permanente, o la siguiente recarga del cortafuegos eliminará su arreglo sin avisar. El coste es la identidad: cada cliente parece el servidor VPN en los registros de la LAN y en las reglas de acceso, y per-client policy becomes guesswork.

Una ruta estática para 10.8.0.0/24 en el router de la LAN, apuntando al servidor VPN, mantiene visibles las direcciones de los clientes y es la mejor respuesta a largo plazo cuando ese router es suyo. Muchos sitios ejecutan ambas durante un tiempo, NAT para el arreglo inmediato y la ruta una vez escrita la política del cortafuegos. Si el servidor es un par site-to-site en lugar de un grupo, el lado del servidor también necesita un iroute para la subred remota, de lo contrario la ruta del par existe pero el tráfico de los clientes nunca se asocia con ella.

Paso cinco: verifique desde el cliente y anote qué cambió

Cierre el bucle desde el cliente, no desde el servidor. Conéctese a un servicio real en el equipo LAN y luego confirme que los contadores de traducción se movieron con iptables -t nat -L POSTROUTING -v -n, porque una regla con cero paquetes es una regla que nunca coincidió. conntrack -L -s 10.8.0.5 muestra el flujo y su estado cuando necesita pruebas de que el sentido de vuelta se rastrea.

Deje una nota en la configuración del servidor: qué subred, qué interfaz, qué regla y si el router de la LAN lleva una ruta de vuelta. La próxima vez que una actualización del cliente borre una ruta empujada, esa nota convierte una sesión de apagar fuegos en un arreglo de una línea.