¿Acceso a la LAN con OpenVPN roto? Revisa zonas, rutas y camino de vuelta

El túnel informa de una conexión correcta, la página del propio router carga, y la unidad de red hacia una máquina detrás sigue agotando el tiempo. Nada de esa combinación es contradictorio: el router responde como sí mismo, y llegar a algo detrás es otra decisión tomada en otro lugar. Sigue las comprobaciones de abajo en orden y detente en el primer fallo, porque cada una se apoya en la anterior. Cuando las cuatro pasan, el fallo está por encima del túnel y no dentro.

Qué filtro ve un paquete destinado a la LAN

Un paquete dirigido al router se consume localmente; un paquete dirigido a un host detrás debe reenviarse, y los cortafuegos juzgan esos dos casos por separado. Por tanto, el permiso para llegar al router no dice nada sobre el permiso para cruzarlo. El firmware que oculta sus conjuntos de reglas sigue implementando ambos, normalmente como un selector que ofrece la LAN, internet o ambos. Si el selector deja fuera la LAN, ninguna comprobación posterior importará.

OpenWrt hace inspeccionable esa división, y la distinción merece una lectura. La zona que termina el túnel necesita una regla de reenvío hacia la zona LAN, mientras que una regla de entrada solo gobierna servicios del propio router. Una página de administración que funciona junto a una LAN muerta es el resultado habitual de esa regla de reenvío ausente.

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

Mira el destino de reenvío de la zona que lleva el túnel: accept es lo que necesita la escalera, y reject explica cada tiempo de espera de abajo. Dos ajustes vecinos producen el mismo síntoma, así que descártalos mientras estás aquí. El aislamiento inalámbrico oculta los hosts cableados a los clientes inalámbricos, y un router que trata los hosts LAN inactivos como desconectados puede descartar las respuestas incluso después de que el reenvío funcione.

Por qué un túnel dividido necesita el prefijo empujado

Un cliente que envía todo el tráfico por el túnel ya tiene el prefijo LAN mediante su ruta por defecto, así que no hay nada que añadir. El túnel dividido es el caso que necesita el prefijo declarado explícitamente, porque nada más en la configuración lo menciona. Añade la directiva a la configuración del servidor y recarga el servicio.

push "route 192.168.50.0 255.255.255.0"

Los perfiles que contienen route-nopull ignoran las rutas empujadas, así que el mismo prefijo pertenece al archivo del cliente. En cualquier caso, confirma que la entrada llegó en lugar de suponerlo, porque una sustitución silenciosa parece idéntica a un problema de cortafuegos.

ip route show | grep 192.168.50

Un par de sitio a sitio pide más que un empujón. El servidor debe aprender qué prefijos hay detrás de ese par, lo que hace una línea iroute en su archivo client-config-dir, y su propia tabla necesita una ruta coincidente hacia el túnel.

La respuesta necesita una dirección a la que pueda llegar

Reenviar la petición es solo la mitad de un intercambio, porque el host de la LAN debe responder a una dirección del conjunto del túnel. Los routers pequeños suelen arreglarlo traduciendo el origen en la zona del túnel, de modo que la respuesta se dirige al router y no necesita configuración en otro sitio. Quita esa traducción y el host necesita su propia ruta al conjunto, que obtiene gratis cuando el router es su puerta de enlace predeterminada. Un host con dirección fijada a mano y otra puerta de enlace responde por esa puerta, y el cliente ve abrirse una sesión y luego atascarse.

tcpdump -ni tun0 host 192.168.50.20

Ejecuta eso en el router mientras el cliente repite su petición, y lee el destino de la respuesta en lugar de la petición. Una respuesta dirigida al conjunto significa que el camino de vuelta funciona y que el fallo está más adentro. Ninguna respuesta significa que el host nunca aceptó el paquete, lo que te devuelve al conjunto de reglas.

Una escalera que termina en el sitio correcto

Cuatro comprobaciones localizan la capa, y cada una es un solo comando en lugar de un juicio. Ejecútalas en orden y detente en el primer fallo. El orden importa más que los comandos, porque un paso posterior que pasa oculta la razón por la que falló uno anterior.

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

Los nombres van al final de la escalera, nunca al principio. Un recurso compartido que responde como 192.168.50.20 pero no como nas.local apunta a la resolución o a un sufijo de búsqueda, y las ediciones del cortafuegos no pueden cambiar ninguno de los dos.

Anota el primer paso fallido y luego da a los puertos de servicio su propia pasada, porque un oyente y un permiso de host son requisitos separados. Compartir archivos, escritorio remoto y flujos de cámara necesitan ambos, y un cortafuegos del host que confía en la subred LAN pero no en el conjunto del túnel descarta al cliente mientras el ping aún funciona. Cuando todas las comprobaciones pasan y la aplicación sigue fallando, el fallo está por encima del túnel: un servicio ligado a una interfaz o un proxy configurado en el cliente.