Compartir SMB sobre VPN sin desconexiones: solucionar ‘La ruta de red no se encontró’ de verdad

Cómo SMB realmente falla sobre VPN (los modos de fallo que importan)

SMB no es un protocolo de «lanzar paquetes al servidor y esperar lo mejor». Mantiene sesiones, estado de autenticación, créditos (control de flujo),
y a veces manejos duraderos y leases. Eso funciona bien en una LAN donde el RTT es bajo, la pérdida de paquetes rara y las rutas no cambian.
Sobre VPN tienes un RTT mayor, más jitter y varios puntos donde la ruta puede desaparecer brevemente sin que nadie lo admita.

Modo de fallo 1: agujeros MTU y fragmentación que «funcionan la mayor parte del tiempo»

Las VPN cambian las restricciones de tamaño de paquete. Si PMTUD está bloqueado o ICMP filtrado, una ruta puede dejar caer silenciosamente paquetes más grandes.
SMB funcionará para listados de directorio y lecturas pequeñas, y luego fallará durante escrituras grandes, operaciones de firmado o acciones con mucha metadata.
«La ruta de red no se encontró» a menudo es Windows traduciendo «la sesión TCP murió y la reconexión falló».

Modo de fallo 2: temporizadores de inactividad NAT/firewall que matan TCP de larga duración

SMB usa TCP. Probablemente tu VPN use UDP (WireGuard, muchas configuraciones de OpenVPN) o ESP encapsulado en UDP (IPsec NAT‑T).
En el medio: dispositivos NAT, firewalls con estado, carrier‑grade NAT, equipos Wi‑Fi de hoteles hechos con mala intención.
Si expira un temporizador de inactividad, la asignación desaparece. El siguiente paquete SMB cae en un agujero negro, el cliente reintenta, luego hace reset y se reconecta.

Modo de fallo 3: flapping de rutas y ambigüedad por split‑tunnel

Si usas split‑tunnel, confías en que la ruta al servidor de archivos se mantenga siempre dentro del túnel.
Eso es confiar mucho cuando DNS cambia, cuando el servidor tiene múltiples IP, cuando las referencias DFS apuntan a otro lado,
o cuando un cliente hace roaming entre Wi‑Fi y ethernet.

Modo de fallo 4: las características de seguridad de SMB aumentan la sensibilidad a la latencia

El firmado y el cifrado SMB son cosas buenas. También añaden sobrecarga y pueden amplificar efectos de latencia—especialmente en patrones de E/S pequeños.
Añade antivirus, opportunistic locking/leases y una carga muy habladora (los archivos de Office son pequeños y problemáticos), y
de repente has construido una torre de protocolos donde cualquier bamboleo se vuelve una desconexión.

Modo de fallo 5: la resolución de nombres falla, no el servidor

«La ruta de red no se encontró» muchas veces es un problema de nombres. El servidor está arriba, accesible por IP y sirviendo felizmente.
Pero el cliente resuelve fileserver a una dirección pública, o a una dirección antigua, o a IPv6 en un intento y a IPv4 en el siguiente.
La reconexión SMB usa nombres, SPN y a veces espacios de nombres DFS. Un resolvedor inestable puede parecer una red inestable.

Modo de fallo 6: presión de recursos en el servidor provoca resets de sesión

No ignores el servidor. Si tu host Samba está saturado de CPU por cifrado/firmado, o el servidor Windows de archivos está ahogado por latencia de almacenamiento,
el cliente ve timeouts y resets. La VPN es culpada porque es visible. El almacenamiento es culpado por tradición.
Normalmente es una mezcla.

Regla de ingeniería de fiabilidad: no puedes ajustar lo que no mides. Aquí dejamos de adivinar y empezamos a recopilar evidencia.

Hechos e historial: por qué este problema se repite

• SMB nació con herencia de la era CIFS. Los dialectos antiguos de SMB eran extremadamente parlanchines en enlaces de alta latencia; muchos mitos de «SMB es lento en WAN» vienen de ahí.
• SMB 2.0 (Windows Vista/Server 2008) fue una reescritura importante. Redujo el número de comandos y mejoró el pipelining, haciendo que el comportamiento en WAN fuera menos catastrófico.
• SMB 3.x introdujo cifrado, multichannel y manejos duraderos. Genial para centros de datos; sobre VPN, multichannel puede sorprender si hay múltiples interfaces.
• Los espacios de nombres DFS pueden redirigir clientes en mitad de la operación. Un usuario mapea \\corp\share, pero las referencias pueden enviarlo a un destino diferente con distinta alcanzabilidad sobre la VPN.
• Los fallos de PMTUD son más antiguos que tu sistema de tickets. «Funciona con paquetes pequeños, falla con paquetes grandes» es clásico cuando ICMP está filtrado o mal‑formado.
• Los temporizadores NAT son decisiones de política, no física. Algunos dispositivos mantienen mapeos UDP por segundos, otros por minutos; los clientes en roaming sufren el peor caso rutinariamente.
• Los timeouts de SMB pueden ser más largos que la paciencia de tu VPN. La capa de aplicación puede esperar mientras la capa de red ya ha perdido el estado, haciendo que las fallas parezcan aleatorias.
• Windows intenta reconectar unidades asignadas con insistencia. Eso ayuda hasta que no: obtienes «ruta no encontrada» intermitente, bloqueos en el Explorador y solicitudes de credenciales fantasma.
• Los valores por defecto de seguridad se han endurecido con el tiempo. Deshabilitar firmado/cifrado para «arreglar el rendimiento» a veces funciona—hasta que se convierte en el siguiente hallazgo de auditoría.

Una idea parafraseada a menudo atribuida a James Hamilton (Amazon): Mide primero; de lo contrario solo estarás debatiendo opiniones. Esa mentalidad ahorra días aquí.

Guion de diagnóstico rápido (primero/segundo/tercero)

Cuando alguien dice «la unidad VPN se desconectó otra vez», tienes dos trabajos: restaurar el servicio rápidamente y prevenir la próxima desconexión.
Aquí el orden que encuentra el cuello de botella rápido en vez de hacerlo de manera teatral.

Primero: prueba si es nombre, ruta o transporte

1. Nombre: ¿resuelve el nombre del recurso a la(s) IP esperada(s) mientras está en VPN?
2. Ruta: ¿la ruta hacia esa IP va realmente por el túnel (y es estable)?
3. Transporte: ¿puedes mantener una sesión TCP limpia a 445 sin retransmisiones y resets?

Segundo: busca MTU/MSS y agujeros de fragmentación

1. Prueba la MTU de ruta con DF activado.
2. Busca fragmentación, retransmisiones y patrones de «TCP previous segment not captured» en las capturas.
3. Si ves «funciona para cosas pequeñas, muere en copia grande», asume MTU hasta demostrar lo contrario.

Tercero: revisa temporizadores NAT/firewall y keepalives de la VPN

1. ¿Se cae después de N minutos de inactividad? Eso no es coincidencia; es un temporizador.
2. ¿Se cae cuando los usuarios cambian de red o despiertan el equipo? Eso es pérdida de estado.
3. Arregla con keepalives y temporizadores sensatos antes de tocar registros de SMB.

Cuarto: valida la salud del servidor (CPU, latencia de disco, servicio SMB)

1. En Samba: saturación de CPU, sobrecarga de cifrado y latencia de disco aparecen como timeouts en el cliente.
2. En servidores Windows: los registros de eventos, estadísticas del servidor SMB y la latencia de almacenamiento importan más que las impresiones.

Broma #1: La VPN es como un túnel en un dibujo animado—sólido hasta que miras abajo y te das cuenta de que tienes un problema de MTU.

Tareas prácticas con comandos: demostrar la causa raíz

Estos son comandos reales que puedes ejecutar. Cada uno incluye lo que significa la salida y qué decisión tomar después.
Úsalos como una lista de verificación, no como un bufé.

Task 1: Confirmar resolución DNS del servidor de archivos (cliente Linux)

cr0x@server:~$ getent ahosts fileserver.corp.local
10.60.12.25      STREAM fileserver.corp.local
10.60.12.25      DGRAM  fileserver.corp.local
10.60.12.25      RAW    fileserver.corp.local

Significado: Obtienes un registro A único (IPv4) y está en el rango de la VPN. Bien.
Si ves una IP pública o una subred inesperada, has encontrado una falla de DNS dividido.
Decisión: Arregla DNS (resolvers proporcionados por la VPN, NRPT en Windows, DNS de horizonte dividido). No toques SMB aún.

Task 2: Confirmar DNS en Windows (PowerShell)

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName fileserver.corp.local | Select-Object -First 5"
Name                           Type TTL  Section IPAddress
----                           ---- ---  ------- ---------
fileserver.corp.local          A    60   Answer  10.60.12.25

Significado: Windows está resolviendo lo que esperas.
Si la respuesta cambia entre IPs durante una sesión (especialmente IPv6 vs IPv4), las reconexiones SMB pueden descontrolarse.
Decisión: Estabiliza las respuestas DNS para clientes VPN, o fija un nombre estable usado solo para servicios de archivos.

Task 3: Verificar que la ruta entra por la interfaz VPN (Linux)

cr0x@server:~$ ip route get 10.60.12.25
10.60.12.25 dev wg0 src 10.60.0.14 uid 1000
    cache

Significado: El tráfico usa wg0. Si sale por wlan0 o eth0, las reglas de split‑tunnel están mal.
Decisión: Arregla enrutamiento/policy routing, o ajusta AllowedIPs (WireGuard) / rutas empujadas (OpenVPN).

Task 4: Verificar la ruta en Windows

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -DestinationPrefix 10.60.12.0/24 | Sort-Object RouteMetric | Select-Object -First 3"
ifIndex DestinationPrefix NextHop     RouteMetric PolicyStore
------- ----------------- -------     ----------- -----------
31      10.60.12.0/24     0.0.0.0     5           ActiveStore

Significado: La ruta existe y es preferida (métrica baja). Si la ruta VPN tiene una métrica más alta que la ruta por defecto,
obtendrás «a veces funciona» según el estado de las interfaces.
Decisión: Arregla métricas de interfaz, o establece rutas explícitas para los objetivos SMB.

Task 5: Probar conectividad TCP al puerto SMB 445 (Linux)

cr0x@server:~$ nc -vz -w 3 10.60.12.25 445
Connection to 10.60.12.25 445 port [tcp/microsoft-ds] succeeded!

Significado: El puerto 445 es alcanzable por TCP. Si caduca, tienes problemas de firewall/enrutamiento/VPN.
Si conecta pero SMB aún falla, el problema está en capa superior (auth, dialecto, firmado, timeouts).
Decisión: Si está bloqueado, para y arregla controles de acceso y enrutamiento. No ajustes SMB para compensar un puerto bloqueado.

Task 6: Probar desde Windows con Test-NetConnection

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection -ComputerName 10.60.12.25 -Port 445"
ComputerName     : 10.60.12.25
RemoteAddress    : 10.60.12.25
RemotePort       : 445
InterfaceAlias   : CorpVPN
TcpTestSucceeded : True

Significado: Windows coincide: TCP está abierto en la interfaz VPN.
Decisión: Pasa a diagnósticos de MTU y sesión SMB si los usuarios aún ven desconexiones.

Task 7: Enumerar dialecto y capacidades SMB (smbclient en Linux)

cr0x@server:~$ smbclient -L //10.60.12.25 -U 'CORP\alice' -m SMB3
Password for [CORP\alice]:
        Sharename       Type      Comment
        ---------       ----      -------
        projects        Disk      Projects share
        IPC$            IPC       IPC Service (Samba 4.19.5)
SMB1 disabled -- no workgroup available

Significado: Negociaste SMB3 y SMB1 está deshabilitado (bien). Si el servidor solo permite SMB1, detente y arregla eso antes de nada.
Decisión: Si SMB3 funciona por IP pero no por nombre, vuelves a problemas de DNS/SPN/DFS.

Task 8: Inspeccionar sesiones SMB activas en el cliente Windows

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbConnection | Select-Object ServerName,ShareName,Dialect,NumOpens,ContinuouslyAvailable"
ServerName ShareName Dialect NumOpens ContinuouslyAvailable
---------- --------- ------- -------- ---------------------
10.60.12.25 projects 3.1.1   12       False

Significado: El dialecto es SMB 3.1.1. Si el dialecto es menor al esperado, el rendimiento y la resiliencia pueden degradarse.
Decisión: Si ves reconexiones repetidas o NumOpens que se reinician, correlaciona con logs de VPN y pérdida de paquetes.

Task 9: Encontrar caídas y reconexiones en los logs del cliente SMB de Windows

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-SMBClient/Connectivity' -MaxEvents 5 | Format-Table TimeCreated,Id,LevelDisplayName -Auto"
TimeCreated            Id LevelDisplayName
-----------            -- ----------------
12/28/2025 10:14:22  308 Warning
12/28/2025 10:13:57  310 Warning
12/28/2025 10:13:41  320 Error

Significado: Advertencias/errores en la conectividad SMBClient suelen alinearse con flaps de ruta.
Decisión: Si se correlacionan con roaming de Wi‑Fi o renegociación de VPN, soluciona primero el problema de estado de red.

Task 10: Capturar retransmisiones y resets durante una copia (tcpdump en Linux)

cr0x@server:~$ sudo tcpdump -ni wg0 host 10.60.12.25 and port 445 -vv
tcpdump: listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
10:15:01.112233 IP 10.60.0.14.51422 > 10.60.12.25.445: Flags [P.], seq 129:1189, ack 774, win 501, length 1060
10:15:01.342190 IP 10.60.0.14.51422 > 10.60.12.25.445: Flags [P.], seq 129:1189, ack 774, win 501, length 1060 (retransmission)
10:15:02.001005 IP 10.60.12.25.445 > 10.60.0.14.51422: Flags [R], seq 774, win 0, length 0

Significado: Retransmisiones seguidas por un RST huelen a pérdida de paquetes, problemas de MTU o un middlebox matando estado inactivo.
Decisión: Si las retransmisiones aumentan bajo carga, prioriza MTU/MSS y la investigación de pérdida/jitter. Si aparece RST tras inactividad, prioriza temporizadores NAT/keepalive.

Task 11: Medir MTU de ruta con DF activado (ping en Linux)

cr0x@server:~$ ping -c 3 -M do -s 1360 10.60.12.25
PING 10.60.12.25 (10.60.12.25) 1360(1388) bytes of data.
1368 bytes from 10.60.12.25: icmp_seq=1 ttl=63 time=38.1 ms
1368 bytes from 10.60.12.25: icmp_seq=2 ttl=63 time=37.5 ms
1368 bytes from 10.60.12.25: icmp_seq=3 ttl=63 time=37.9 ms

--- 10.60.12.25 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 37.5/37.8/38.1/0.2 ms

Significado: Carga de 1360 bytes con DF funciona. Aumenta hasta que falle para encontrar el techo.
Si obtienes mensajes de «Frag needed», PMTUD funciona; si simplemente caduca, algo está ocultando ICMP.
Decisión: Si la MTU es menor de lo que asumías, ajusta MSS o reduce la MTU del túnel.

Task 12: Comprobar MTU de la interfaz y del dispositivo VPN (Linux)

cr0x@server:~$ ip link show dev wg0
5: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none

Significado: MTU por defecto de WireGuard ~1420. Si estás encapsulando otra vez (WG sobre UDP sobre algo raro),
1420 puede seguir siendo demasiado alto.
Decisión: Si las pruebas de MTU muestran caídas sobre ~1360, ajusta la MTU de wg0 a menor (p. ej., 1380/1360) o clampa MSS en el borde.

Task 13: Clampear MSS TCP en Linux (firewall de borde) y confirmar contadores

cr0x@server:~$ sudo iptables -t mangle -A FORWARD -o wg0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
cr0x@server:~$ sudo iptables -t mangle -L FORWARD -v -n | head
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in  out  source      destination
   14   840 TCPMSS     tcp  --  *   wg0  0.0.0.0/0   0.0.0.0/0   tcp flags:0x02/0x02 TCPMSS clamp to PMTU

Significado: Los paquetes están golpeando la regla (el contador pkts incrementa). Eso es lo que quieres.
Decisión: Si el clamping estabiliza SMB, mantenlo y documenta. Si no, pasa a pérdida/jitter/temporizadores NAT.

Task 14: Comprobar el timing del handshake de WireGuard (lado servidor)

cr0x@server:~$ sudo wg show
interface: wg0
  public key: 0aBc...redacted
  listening port: 51820

peer: 7XyZ...redacted
  endpoint: 203.0.113.44:54321
  allowed ips: 10.60.0.14/32
  latest handshake: 1 minute, 12 seconds ago
  transfer: 1.82 GiB received, 2.10 GiB sent

Significado: Si «latest handshake» está obsoleto durante una sesión activa, algo está rompiendo la alcanzabilidad UDP.
Decisión: Ajusta PersistentKeepalive en clientes detrás de NAT; ajusta temporizadores de firewall.

Task 15: Confirmar que el servidor SMB está escuchando y no está bloqueado (Samba en Linux)

cr0x@server:~$ sudo ss -ltnp | grep ':445 '
LISTEN 0      128          0.0.0.0:445        0.0.0.0:*    users:(("smbd",pid=1214,fd=45))

Significado: smbd está escuchando. Si falta, el problema es la salud del servicio o reglas de bind en el servidor.
Decisión: Si está escuchando, revisa logs de smbd y presión de recursos del sistema.

Task 16: Comprobar estado de Samba y procesos atascados

cr0x@server:~$ sudo systemctl status smbd --no-pager
● smbd.service - Samba SMB Daemon
     Loaded: loaded (/lib/systemd/system/smbd.service; enabled; preset: enabled)
     Active: active (running) since Sun 2025-12-28 09:12:06 UTC; 1h 3min ago
       Docs: man:smbd(8)
   Main PID: 1214 (smbd)
     Status: "smbd: ready to serve connections..."
      Tasks: 5 (limit: 18972)
     Memory: 92.5M
        CPU: 3min 12s

Significado: El servicio está sano. Si se está reiniciando, fallando o registrando errores de auth, ese es tu problema real.
Decisión: Si el daemon es estable, céntrate en la ruta de red, MTU y comportamiento del cliente.

Task 17: Medir latencia de disco en el servidor (Linux)

cr0x@server:~$ iostat -x 1 3
Linux 6.8.0 (nas01)  12/28/2025  _x86_64_ (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.31    0.00    2.14    7.55    0.00   86.00

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
nvme0n1          85.0    40.0  6120.0  3200.0   2.10   0.22  2.8

Significado: await es bajo; el disco no es el cuello de botella.
Si await es decenas/centenas de ms bajo carga, los clientes pueden sufrir timeouts y reconectarse.
Decisión: Si la latencia de almacenamiento es mala, arregla el almacenamiento (profundidad de cola, contención, discos fallando, pool saturado) antes de culpar a la VPN.

Task 18: Verificar comportamiento Kerberos vs NTLM (cliente Windows)

cr0x@server:~$ powershell -NoProfile -Command "klist"
Current LogonId is 0:0x3e7

Cached Tickets: (3)
#0>     Client: alice @ CORP.LOCAL
        Server: krbtgt/CORP.LOCAL @ CORP.LOCAL
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x60a10000 -> forwardable renewable initial pre_authent name_canonicalize

Significado: Existen tickets Kerberos. Si el acceso a la compartición falla solo por nombre pero funciona por IP, SPN y Kerberos pueden estar involucrados.
Decisión: Confirma SPN correctos para el nombre del servidor de archivos y asegúrate de que la VPN resuelva a los controladores de dominio.

Ajustes de red que evitan desconexiones (MTU, MSS, NAT, roaming)

Elige una MTU aburrida y hazla cumplir

La encapsulación VPN reduce la MTU efectiva. Luego alguien apila VPN sobre VPN, o añade PPPoE, o conectan por hotspot celular.
Si no controlas la MTU, eventualmente enviarás por una ruta que silenciosamente deja caer paquetes grandes.

Mi sesgo: si no puedes garantizar que PMTUD funcione de extremo a extremo, clampéa MSS en el borde VPN. No es glamuroso, pero previene la clase de tickets «una escritura grande mata la sesión».
En WireGuard, ajustar la MTU de la interfaz también es efectivo, pero el clamping ayuda cuando los clientes varían ampliamente.

Deja de bloquear ICMP como si fuera 2004

«Fragmentation needed» de ICMP es parte de cómo Internet sigue funcionando. Bloquearlo te obliga a adivinar la MTU y cruzar los dedos.
Si seguridad insiste, aún puedes clamping MSS—pero entiende que estás eligiendo deuda operativa.

Trata al NAT como si fuera enemigo (porque lo es)

Si la VPN usa UDP, configura keepalives para clientes detrás de NAT. El PersistentKeepalive de WireGuard existe por una razón.
OpenVPN tiene opciones de keepalive también. IPsec NAT‑T a menudo necesita ajustes de DPD.

Síntomas que gritan «timeout NAT»: caída tras un periodo predecible de inactividad, recuperación inmediata tras reconexión y fallos sobre todo en «redes de invitado»
o móviles.

Roaming y suspensión: trátalos como desconexiones, no como espasmos

Los portátiles se suspenden. El Wi‑Fi hace roaming. Las IP cambian. Las sesiones SMB no aman ninguna de esas cosas.
Si los usuarios son móviles, apunta a:

• VPN que se reconecte rápido y rote claves sin problema
• Keepalive ajustado para NAT
• DNS y rutas estables después de reconectar
• Características SMB como manejos duraderos cuando estén disponibles (dependiente del servidor)

Evita el split tunneling para comparticiones de archivos a menos que seas disciplinado

El split tunneling es una decisión de política disfrazada de decisión de red. Puede estar bien, pero solo si:
el rango de IP objetivo SMB es explícito y estable, las referencias DFS están controladas y el DNS es de horizonte dividido.
Si no, obtendrás la peor clase de incidente: intermitente, específico por usuario e imposible de reproducir desde tu escritorio.

Broma #2: El split tunneling es como pedir «medio picante» en un restaurante—cada quien lo interpreta diferente, y te arrepentirás después.

Ajustes de SMB/Samba que evitan berrinches

No «optimices» degradando la seguridad del protocolo

Deshabilitar firmado o cifrado para que SMB «funcione mejor sobre VPN» suele ser una trampa. Puede reducir el coste de CPU, claro.
Pero también cambias el comportamiento ante fallos, creas problemas de cumplimiento y a veces empeoras las reconexiones al alterar rutas de autenticación.
Ajusta la red primero y luego decide si la sobrecarga criptográfica es realmente tu cuello de botella.

Prefiere SMB 3.1.1, deshabilita SMB1 en todas partes

SMB1 es inseguro y frágil. Además, se comporta mal en enlaces de alta latencia. Si algo en 2025 todavía necesita SMB1,
ponlo en un segmento de red cuarentenado y planifica su retirada en serio.

Ten cuidado con SMB Multichannel sobre VPN

SMB Multichannel puede abrir múltiples conexiones TCP a través de varias NIC. Sobre VPN, clientes con múltiples interfaces pueden hacer cosas raras:
un canal va por el túnel, otro intenta ir directo y entonces tienes stalls y tormentas de reconexión.

Si ves que multichannel causa inestabilidad, desactívalo en clientes o servidores de forma controlada.
Pero no lo hagas primero. Demuéstralo con inspección de conexiones SMB y capturas de paquetes.

Detalles de Samba: mantén logs útiles, no ruidosos

En Samba, activa suficiente logging para correlacionar desconexiones, fallos de autenticación y negociación de firmado/cifrado.
Pero no ejecutes debug nivel 10 en producción durante horario laboral a menos que te guste llenar discos y perder el foco del incidente real.

Comprende la carga de trabajo: documentos Office vs archivos multimedia vs artefactos de build

El dolor de SMB está moldeado por la carga. Una copia secuencial grande es sensible a MTU y throughput. Una carpeta llena de archivos pequeños es sensible a latencia.
Los documentos Office son muy dependientes de metadata y adoran locks/leases. Los builds generan tormentas de opens/closes.

Si los usuarios se quejan «abrir una carpeta tarda 30 segundos» pero «copiar un archivo grande está bien», eso es latencia + operaciones parlanchinas, no ancho de banda bruto.
Eso te apunta a RTT/jitter de la VPN, demoras de DNS y sobrecosto del firmado SMB—no al throughput de disco.

Tres microhistorias corporativas (cómo los equipos realmente se queman)

Microhistoria 1: El incidente causado por una suposición equivocada

Una empresa mediana desplegó un cliente VPN nuevo y brillante. El grupo piloto reportó éxito: las unidades mapeadas funcionaban, la navegación de archivos iba bien
y la cola de helpdesk no explotó. El despliegue alcanzó a toda la compañía un lunes.

El martes, finanzas empezó a recibir errores «la ruta de red no se encontró» alrededor de la hora de almuerzo. Ingeniería no.
La primera suposición fue predecible: «El servidor de archivos está sobrecargado.» El equipo añadió CPU a la VM y la movió a almacenamiento más rápido.
Nada cambió. Los errores siguieron apareciendo, mayormente para finanzas y RR. HH.

La segunda suposición fue más sutil: «Si la VPN está conectada, el DNS es correcto.» No lo era.
La VPN empujaba una lista de servidores DNS, pero Windows mantenía los servidores DNS del Wi‑Fi con mayor prioridad en algunos clientes debido a métricas de interfaz.
Así que los usuarios resolvían el espacio de nombres DFS a un objetivo que no era alcanzable vía split‑tunnel, intermitentemente.

La solución no fue más computación. Fue control de enrutamiento y nombres: corregir métricas de interfaz, forzar comportamiento de DNS dividido
y fijar la selección de destino DFS para clientes VPN. La «inestabilidad del servidor» desapareció.
El postmortem fue corto y doloroso: asumieron que «conectado» significaba «ruteado correctamente». No lo es.

Microhistoria 2: La optimización que salió mal

Otra organización tenía lentitud crónica de SMB sobre VPN IPsec. Un ingeniero decidió «optimizar» aumentando la MTU del túnel
y deshabilitando el clamping MSS. La idea: menos paquetes, mejor throughput. Funcionó en su laboratorio.

En producción, usuarios remotos en ISPs domésticos empezaron a perder sesiones durante transferencias grandes.
Las operaciones con archivos pequeños estaban bien, lo que hacía parecer un bug de aplicación. Los logs de VPN estaban mayormente limpios.
Los logs SMB mostraban desconexiones y reconexiones sin errores de servidor obvios.

Una captura de paquetes finalmente mostró lo que pasaba: segmentos TCP más grandes eran eliminados en algún punto entre el ISP y la puerta de enlace IPsec.
Los mensajes ICMP «frag needed» no regresaban (filtrados por un middlebox), así que PMTUD no podía salvarlos.
La MTU más alta aumentó la frecuencia de paquetes sobredimensionados, convirtiendo un caso raro en un problema diario.

Volver a una MTU conservadora más clamping MSS lo arregló de inmediato. El rendimiento mejoró también—no porque la MTU fuera «más rápida»,
sino porque las retransmisiones se detuvieron. La optimización era válida en una red limpia. El mundo real no es una red limpia.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Una empresa global con muchos teletrabajadores tenía una política: cada recurso de archivos remoto tenía dos vías de acceso—SMB sobre VPN para workflows legados
y un servicio documental web para todo lo demás. No por amor a la complejidad, sino por respeto a lo frágiles que son los clientes en roaming.

También tenían un runbook estándar: comprobar resolución DNS contra los resolvers de VPN, validar métricas de ruta, ejecutar una prueba MTU DF ping
e inspeccionar logs de conectividad SMB del cliente. Nada sofisticado. Solo consistencia.

Un día, las quejas «la ruta de red no se encontró» se dispararon después de una actualización de firewall. El runbook lo encontró en minutos:
el tipo ICMP 3 código 4 (fragmentation needed) estaba siendo bloqueado por una política nueva. La detección de MTU se rompió. Las escrituras SMB grandes fallaron.

Como la organización tenía una regla estándar de clamping MSS en el borde (sí, aburrido), el impacto se limitó a un subconjunto de usuarios cuyo camino evitaba ese borde.
Arreglaron la política del firewall, extendieron la cobertura de clamping y el incidente terminó sin una noche en vela heroica.
La victoria no fue genialidad. Fue consistencia.

Errores comunes: síntoma → causa raíz → solución

«La ruta de red no se encontró» aparece solo después de copiar archivos grandes

Causa raíz: agujero MTU / fallo de PMTUD; paquetes sobredimensionados eliminados; TCP se queda y luego hace reset.

Solución: Clampear MSS en el borde VPN o reducir la MTU del túnel; permitir ICMP fragmentation‑needed; verificar con pings DF y capturas.

La unidad mapeada se reconecta repetidamente, mayormente después de periodos de inactividad

Causa raíz: timeout de inactividad de NAT/firewall que elimina el mapeo UDP o el estado TCP; keepalive de VPN muy espaciado.

Solución: Configurar keepalives en la VPN (PersistentKeepalive de WireGuard; keepalive de OpenVPN); aumentar timeouts de estado en firewalls de borde donde sea posible.

Funciona por IP, falla por nombre (o ruta DFS)

Causa raíz: fallo de DNS de horizonte dividido, orden de sufijos incorrecto, o referencias DFS apuntando a destinos inalcanzables; a veces mismatch de SPN Kerberos.

Solución: Arreglar DNS en la VPN, asegurar alcance de DC, validar SPNs, controlar referencias DFS para clientes VPN.

Solo algunos usuarios fallan, y cambia con la ubicación

Causa raíz: métricas de ruta, fugas de split‑tunnel, cliente usando DNS local, o peculiaridades de MTU del ISP.

Solución: Forzar configuración consistente de clientes (rutas, DNS, métricas de interfaz) y aplicar clamping MSS en un punto de estrangulamiento consistente.

Abrir carpetas es lento; copiar un archivo grande está bien

Causa raíz: latencia y operaciones parlanchinas de SMB; a veces antivirus y sobrecosto de firmado SMB.

Solución: Mejorar RTT/jitter (mejores endpoints VPN, POPs más cercanos), revisar coste CPU de firmado/cifrado SMB, considerar mover workflows muy parlanchines fuera de SMB.

Desconexiones aleatorias durante roaming Wi‑Fi o suspensión/activación del portátil

Causa raíz: resets del transporte VPN; cambios de IP; rutas obsoletas; sesión SMB que no sobrevive transiciones de red.

Solución: Usar cliente VPN con reconexión rápida, keepalive ajustado y considerar VPN «always‑on»; educar a los usuarios que la suspensión es una desconexión.

SMB funciona, pero el rendimiento es terrible tras habilitar cifrado en todas partes

Causa raíz: cuello de botella de CPU en cliente o servidor por cifrado/firmado; agravado por alta latencia.

Solución: Medir CPU, confirmar AES‑NI/aceleración criptográfica, escalar servidores de archivos, o habilitar cifrado selectivamente según zonas de riesgo (con aprobación de seguridad).

Tormentas de desconexión cuando los clientes tienen múltiples interfaces

Causa raíz: SMB Multichannel intentando rutas que no son consistentes sobre la VPN; enrutamiento asimétrico.

Solución: Validar con inspección de conexiones SMB; deshabilitar multichannel donde cause inestabilidad; asegurar que todas las rutas SMB permanezcan dentro del túnel.

Listas de verificación / plan paso a paso

Paso a paso: estabilizar SMB sobre VPN en producción

1. Define el objetivo: lista servidores de archivos, espacios de nombres DFS, subredes y si se permite split‑tunnel.
   Si no puedes listarlo, no puedes enrutarlo.
2. Haz DNS determinista para clientes VPN: resolvers proporcionados por la VPN, sufijos correctos y respuestas consistentes.
   Prueba tanto resolución por nombre como por ruta DFS.
3. Haz el enrutamiento determinista: rutas explícitas para subredes SMB por la VPN; verifica métricas para que la ruta VPN gane.
4. Arregla MTU de la forma aburrida: permite PMTUD (ICMP frag‑needed), o clampéa TCP MSS en el borde VPN. Valida con pings DF.
5. Configura keepalives para clientes NAT: elige un intervalo que sobreviva los timeouts típicos de NAT (a menudo 20–30 segundos en redes tercas).
6. Instrumenta antes de tunear SMB: recopila logs de conectividad SMB cliente, logs de VPN y captura de paquetes durante una reproducción.
7. Revisa salud del servidor: CPU, memoria, latencia de disco y estabilidad del servicio SMB. Arregla cuellos de botella reales.
8. Controla referencias DFS: asegúrate de que los clientes VPN reciban referencias a destinos alcanzables, idealmente en la misma zona de red.
9. Evalúa ajustes de seguridad SMB con datos: mantén firmado/cifrado a menos que puedas demostrar cuello de botella de CPU y tengas una decisión de riesgo aprobada.
10. Despliega cambios de forma segura: grupo canario, criterios de éxito medibles (tasa de caídas, recuento de reconexiones, tasa de éxito de copias grandes), plan de rollback.

Checklist: qué capturar durante un incidente real

• IP del cliente, nombre de la interfaz VPN y endpoint del túnel
• IPs resueltas para el nombre de la compartición y el espacio DFS en el momento del fallo
• Snapshot de la tabla de rutas (cliente) y rutas/políticas empujadas por la VPN
• Resultados de pruebas MTU (máximo ping DF que funciona)
• Captura de paquetes en torno al fallo (RST? retransmisiones?)
• Eventos de Conectividad del SMBClient en Windows o logs de Samba alrededor del timestamp
• Métricas de CPU y latencia de disco del servidor durante la ventana del fallo

Preguntas frecuentes

1) ¿Por qué SMB parece estar bien por un tiempo y luego se cae?

Porque muchas roturas son basadas en temporizadores (idles NAT/firewall) o basadas en eventos (roaming Wi‑Fi, rekey de VPN, suspensión del portátil).
SMB tiene estado; cuando el estado subyacente desaparece, la siguiente operación desencadena el fallo.

2) ¿Es «la ruta de red no se encontró» siempre un problema de DNS?

No. A menudo es DNS, pero también puede ser selección de ruta, resets TCP o puerto 445 bloqueado.
Trátalo como «nombre/ruta/transporte» hasta que hayas demostrado cuál es.

3) ¿Deberíamos usar SMB sobre VPN en absoluto?

Si debes soportar workflows legados, sí—pero mantén expectativas realistas.
Para usuarios en roaming, considera trasladar flujos de colaboración a servicios diseñados para conectividad intermitente.
Mantén SMB para cargas que realmente lo necesiten.

4) ¿Qué MTU debo poner?

No hay un número universalmente correcto. Mide la MTU de tu ruta (pruebas DF ping) y elige un valor conservador.
Si no puedes garantizar que ICMP funcione, clampea MSS y mantén la MTU del túnel moderada.

5) ¿El cifrado SMB provoca desconexiones?

Puede contribuir indirectamente: mayor uso de CPU aumenta tiempo de respuesta; sobre enlaces de alta latencia, eso puede empujarte a timeouts.
Mide CPU en cliente/servidor durante transferencias antes de culpar al cifrado.

6) ¿Por qué funciona por IP pero no por nombre?

El acceso por nombre dispara resolución DNS, chequeos SPN/Kerberos y comportamiento DFS. El acceso por IP omite partes de eso.
Esa diferencia es una pista diagnóstica: céntrate en DNS e identidad (Kerberos/SPN), no en pérdida de paquetes.

7) ¿Deberíamos deshabilitar SMB Multichannel sobre VPN?

Solo si puedes probar que está creando rutas inestables o asimétricas.
Multichannel es excelente en redes estables. Sobre VPN con múltiples interfaces cliente, puede ser caótico.
Valida con inspección de conexiones SMB primero.

8) ¿Cuál es el cambio de mayor valor para la estabilidad?

Si sufres caídas aleatorias: keepalives y buena higiene MTU/MSS en el borde VPN.
Estas dos medidas eliminan una gran parte de los tickets de «desconexión misteriosa».

9) ¿Por qué abrir carpetas se siente peor que copiar archivos?

Navegar carpetas desencadena muchas operaciones SMB pequeñas: metadata, opens, closes, checks de atributos.
Alto RTT y jitter multiplican ese dolor. Las transferencias secuenciales grandes amortizan mejor la latencia.

10) ¿Podemos arreglar esto solo con tweaks del registro de Windows?

A veces puedes enmascarar síntomas. Pero si tu red pierde estado o oculta paquetes, los tweaks del registro SMB son mayormente una forma de retrasar la falla.
Arregla el transporte primero.

Conclusión: siguientes pasos que puedes dar esta semana

SMB sobre VPN puede ser estable, pero solo si lo tratas como una dependencia de producción en lugar de una característica de conveniencia.
Las fallas recurrentes—agujeros MTU, timeouts inactivos NAT y deriva de DNS/enrutamiento por split—no son misteriosas. Solo están poco medidas.

Pasos prácticos:

1. Ejecuta el guion de diagnóstico rápido en un cliente afectado y captura evidencia (DNS, ruta, reachability TCP, pruebas MTU DF).
2. Implementa clamping MSS (o una MTU de túnel conservadora) en el punto de estrangulamiento VPN y valida con una prueba de copia de archivos grandes.
3. Habilita y ajusta keepalives de VPN para clientes detrás de NAT; confirma que las desconexiones ya no ocurren tras inactividad.
4. Audita referencias DFS y rutas split‑tunnel para que «la compartición» siempre signifique el mismo objetivo alcanzable.
5. Establece un pequeño runbook y exige su uso en tickets: sin logs, no hay adivinanzas.

Haz esas cinco cosas y «la ruta de red no se encontró» se convertirá en un evento raro y explicable en lugar de un ritual semanal.