El VPN se conecta pero no llega a los dispositivos de la LAN: qué revisar

El tráfico entra en el túnel, la puerta de enlace responde en su propia dirección y nada detrás de ella responde. Ese patrón es habitual y no es una contradicción: una respuesta de la puerta de enlace demuestra que el túnel terminó, y no demuestra nada sobre lo que ocurre con un paquete dirigido más allá. Las dos pruebas ejercitan rutas de código distintas en la misma máquina.

A partir de ahora, pruebe algo al otro lado de la puerta de enlace. La dirección propia de la puerta de enlace seguirá respondiendo por muy roto que esté el reenvío.

La puerta de enlace responde desde su propia pila

Un paquete dirigido a la puerta de enlace se entrega a su ruta de entrada local, donde el núcleo decide si lo acepta un socket a la escucha. Un paquete dirigido a un host detrás de la puerta de enlace se entrega, en cambio, a la ruta de reenvío, donde se aplica otro conjunto de comprobaciones. El reenvío puede estar completamente desactivado, o el núcleo puede activarlo y luego una regla de filtro que nunca menciona el túnel puede rechazarlo. Nada de eso afecta a la respuesta propia de la puerta de enlace, por eso el síntoma engaña con tanta fiabilidad.

Las páginas de administración alcanzadas por el túnel también pertenecen a la primera categoría. Son evidencia sobre el túnel, no sobre la red que hay detrás.

Siga el flujo hasta la primera frontera que lo descarte

Empiece en el cliente y confirme la ruta y la dirección de origen que usará el flujo. Luego observe la puerta de enlace para ver llegar ese flujo exacto, y de nuevo el mismo flujo saliendo hacia la LAN. Si nunca llega, el problema está en el lado del cliente o en los prefijos permitidos del túnel. Si llega y nunca sale, el problema está en el reenvío o en un filtro de la ruta de avance, y la captura ya ha dicho cuál de los dos.

Ejecutar la misma prueba desde la puerta de enlace oculta la mitad interesante, porque un paquete originado en la puerta de enlace tiene otro origen y otro requisito de retorno. Use el flujo del cliente, con su propia dirección de origen, en cada paso. Una captura tomada en la interfaz equivocada produce sandeces con mucha seguridad.

Las rutas de retorno y los cortafuegos de los hosts fallan por separado

Cuando el paquete llega al host, deben cumplirse tres cosas más. El servicio debe estar escuchando en la dirección a la que se envió el paquete, el cortafuegos del host debe aceptarlo, y la respuesta debe tener una ruta de vuelta hacia el conjunto de clientes. Esa última falla a menudo, porque la ruta predeterminada del host apunta a un enrutador que nunca ha oído hablar del rango del túnel. El resultado es una conexión que se establece desde el punto de vista del host y muere en silencio en la otra dirección.

Pruebe la ruta de vuelta a propósito enviando desde el cliente y observando el retorno. Una captura unidireccional resuelve en segundos lo que una hora de especulación no resolverá.

Confirme cada salto con la dirección de origen del cliente

Ejecute las comprobaciones en orden y conserve cada salida, porque el valor está en la comparación y no en ninguna línea concreta. Los comandos de abajo fijan la dirección de origen, muestran la ruta elegida y capturan ambos lados del reenvío. Sustituya su propio host de la LAN y su interfaz de túnel.

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

La consulta de ruta muestra si el cliente enviaría siquiera ese paquete al túnel, y el ping muestra si volvió algo del host. Comparar las dos capturas separa la llegada de la salida, ya que una trama en la interfaz del túnel sin contrapartida en la interfaz de la LAN es una decisión de reenvío y no un fallo del servicio. Cuando ambas capturas muestran la petición y solo una muestra la respuesta, la ruta de vuelta es el sospechoso restante.

Anote qué dirección respondió y qué destino reenviado falló. Esa frase hace el informe accionable en lugar de una afirmación de que el servidor no es accesible.