¿Conectado a OpenVPN pero sin ping ni recurso compartido SMB? Comprueba tres puertas

El túnel se levanta, el cliente recibe una dirección y nada en la LAN remota responde. El ping falla, el recurso compartido no se abre y el registro del VPN parece limpio porque, desde su punto de vista, la sesión está sana. Entre esa sesión y un archivo en un servidor hay tres puertas independientes: la política de reenvío, los puertos que necesita el servicio y el nombre que escribiste en lugar de una dirección.

Cada puerta falla con un síntoma distinto, y solo la primera está en el servidor VPN.

El reenvío es una política de la cadena FORWARD

La aceptación del listener de OpenVPN ocurre en INPUT, por eso el túnel puede conectarse mientras se descarta cada paquete dirigido a la LAN. El tráfico que llega por tun0 y sale por la interfaz de la LAN atraviesa FORWARD, y un host con una política DROP predeterminada allí lo descarta en silencio. Comprueba tanto el sysctl como la cadena antes de tocar cualquier otra cosa: sysctl net.ipv4.ip_forward y iptables -L FORWARD -v -n.

Permite la dirección que pretendes y las respuestas que le pertenecen, por ejemplo una regla accept de la interfaz del túnel a la interfaz de la LAN más una regla stateful para tráfico established y related. Si la LAN está detrás de otro router, ese router necesita una ruta de vuelta al pool de clientes o un source NAT en el servidor VPN. Confirma esa ruta con un solo ping antes de añadir más reglas, porque una regla que no se puede alcanzar nunca aparece en un contador.

SMB necesita más de un puerto

Compartir archivos no es una sola conversación TCP 445. El descubrimiento usa UDP 137 y 138, las sesiones NetBIOS antiguas usan TCP 139 y las sesiones SMB modernas usan TCP 445. Una regla que solo abre el 445 produce el caso desesperante en el que una unidad asignada funciona y la exploración de la red no, o al revés.

Las transferencias grandes por un túnel también chocan con problemas de MSS que parecen un recurso compartido roto. Un SYN que anuncia el tamaño de segmento completo de la LAN se descarta por el MTU más pequeño del túnel, y la conexión se cuelga tras el handshake. Limitar el MSS en la ruta de reenvío, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, elimina esa clase de bloqueo. Verifícalo con una copia de unos pocos megabytes en lugar de un listado de directorio, porque las respuestas pequeñas pasan incluso cuando las transferencias grandes no.

El adaptador del túnel llega como un perfil de red nuevo

Windows clasifica cada adaptador en un perfil de red, y un adaptador de túnel nuevo suele caer en Public, donde las reglas de compartir archivos e impresoras están bloqueadas. Es una decisión del firewall del host en el servidor de archivos, no un problema de enrutamiento en el servidor VPN. Cambia la categoría a propósito con Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private después de confirmar que la política lo permite, porque la categoría también cambia qué reglas de entrada se aplican.

El mismo perfil explica un ping que falla mientras el TCP 445 tiene éxito: las solicitudes de eco se descartan en Public de forma predeterminada.

Los nombres no cruzan solos un túnel enrutado

La resolución de nombres NetBIOS y el descubrimiento local dependen de difusiones que un túnel enrutado no transporta. Por eso escribir el nombre corto del servidor falla mientras su dirección funciona, y el recurso compartido parece roto cuando solo lo está la consulta. Añade un registro DNS para el servidor en el resolutor que entrega el túnel, o usa la dirección en el acceso directo.

Si el despliegue aún depende de WINS, configúralo en el cliente en lugar de esperar a que aparezca tráfico de difusión. Prueba primero por dirección para que un fallo de nombre no se confunda con un fallo de firewall.

Prueba una capa a la vez y lee el primer fallo

Avanza hacia arriba: haz ping a la puerta de enlace del túnel, haz ping a un host de la LAN por dirección, luego abre el puerto del servicio con Test-NetConnection -ComputerName 10.8.0.5 -Port 445, y solo entonces autentícate en el recurso compartido. El primer paso que falla es la capa que hay que arreglar, y cada paso posterior es ruido hasta que ese pase. Un ping que responde mientras el puerto sigue cerrado apunta al firewall propio del servidor de archivos, mientras que un puerto que se abre pese a pings silenciosos apunta al filtrado ICMP. Anota el primer paso que falla antes de cambiar nada, porque un segundo cambio oculta el resultado del primero.

Si el servidor VPN no es el router de la LAN, confirma la ruta de vuelta en ese router antes de añadir más reglas al servidor. Sin ella, las solicitudes llegan al host y las respuestas salen por la ruta predeterminada hacia internet, lo que desde el lado del cliente parece exactamente un descarte del firewall.

Mantén la cuenta del recurso compartido separada del inicio de sesión del VPN en tus notas, porque un túnel exitoso no dice nada sobre los permisos de archivos. Exponer SMB a internet para sortear una regla que falta no es una solución.