El router como cliente SMB frente a reenviador de paquetes: cuál encaja

Reenviar el tráfico SMB no es la misma tarea que terminarlo, y un router que hace una puede que no domine la otra. Reenviar significa que el router mueve paquetes cuyo contenido nunca analiza. Montar significa que el router se convierte en cliente de archivos, con software que puede no incluir, credenciales que debe proteger y modos de fallo que ahora asume. Elegir entre ambos es una cuestión de dónde se necesitan los archivos, no de a qué se puede convencer a la plataforma de enrutamiento para que instale.

Reenviar y terminar son tareas distintas

En el papel de reenvío el router tiene una responsabilidad: entregar paquetes entre el cliente y el servidor aplicando la política que exija el camino. No se autentica en el recurso compartido, no cachea datos de archivos y no le importa si el servidor habla SMB2 o SMB3, porque nunca lee tan adentro del flujo. Si el recurso deja de estar accesible, el usuario ve un error y el router sigue enrutando.

En el papel de cliente el router se suma a la conversación del protocolo. Negocia un dialecto, se autentica, resuelve nombres, mantiene un punto de montaje y presenta una vista local del sistema de archivos a todo lo que corre por encima. Es un servicio real con un ciclo de vida, y convierte la puerta de enlace en una dependencia del flujo de trabajo de archivos. También hereda todos los modos de fallo de esa dependencia, incluidas las esperas durante el arranque y las credenciales obsoletas.

La comparación no va solo de capacidad. Una plataforma que puede montar un recurso no es automáticamente una plataforma que debería hacerlo, y una plataforma que no puede montar ninguno puede seguir siendo el lugar correcto para enrutar el tráfico.

Qué necesita realmente un montaje CIFS del núcleo

En un equipo basado en Linux, el cliente CIFS del núcleo y un cliente de espacio de usuario son capacidades separadas, y las imágenes pequeñas a menudo no incluyen ninguna. El soporte del núcleo tiene que estar en la imagen en ejecución, tiene que existir el asistente de montaje y el dialecto SMB negociado con el servidor tiene que ser uno que ambas partes acepten. Lo describe la guía del cliente CIFS de Linux, que explica la disposición del núcleo y sus opciones de montaje, y es la referencia correcta antes de suponer que una compilación de fabricante la incluye.

Compruebe la capacidad antes de diseñar alrededor de ella, y compruebe la versión en lugar de la presencia de un nombre de comando. Un nombre de módulo en una lista de paquetes no es lo mismo que un cliente que funciona.

lsmod | grep -w cifs
modinfo cifs | head -5
mount.cifs --version
smbclient -L //fs02.corp.internal -U svc-router -m SMB3

Un módulo del núcleo que se carga y una herramienta de espacio de usuario que informa de una versión todavía no garantizan que un montaje sobreviva a una renovación de claves de VPN, así que trate la prueba como una condición inicial y no como una prueba concluyente. Si la imagen solo trae soporte SMB1, eso es motivo para detenerse, no motivo para habilitarlo en el servidor.

Las credenciales y la identidad de origen difieren de las de un portátil

Una petición reenviada lleva la identidad del portátil por el túnel, mientras que una petición generada en el router lleva su propia dirección de origen, la ruta del resolutor y el filtrado de salida. Pueden acabar en una regla de cortafuegos distinta, una vista de DNS distinta y una lista de permitidos distinta en el lado del servidor. Por tanto, una copia que funciona desde una estación de trabajo no demuestra nada sobre el montaje propio del router. Pruebe el montaje desde el propio intérprete de órdenes del router, no desde una estación de trabajo situada detrás.

Dé al router una identidad de servicio con autorización estrecha si el papel se aprueba siquiera. Nunca ponga una contraseña directamente en la línea de órdenes de montaje, porque se queda en el historial del intérprete y aparece en la tabla de procesos mientras el montaje se ejecuta.

Guarde la credencial mediante el mecanismo protegido de la plataforma y léala de un archivo con permisos restrictivos. Ese archivo debería ser ilegible para toda cuenta excepto la que ejecuta el montaje.

install -m 600 /dev/null /etc/cifs-reports.creds
printf 'username=svc-router\npassword=REPLACE_ME\ndomain=CORP\n' > /etc/cifs-reports.creds
mount -t cifs //fs02.corp.internal/reports /mnt/reports -o credentials=/etc/cifs-reports.creds,vers=3.1.1,ro

Quién es dueño del fallo cuando el recurso desaparece

Un sistema de archivos remoto ausente se comporta de forma distinta a una ruta ausente. Un montaje puede bloquear procesos que lo tocan, puede fallar en el arranque antes de que exista el túnel, y una escritura destinada al servidor puede acabar en el lugar equivocado si hay un directorio local bajo el punto de montaje. Son fallos de almacenamiento que ahora asume el equipo de red, tanto si los quería como si no. Nadie aceptó esa propiedad, pero llega con el montaje.

Diseñe el orden de arranque y las opciones de montaje en torno a esa realidad. Un montaje de solo lectura con un tiempo de espera corto y un paso de recuperación documentado es más fácil de defender que un montaje de escritura del que depende todo lo demás. Confirme que el túnel sube antes de que algo intente montar, o el primer arranque tras un corte de luz se quedará colgado.

Para un procesamiento de archivos considerable, o para cualquier cosa que reexporte los datos más adelante, un host separado suele dar un límite de propiedad más claro. El router sigue enrutando, y el flujo de trabajo de archivos obtiene una máquina que puede reiniciarse sin llevarse la red consigo.

Compruebe la decisión contra la tarea real

Anote qué tarea necesita los archivos y dónde se ejecuta esa tarea. Si la respuesta es una estación de trabajo, enrute el recurso y deténgase ahí. Si la respuesta es un servicio en el equipo, confirme la capacidad del cliente, el dialecto admitido y la ruta de las credenciales antes del primer montaje, y después decida si el equipo es realmente el host correcto.

Verifique la vista montada y el espacio libre desde el propio router, ya que es ahí donde la carga de trabajo los verá. Repita la comprobación tras una reconexión, no solo tras un arranque limpio.

findmnt -t cifs -o TARGET,SOURCE,OPTIONS
df -h /mnt/reports
ls -l /mnt/reports | head

Un montaje que lista archivos pero informa de un sistema de archivos lleno o de solo lectura ya le ha dicho con qué fallo se encontrará a las 2 de la madrugada. Confirme también la ruta de recuperación: desmonte limpiamente, baje el túnel, vuelva a subirlo y monte de nuevo sin reiniciar el equipo. Si esa secuencia necesita un caso de soporte cada vez, el router es el lugar equivocado para el papel de cliente.