NAS inaccesible por la VPN: ¿dirección, camino de vuelta o servicio?

Los túneles se levantan, los clientes reciben una dirección y el NAS no responde absolutamente nada. Ese único síntoma cubre tres fallos sin relación, y el orden en que los pruebe decide cuánto tarda la reparación. El direccionamiento va primero, porque una subred solapada puede enviar su petición a un dispositivo ajeno. El camino de vuelta va segundo, porque una petición que llega sin respuesta parece idéntica a un servicio cerrado. El servicio y el permiso van al final, y solo después de probar los dos primeros.

Tres fallos que se leen todos como inaccesible

La selección de dirección, el enrutamiento de vuelta y la autorización del servicio producen el mismo mensaje visible: no ocurre nada. Tienen pruebas, responsables y correcciones distintas, así que separarlos es toda la tarea. Un ping que falla demuestra poco por sí solo, y un rechazo TCP correcto es en realidad una buena noticia.

Lea la tabla como un orden de pruebas y no como una lista de causas. Cada fila limita la siguiente, porque un rechazo ya demuestra que el direccionamiento y el camino de vuelta funcionan. Pasar veinte minutos dentro de reglas de firewall antes de comprobar qué interfaz eligió la ruta es la forma más habitual de perder una tarde. Trabaje de arriba abajo y deténgase en la primera fila que encaje.

Condición uno: ¿es esa dirección el dispositivo correcto?

Anote la subred del NAS y el rango que la VPN entrega a los clientes, y compare ambos con la red en la que está su portátil ahora mismo. En este recorrido el NAS está en 10.40.7.25 y el grupo de la VPN es 10.40.9.0/24, dos rangos privados separados dentro de un mismo plan de sitio; un hogar que use 192.168.0.0/24 o 10.0.0.0/24 tiene muchas más posibilidades de chocar con uno de ellos.

Cuando la red local y la red del NAS se solapan, el cliente envía ese tráfico a su propia puerta de enlace y puede llegar a un dispositivo no relacionado que casualmente tenga la misma dirección. Verifique el camino antes de escribir credenciales en cualquier cosa que responda.

ip -4 route get 10.40.7.25
traceroute -n -m 5 10.40.7.25

El primer comando nombra la interfaz y la puerta de enlace que usaría el núcleo, y el segundo muestra los primeros saltos que responden de verdad. Si los dos no coinciden, crea la consulta, porque es el camino que tomará el paquete. Una lista de saltos que se detiene un salto antes del NAS también es un hallazgo y no un fallo. Una consulta que se resuelve hacia el adaptador físico en lugar del túnel termina la investigación en este punto.

Condición dos: ¿vuelve la respuesta?

El cliente necesita una ruta hacia el NAS, y la red del NAS necesita un camino de vuelta hacia el grupo de la VPN. El reenvío de la puerta de enlace, las reglas de firewall y la traducción deliberada afectan cada uno a ese par. las notas de reenvío de strongSwan describen las opciones de ruta de vuelta y de traducción para una subred privada detrás de una puerta de enlace.

Cuando la petición llega y la respuesta sale por otra puerta de enlace, ningún cambio de DNS repara la asimetría. Una captura en ambos lados lo resuelve en un solo intento, y también muestra si la traducción reescribió el origen al que respondió el NAS. El administrador es dueño de esa frontera: permita solo los servicios necesarios y el rango de clientes de la VPN, y anote si se eligió enrutamiento o traducción.

Condición tres: ¿está el servicio y está permitido?

Una página de gestión y un servicio de compartición de archivos son puntos finales distintos en la misma máquina, y uno puede aceptar conexiones mientras el otro queda bloqueado por el firewall del host, la configuración del servicio o un permiso de compartición. Un dispositivo que responde con un rechazo ya ha probado las dos primeras condiciones, lo que estrecha mucho la tercera.

Pruebe con la cuenta que realmente necesita los archivos, no con la cuenta de administrador de la instalación, porque los derechos administrativos no pueden reparar una ruta que falta y una ruta no puede conceder un permiso de compartición. Los nombres también tienen cabida aquí: un nombre de NAS descubierto en casa suele depender de multicast local, que un túnel enrutado no transporta, así que pruebe el nombre de host privado documentado por el fabricante o la dirección misma para separar el nombrado del acceso.

Pruebe desde fuera de la red del NAS y amplíe después poco a poco

Una prueba hecha en la misma LAN oculta cada parte incompleta del camino remoto, y por eso el primer intento remoto correcto merece una nota en el registro de cambios. Ejecute las comprobaciones desde un cliente que solo llegue al NAS por el túnel, y guarde el texto de error original de cada intento.

nc -vz 10.40.7.25 445
smbclient -L 10.40.7.25 -U guest

Cuando el camino funcione, transfiera un archivo inocuo y confirme el comportamiento de lectura o escritura que realmente necesita. Si las transferencias grandes se atascan mientras las pequeñas funcionan, el problema restante es el tratamiento del tamaño de paquete o la estabilidad de la conexión, no el direccionamiento.

No publique puertos de compartición de archivos ni de administración en internet para sortear un fallo sin explicación. Repare el camino privado, mantenga el software del NAS con soporte y pruebe la restauración de todo lo que copie a través de él antes de confiar en esa copia.