No hay nada que haga que una oficina remota odie al equipo de TI más rápido que una unidad asignada que se desconecta a mitad de guardar. A los usuarios no les importa que tengas una “SD‑WAN moderna” o que el panel del cortafuegos esté en verde. Les importa que Excel tardó 45 segundos en abrirse, después se congeló y luego preguntó si querían guardar una copia de recuperación llamada ~$Budget_FINAL_v7_REALFINAL.xlsx.
SMB entre oficinas puede ser estable. Pero tienes que tratarlo como un sistema distribuido de producción, no como “una letra de unidad sobre un túnel”. El túnel es solo el comienzo: MTU, DNS, enrutamiento, timeouts de firewall, dialecto/funcionalidades SMB y el backend de almacenamiento conspiran para crear desconexiones que parecen aleatorias. No lo son. Simplemente están poco instrumentadas.
Qué falla realmente cuando SMB atraviesa una VPN
SMB (el protocolo de compartición de archivos de Windows) es hablador. SMB3 moderno es muy superior a los viejos días malos, pero aún realiza muchas solicitudes/respuestas pequeñas: negociar, autenticar, tree connect, create/open, lock, read/write, consultas de metadatos, enumeración de directorios, opportunistic locks, durable handles, leases. Cada una de estas operaciones es sensible a latencia, pérdida de paquetes y reinicios de estado.
Cuando mueves SMB de una LAN a algo “parecido a LAN pero no tanto” (dos oficinas con un túnel entre ellas), tus modos de fallo se multiplican:
- La latencia agrava la verbosidad. La navegación de directorios y las secuencias de apertura de archivos se convierten en momentos de “¿por qué está pensando?”.
- La pérdida de paquetes se traduce en desconexiones. No porque SMB sea frágil, sino porque las cosas con estado (túneles VPN, tablas NAT, sesiones de firewall) son frágiles cuando se pierden o reordenan paquetes.
- Los problemas de Path MTU causan bloqueos que parecen congelamientos de la aplicación. Marcos jumbo y encapsulación VPN: un emparejamiento clásico para “funciona con archivos pequeños, cuelga con los grandes”.
- Los timeouts de sesión se activan por archivos abiertos pero inactivos. Los usuarios dejan archivos abiertos durante horas. SMB mantiene una sesión. El dispositivo del túnel puede no hacerlo.
- Confusión de DNS y autenticación entre sitios. Kerberos es exigente con la hora, el DNS y los SPN. Cuando cae a NTLM sobre un enlace con latencia, pagas en timeouts y avisos al usuario.
- Las funciones de seguridad pueden costarte rendimiento. Firma y cifrado SMB son buenas herramientas. También son multiplicadores de CPU y latencia si se activan sin criterio.
El error operativo es asumir que SMB es “solo TCP/445”. No lo es. Es un protocolo de aplicación con estado cuya experiencia de usuario está dominada por la parte más lenta de tu sistema. A menudo esa parte no es el ancho de banda del VPN. Es las IOPS de almacenamiento, la tabla de sesiones del firewall o un MTU mal dimensionado.
Hay una frase de Werner Vogels que vale la pena mantener como brújula: Everything fails, all the time
(la idea parafraseada). SMB entre oficinas es elegir qué fallos son gráciles y cuáles se convierten en “la unidad compartida está caída”.
Hechos interesantes y contexto histórico
Un poco de contexto ayuda porque SMB arrastra decisiones de diseño de décadas. Algunos hechos concretos muestran por qué “es inestable” suele significar “lo estamos usando fuera de su zona de confort”.
- SMB nació en los años 80. Se diseñó para redes pequeñas y locales donde la latencia era básicamente “¿qué latencia?”.
- CIFS no fue tanto un protocolo nuevo como una foto de la era del marketing. “CIFS” suele referirse al comportamiento de la era SMB1; no es lo que quieres sobre una WAN hoy.
- SMB2 (era Vista/Server 2008) fue una reescritura importante. Redujo la verbosidad y mejoró el pipelining, lo cual importa mucho sobre VPN.
- SMB3 (Windows 8/Server 2012) añadió durable handles y multichannel. Los durable handles son importantes para problemas de red transitorios; multichannel puede ayudar en servidores con múltiples NIC, pero también puede confundir redes con enrutamiento asimétrico.
- El cifrado SMB llegó en SMB3. Es por sesión y por recurso compartido y se puede negociar; puede protegerte de “el VPN está caído pero el recurso compartido sigue expuesto”—si tu enrutamiento es raro—pero no es gratuito.
- Oplocks y leases son clave para el rendimiento de SMB. Reducen los viajes de ida y vuelta al cachear. También pueden crear dramas de “archivo bloqueado” con aplicaciones mal comportadas, especialmente sobre enlaces intermitentes.
- DFS Namespaces existe en gran parte porque “un nombre de servidor de archivos es una responsabilidad”. Ofrece indirectividad: los clientes mapean a un namespace, no a un servidor específico, permitiendo migración y direccionamiento multi-sede.
- Windows tiene “Archivos sin conexión” (Client-Side Caching) desde hace tiempo. Está poco usado porque se puede configurar mal, pero es una de las respuestas sensatas a “usuarios editando documentos sobre una WAN”.
Arquitecturas que funcionan (y las que parecen baratas pero no lo son)
Opción A: Servidor central + VPN sitio a sitio (lo por defecto)
Es lo más común: un servidor de archivos en HQ, las sucursales se conectan por IPsec/OpenVPN/WireGuard, los usuarios mapean unidades.
Cuando funciona: la latencia es moderada (dígitos simples a decenas bajas de ms), el VPN es estable, tu firewall no mata agresivamente sesiones inactivas y tu almacenamiento es lo bastante rápido para que “abrir archivo” no dependa del disco.
Cuando falla: latencia más alta, pérdida de paquetes, usuarios abriendo árboles enormes de carpetas, CAD/Adobe/PST de Outlook sobre la compartición, o cualquier app que haga muchas llamadas de metadatos. También: túneles que flaquean o rekeyean demasiado agresivamente.
Opción B: DFS Namespace + DFS Replication (para home directories y compartidos que toleran consistencia eventual)
Si tienes dos oficinas que necesitan el mismo compartido de equipo y no requieren semánticas estrictas de escritor único, DFS‑N + DFS‑R puede reducir el tráfico SMB entre sitios manteniendo réplicas locales. Los usuarios acceden al servidor local la mayor parte del tiempo.
Compromiso: DFS‑R no es un sistema de archivos distribuido transaccional. Ocurren conflictos. Archivos grandes replican despacio. Ciertos patrones de archivo (muchos archivos pequeños, renombrados frecuentes) pueden ser dolorosos.
Opción C: Servidor de archivos en la sucursal con caching (la versión adulta de “mantener datos locales”)
Coloca un servidor (o NAS) en la sucursal y usa un mecanismo diseñado para WAN: BranchCache, caching de terceros, o incluso una plataforma de colaboración donde no se requieran semánticas idénticas a un share SMB.
Mi opinión: si tienes más de ~20 usuarios en una sucursal que trabajan activamente con documentos todo el día, una caché/replica local suele ser más barato que quemar horas de ingenieros haciendo que SMB se parezca a LAN sobre WAN.
Opción D: Deja de usar SMB como herramienta de colaboración WAN
Sí, en serio. SMB es excelente dentro de un sitio. Entre sitios, a menudo es la abstracción equivocada. Para colaboración entre oficinas en documentos, considera una plataforma de sync, un DMS, o al menos “edición local con sincronización”. Mantén SMB para home drives, shares de aplicaciones y flujos on‑prem donde brilla.
Broma #1: SMB sobre una VPN inestable es como una relación a distancia: puede funcionar, pero cada paquete perdido se convierte en un problema de confianza.
Guía rápida de diagnóstico
Este es el orden de triaje que encuentra el cuello de botella más rápido en entornos reales. No empieces a alternar claves del registro de SMB como si jugaras a golpear‑moles.
Primero: ¿es el túnel o el servidor?
- Revisa la estabilidad del túnel: rekeys, flaps, eventos DPD/keepalive, pérdida de paquetes.
- Revisa la salud del servidor: CPU, latencia de disco, errores de NIC, estadísticas del servidor SMB.
- Revisa síntomas del cliente: ¿se desconectan todos los usuarios o solo ciertos subnets/clientes?
Segundo: MTU y fragmentación
- Busca “archivos pequeños OK, archivos grandes se bloquean”. Eso es MTU/MSS hasta que se demuestre lo contrario.
- Confirma el Path MTU end‑to‑end a través de la encapsulación VPN.
- Ajusta el MSS en los bordes del VPN si no puedes garantizar PMTUD.
Tercero: DNS, AD y hora
- Kerberos odia la deriva de tiempo y las rarezas de DNS.
- Confirma que los clientes de la sucursal resuelvan el servidor de archivos a la IP prevista, no a un registro obsoleto o a una dirección pública.
- Verifica la alcanzabilidad de controladores de dominio y el mapeo sitio/subred si estás en AD.
Cuarto: timeouts de sesión y tablas de estado
- Los firewalls y dispositivos NAT matan sesiones “inactivas” mientras SMB cree que siguen vivas.
- Los dispositivos VPN que rekeyean agresivamente pueden romper flujos TCP de larga duración.
- Busca patrones: desconexión después de exactamente N minutos.
Quinto: desajuste de características SMB
- Firma/cifrado SMB + CPU débil = dolor.
- Multichannel sobre VPN puede ser sorprendente si existen múltiples rutas o si NAT cambia.
- OpLocks/leases pueden ser una ventaja o una fuente de bloqueos según las aplicaciones.
Tareas prácticas: comandos, salidas y decisiones
Abajo hay tareas reales que puedes ejecutar durante un incidente o en un proyecto de “hacerlo estable”. Cada una incluye el comando, salida de ejemplo, qué significa y qué decisión tomar después. Una mezcla de Linux (para VPN/firewall/NAS) y Windows (para clientes/servidores SMB) es intencional porque tu entorno nunca es puro.
Tarea 1: Probar si el túnel está flaqueando (Linux, ejemplo WireGuard)
cr0x@server:~$ sudo wg show
interface: wg0
public key: zX2...abc=
listening port: 51820
peer: 8kF...def=
endpoint: 203.0.113.10:51820
allowed ips: 10.20.0.0/16
latest handshake: 18 seconds ago
transfer: 22.41 GiB received, 19.88 GiB sent
persistent keepalive: every 25 seconds
Qué significa: “latest handshake” muestra vida reciente. Si esto salta a minutos/horas durante quejas de usuarios, tu “problema SMB” es en realidad un problema de vitalidad del túnel.
Decisión: Si el handshake está obsoleto durante las quejas, arregla el enrutamiento/keepalive/alcanzabilidad del borde del túnel antes de tocar SMB.
Tarea 2: Revisar rekey y eventos DPD de IPsec (ejemplo strongSwan)
cr0x@server:~$ sudo journalctl -u strongswan --since "2 hours ago" | egrep -i "rekey|deleting|dpd|proposal" | tail -n 20
Dec 27 09:11:03 gw1 charon[1187]: 09[KNL] deleting IKE_SA vpn-to-branch[12] between 198.51.100.2...203.0.113.10
Dec 27 09:11:03 gw1 charon[1187]: 09[IKE] initiating IKE_SA vpn-to-branch[13] to 203.0.113.10
Dec 27 09:11:10 gw1 charon[1187]: 09[IKE] IKE_SA vpn-to-branch[13] established between 198.51.100.2...203.0.113.10
Dec 27 09:12:12 gw1 charon[1187]: 11[NET] sending DPD request
Dec 27 09:12:22 gw1 charon[1187]: 11[NET] DPD response received
Qué significa: Ciclos frecuentes de delete/initiate pueden derribar flujos TCP (hola, SMB). DPD en sí está bien; renegociación constante no lo está.
Decisión: Si ves rekeys cada pocos minutos o eliminaciones inesperadas, ajusta lifetimes, configuraciones de reautenticación, keepalives NAT e investiga pérdida de paquetes upstream.
Tarea 3: Confirmar simetría de enrutamiento (Linux)
cr0x@server:~$ ip route get 10.20.5.25
10.20.5.25 dev wg0 src 10.10.0.1 uid 0
cache
Qué significa: El gateway enviará tráfico a 10.20.5.25 vía la interfaz VPN. Si elige una interfaz WAN en su lugar, las respuestas saldrán por el camino equivocado y SMB se “caerá” aleatoriamente.
Decisión: Arregla tablas de enrutamiento/policy routing para que las respuestas a subredes de sucursales retornen por el túnel.
Tarea 4: Encontrar MTU en la ruta (Linux ping con DF)
cr0x@server:~$ ping -M do -s 1372 10.20.5.25 -c 3
PING 10.20.5.25 (10.20.5.25) 1372(1400) bytes of data.
1380 bytes from 10.20.5.25: icmp_seq=1 ttl=63 time=18.4 ms
1380 bytes from 10.20.5.25: icmp_seq=2 ttl=63 time=18.7 ms
1380 bytes from 10.20.5.25: icmp_seq=3 ttl=63 time=18.3 ms
--- 10.20.5.25 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
Qué significa: Paquetes de 1400 bytes sobreviven sin fragmentación. Si pruebas un tamaño mayor y obtienes “Frag needed”, tu MTU efectiva es menor de lo que creías.
Decisión: Ajusta la MTU de la interfaz VPN en consecuencia y/o aplica clamp TCP MSS para que SMB no intente segmentos sobredimensionados.
Tarea 5: Revisar TCP MSS clamping (ejemplo iptables Linux)
cr0x@server:~$ sudo iptables -t mangle -S | grep -i tcp-mss
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Qué significa: El clamp MSS está presente para paquetes SYN TCP reenviados, lo que ayuda a evitar blackholes PMTU a través de VPNs.
Decisión: Si falta y tienes problemas de MTU, añádelo en el borde del VPN (o establece MSS explícitamente según tu encapsulación).
Tarea 6: Medir pérdida/jitter rápidamente (Linux, mtr)
cr0x@server:~$ mtr -rwzc 50 10.20.5.25
Start: 2025-12-27T09:20:02+0000
HOST: gw1 Loss% Snt Last Avg Best Wrst StDev
1.|-- 10.10.0.254 0.0% 50 0.4 0.5 0.3 1.2 0.2
2.|-- 10.255.0.2 0.0% 50 18.5 18.9 17.8 31.2 1.9
3.|-- 10.20.5.25 2.0% 50 19.0 19.4 18.2 33.4 2.4
Qué significa: 2% de pérdida hacia el host de la sucursal es suficiente para que SMB parezca embrujado, especialmente en cargas con muchos metadatos.
Decisión: Trata la pérdida/jitter sostenida como un incidente de red primero. El tuning de SMB no arreglará las leyes físicas.
Tarea 7: Verificar que el firewall no mata flujos inactivos (conntrack Linux)
cr0x@server:~$ sudo conntrack -L | grep -E "dport=445|sport=445" | head
tcp 6 431992 ESTABLISHED src=10.20.5.25 dst=10.10.1.50 sport=50322 dport=445 src=10.10.1.50 dst=10.20.5.25 sport=445 dport=50322 [ASSURED] mark=0 use=1
Qué significa: La entrada de estado existe y muestra un valor de timeout largo (aquí ~5 días). Si tu timeout es pequeño (minutos), verás desconexiones tras periodos inactivos.
Decisión: Aumenta los timeouts TCP established en el firewall/dispositivo VPN, o asegura keepalives para sesiones SMB de larga duración.
Tarea 8: En cliente Windows, confirmar dialecto SMB y cifrado/firma
cr0x@server:~$ powershell -NoProfile -Command "Get-SmbConnection | ft ServerName,ShareName,Dialect,Encrypted,SigningRequired"
ServerName ShareName Dialect Encrypted SigningRequired
---------- --------- ------ --------- ---------------
FS-HQ Projects 3.1.1 False True
Qué significa: Dialecto 3.1.1 es moderno. Firma requerida está activada; cifrado está desactivado para este recurso.
Decisión: Si ves Dialect 1.0 o 2.0 inesperadamente, corrige la negociación heredada. Si el cifrado está activado y el rendimiento es terrible, mide CPU y considera cifrado selectivo.
Tarea 9: Revisar configuración del cliente SMB (Windows)
cr0x@server:~$ powershell -NoProfile -Command "Get-SmbClientConfiguration | Select EnableSecuritySignature,RequireSecuritySignature,EnableMultiChannel,ConnectionCountPerRssNetworkInterface"
EnableSecuritySignature RequireSecuritySignature EnableMultiChannel ConnectionCountPerRssNetworkInterface
---------------------- ------------------------ ---------------- -------------------------------
True False True 4
Qué significa: El cliente usará firma si el servidor la requiere; multichannel está habilitado.
Decisión: Si multichannel causa problemas sobre VPN (rutas múltiples, NAT), considera deshabilitarlo para pruebas en clientes o servidores y decide en base a evidencia.
Tarea 10: Revisar sesiones SMB en servidor y razones de desconexión (Windows Server)
cr0x@server:~$ powershell -NoProfile -Command "Get-SmbSession | Sort-Object -Descending NumOpens | Select -First 5 | ft ClientComputerName,NumOpens,SessionId,ClientUserName"
ClientComputerName NumOpens SessionId ClientUserName
------------------ -------- --------- --------------
BR-WS-014 27 1125899906842631 CONTOSO\alex
BR-WS-021 19 1125899906842630 CONTOSO\maria
BR-WS-008 12 1125899906842628 CONTOSO\sam
Qué significa: Existen sesiones activas; puedes correlacionar quejas de desconexión con clientes específicos y contadores de abiertas.
Decisión: Si solo un subconjunto de clientes se ve afectado, enfócate en su camino (Wi‑Fi, VLAN, seguridad endpoint) más que en el servidor.
Tarea 11: Buscar errores del servidor SMB (consulta de event log en Windows)
cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName Microsoft-Windows-SMBServer/Operational -MaxEvents 8 | ft TimeCreated,Id,LevelDisplayName,Message -AutoSize"
TimeCreated Id LevelDisplayName Message
----------- -- ---------------- -------
12/27/2025 9:17:10 AM 310 Error The server failed to allocate from the system nonpaged pool because the pool was empty.
12/27/2025 9:16:58 AM 1006 Warning A connection was disconnected due to inactivity.
Qué significa: “Disconnected due to inactivity” apunta a desajustes de timeout. Problemas de nonpaged pool indican presión de memoria/bugs de drivers (menos común hoy, pero sucede).
Decisión: Para desconexiones por inactividad, aborda timeouts de firewall/VPN y keepalives SMB. Para problemas de pool de memoria, trátalo como un incidente de salud/capacidad del servidor.
Tarea 12: Probar throughput bruto vs comportamiento de I/O pequeño (Linux, smbclient)
cr0x@server:~$ smbclient //FS-HQ/Projects -U 'CONTOSO\alex' -c 'lcd /tmp; get bigfile.bin'
getting file \bigfile.bin of size 2147483648 as bigfile.bin (38.2 MBytes/sec) (average 38.2 MBytes/sec)
Qué significa: La transferencia secuencial grande es decente. Si los usuarios aún se quejan de “abrir carpetas” lento, el cuello de botella probablemente sea latencia de metadatos, no ancho de banda.
Decisión: Enfócate en latencia, enumeración de directorios, escaneo AV y rondas SMB, no en “mejorar el circuito”.
Tarea 13: Medir latencia de “create/open” SMB con un bucle simple (cliente Windows)
cr0x@server:~$ powershell -NoProfile -Command "$p='\\FS-HQ\Projects\latencytest'; 1..20 | % { $t=Measure-Command { Get-ChildItem $p | Out-Null }; '{0} ms' -f [int]$t.TotalMilliseconds }"
182 ms
190 ms
176 ms
415 ms
181 ms
179 ms
Qué significa: La mayoría de ejecuciones están en ~180–190 ms, pero hay picos a 400 ms. Eso es jitter. Los usuarios perciben picos, no promedios.
Decisión: Investiga pérdida/jitter, saturación de CPU del VPN y encolamiento. Considera QoS y dimensionamiento del hardware del túnel.
Tarea 14: Confirmar resolución DNS consistente del servidor de archivos (cliente Windows)
cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName FS-HQ | ft Name,Type,IPAddress"
Name Type IPAddress
---- ---- ---------
FS-HQ A 10.10.1.50
Qué significa: El cliente resuelve a la IP interna. Si resuelve a una IP pública o a otro sitio, tu ruta SMB puede hacer hairpin o atravesar la política de firewall equivocada.
Decisión: Corrige DNS de horizonte dividido y definiciones de sitio/subred AD para que los clientes de sucursal usen la ruta prevista.
Tarea 15: Revisar sincronización de tiempo (sanidad Kerberos) (Windows)
cr0x@server:~$ w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 3 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Last Successful Sync Time: 12/27/2025 9:14:21 AM
Source: DC-HQ.contoso.local
Poll Interval: 10 (1024s)
Qué significa: El cliente se sincronizó recientemente con una fuente de dominio. Si la hora difiere por minutos, la autenticación Kerberos y el establecimiento de sesiones SMB pueden fallar o degradarse feamente.
Decisión: Arregla NTP/jerarquía AD antes de culpar a SMB.
Tarea 16: Ver si el servidor de archivos está limitado por almacenamiento (ejemplo NAS Linux)
cr0x@server:~$ iostat -xz 1 5
avg-cpu: %user %nice %system %iowait %steal %idle
12.44 0.00 4.11 18.32 0.00 65.13
Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %util await
nvme0n1 55.0 120.0 7200.0 15600.0 0.0 0.0 92.1 18.4
Qué significa: Alto %util y await indican que el disco está ocupado y las solicitudes esperan ~18 ms en promedio. Eso magnifica la latencia SMB, especialmente en I/O de metadatos.
Decisión: Si el await de almacenamiento es alto durante las quejas, arregla el almacenamiento (cache, medios más rápidos, separar cargas, afinar ZFS/RAID, reducir presión de escrituras síncronas) antes de tocar la VPN.
Ajustes SMB que importan (y qué dejar en paz)
Elimina SMB1. No negocies con él.
Si SMB1 está habilitado en algún lugar “por compatibilidad”, aparecerá en el peor momento posible: un escáner antiguo, un dispositivo embebido misterioso o una estación de trabajo con políticas antiguas. SMB1 tiene problemas de seguridad conocidos y pobres características de rendimiento. Más importante para tus usuarios: se comporta mal bajo latencia.
Regla de decisión: si un dispositivo solo habla SMB1, aíslalo o reemplázalo. No dejes que arrastre todo tu entorno a 1996.
Firma SMB: exígela donde corresponde, mídela donde debas
La firma provee integridad (evita manipulación). En dominios modernos suele ser requerida por política. Sobre VPN, es redundante desde la perspectiva de confidencialidad (el túnel ya cifra), pero sigue importando para integridad si no confías en el camino o si el túnel termina en lugares extraños.
Realidad operativa: la firma cuesta CPU y puede reducir el throughput. En CPUs modernas suele estar bien. En un NAS pequeño o una VM infra‑provisionada, es un impuesto de rendimiento que notarás.
Qué hacer: mantén la firma requerida en entornos de dominio salvo que tengas una razón sólida para no hacerlo. Si el rendimiento cae, mejora el dimensionamiento de CPU y offloads antes de desactivar la firma por reflejo.
Cifrado SMB: úsalo de forma quirúrgica
El cifrado SMB es excelente cuando:
- Tienes segmentos no confiables entre cliente y servidor (no solo “una VPN”, sino múltiples redes enrutadas).
- Necesitas seguridad por recurso sin importar la topología de red.
- No puedes garantizar cobertura VPN para todos los caminos de los clientes.
El cifrado SMB no es bueno cuando la CPU del servidor ya está ocupada y tu VPN ya cifra todo. Doble cifrado puede ser aceptable; también puede ser muerte por mil cambios de contexto.
Durable handles y continuous availability: no confundas características
Durable handles ayudan a un cliente a reconectar tras una breve interrupción sin corromper el estado del archivo abierto. Eso es útil sobre VPN porque tendrás micro‑caídas: rekeys, roaming Wi‑Fi, jitter de ISP.
Continuous availability es otra bestia: está ligada a servidores de archivos clusterizados y ajustes especiales de recursos compartidos. Si no tienes esa infraestructura, no esperes milagros. Aún puedes lograr estabilidad, pero no las semánticas de NAS clusterizado gratis.
OpLocks/leases: acelerador con filo cortante
En la mayoría de flujos de trabajo de oficina, las leases reducen viajes de ida y vuelta y aceleran las cosas. En shares usados por aplicaciones LOB, sistemas CAD o cualquier cosa con bloqueo de archivos extraño, pueden aparecer como conflictos de “archivo en uso” o visibilidad retardada de cambios.
No las desactives globalmente porque una app sea problematic. Aísla esa carga de trabajo en su propio share o servidor y afina allí.
Ajustes de VPN y red para SMB
MTU: el asesino silencioso de “archivos grandes cuelgan”
La encapsulación VPN reduce la MTU efectiva. Si mantienes 1500‑byte Ethernet MTU en todas partes pero añades overhead IPsec ESP u OpenVPN, puedes exceder el Path MTU real. Si PMTUD está bloqueado (común con firewalls sobreprotectoras), los paquetes se pierden en lugar de fragmentarse, y TCP se detiene. SMB entonces parece “desconectarse aleatoriamente”, a menudo durante escrituras grandes.
Haz esto: decide tu MTU efectiva para el túnel, configúrala explícitamente en la interfaz VPN y aplica clamp MSS para paquetes SYN TCP que crucen el túnel. Sí, incluso en 2025. PMTUD sigue siendo un libro de elige‑tu‑propia‑aventura.
Timeouts de estado del firewall: ajústalos al comportamiento humano, no al de laboratorio
Los humanos abren un archivo, piensan, van a almorzar y lo dejan abierto. SMB mantiene estado y puede enviar keepalives, pero tu firewall puede no respetarlos o tener lógica separada de “timeout inactividad VPN”.
Si los usuarios se desconectan después de exactamente 30 o 60 minutos, eso no es SMB caprichoso. Es un temporizador. Encuéntralo y arréglalo.
QoS: prioriza lo que más duele
SMB no es solo datos a granel. También son muchas operaciones pequeñas “de control”. Si tu enlace está saturado por backups, llamadas de vídeo o alguien sincronizando una imagen de VM, las llamadas de metadatos SMB se encolan detrás del tráfico a granel y cada apertura de carpeta se siente a melaza.
Prioriza TCP/445 y también las clases de tráfico encapsulado del VPN si hace falta. Pero hazlo con cuidado: “prioridad” no significa “deja morir todo lo demás”. Significa “reducir la latencia cola‑final para operaciones interactivas”.
Split tunneling: decide según riesgo y ancho de banda, no por corazonadas
Para VPNs sitio‑a‑sitio, usualmente quieres enrutamiento completo entre sitios pero no necesariamente “todo el tráfico de Internet por HQ”. Hacer hairpin del tráfico de Internet por HQ aumenta latencia y carga, y puede competir con SMB. Por otro lado, si tu postura de seguridad exige egress centralizado, acepta el coste y dimensiona los circuitos en consecuencia.
Broma #2: Si tu caja VPN también es tu DNS, DHCP, IDS y máquina de café, no te sorprendas cuando el compartido de archivos sepa a quemado.
Realidades del backend de almacenamiento (NAS, Windows, ZFS, VM)
Los problemas de fiabilidad SMB a menudo se diagnostican mal como “problemas de red” porque el síntoma es una desconexión. Pero los bloqueos de almacenamiento y la sobrecarga del servidor se manifiestan igual: el servidor deja de responder con rapidez, el cliente reintenta, la sesión la derriba algo impaciente en el medio.
La latencia de disco vence al ancho de banda en compartición de oficina
Los shares de oficina son mayormente I/O aleatorio pequeño: metadatos, escrituras pequeñas, muchos renombres y archivos temporales. Un servidor que puede hacer 1 Gbps en transferencias secuenciales pero tiene IOPS aleatorios mediocres seguirá sintiéndose lento. Los usuarios no benchmarkean con una copia de 2 GB; abren una carpeta con 20.000 archivos pequeños y esperan miniaturas.
Virtualización: los vecinos ruidosos son reales
Si tu servidor de archivos es una VM en un hypervisor ocupado, tus “desconexiones aleatorias” podrían ser tiempo de CPU listo, latencia de almacenamiento del datastore compartido o un problema de colas vNIC. El tuning del VPN no arreglará un host sobrereservado.
ZFS y SMB: buena combinación, pero entiende escrituras sincronas
En NAS con ZFS (o cualquier almacenamiento con foco en integridad), las escrituras síncronas pueden ser costosas. Las cargas SMB con ciertas banderas y comportamientos de aplicación pueden forzar semánticas síncronas. Si tu SLOG (dispositivo de registro separado) está ausente o es lento, las operaciones de “guardar” pueden bloquearse. La red sigue arriba; la aplicación igual expira.
Operativamente: mide await, mide CPU, mide tasas de aciertos de ARC si aplica, y mantén el servicio SMB en un camino de almacenamiento estable y de baja latencia. Pon los backups en otro sitio.
Antivirus e indexado de contenido: el impuesto oculto
El escaneo en tiempo real en el servidor por cada apertura/lectura puede arruinar el rendimiento. También puede hacerlo Windows Search indexando el share. A través de una VPN, los usuarios harán “abrir” y esperarán mientras el servidor escanea, indexa y finalmente responde.
Sé disciplinado: excluye tipos de archivo y rutas donde corresponda, especialmente formatos binarios grandes que cambian con frecuencia. Prueba con los equipos de seguridad, no lo hagas por tu cuenta. Pero no aceptes “escanear todo siempre” si rompe el negocio.
Tres mini-historias del mundo corporativo
Mini-historia 1: El incidente causado por una suposición equivocada
La configuración parecía limpia. HQ tenía un servidor de archivos. Dos sucursales conectadas por un túnel IPsec. Todos mapeaban unidades por nombre de servidor. El equipo de red juraba que el VPN era estable porque el túnel mostraba “up” y los pings funcionaban.
Las quejas no coincidían con esa imagen ordenada. Usuarios en la Sucursal A se desconectaban tres a cinco veces al día, generalmente a media tarde. La Sucursal B estaba bien. Helpdesk escaló como “SMB inestable sobre VPN” y la primera idea fue ajustar timeouts SMB en los clientes.
La suposición equivocada fue creer que “túnel up” significa “túnel saludable”. En realidad, el firewall en HQ hacía enrutamiento basado en políticas para algunas subredes y basado en rutas para otras. El tráfico de retorno de la Sucursal A a veces tomaba un camino WAN diferente durante eventos de balanceo de carga del ISP. El enrutamiento asimétrico significó drops del firewall stateful. Flujos TCP/445 morían silenciosamente. SMB hacía lo que hace: reintentaba, luego desistía, luego la aplicación entraba en pánico.
La solución no fue un ajuste SMB. Fue hacer el enrutamiento simétrico y asegurar que la tabla de estado del firewall viera ambas direcciones por el mismo camino. Tras eso, las desconexiones básicamente desaparecieron. Los únicos problemas restantes eran de rendimiento, que es el tipo de problema que puedes programar.
Mini-historia 2: La optimización que salió mal
Otra compañía tenía un problema legítimo de ancho de banda. Estaban enviando archivos de diseño grandes desde la sucursal a HQ todo el día y el enlace estaba saturado. Alguien tuvo la brillante idea de habilitar cifrado SMB “porque seguridad lo quiere” y simultáneamente habilitar compresión en la capa VPN para “ganar más throughput”.
En una prueba corta se veía bien. Luego llegó la producción. La CPU del appliance VPN se fue al tope bajo carga. Operaciones SMB empezaron a expirar. Usuarios reportaron que guardar a veces terminaba, a veces colgaba, a veces mostraba “network name no longer available”. Fallo intermitente clásico, el tipo que arruina fines de semana.
El fallo era predecible en retrospectiva: datos cifrados no se comprimen bien, así que la compresión VPN añadió overhead sin ahorro. El cifrado SMB añadió más carga CPU en endpoints. El efecto combinado aumentó latencia y jitter—exactamente lo que SMB odia. El throughput no mejoró; la latencia cola‑final empeoró. Las operaciones interactivas sufrieron incluso cuando el ancho de banda no estaba totalmente usado porque la CPU era el cuello de botella.
La solución estable fue aburrida: deshabilitar compresión VPN, mantener la firma SMB, habilitar cifrado SMB solo en shares sensibles y mejorar el hardware VPN para que la criptografía no compitiera con el ruteo. Después implementaron QoS para que transferencias a granel no acorralaran el tráfico metadata SMB interactivo.
Mini-historia 3: La práctica aburrida pero correcta que salvó el día
Esta es menos dramática, que es el punto. Una firma mediana tenía cuatro oficinas y un clúster de archivos central. Tenían una regla: cada trimestre corrían un “simulacro de shares WAN”. No era un ejercicio de mesa—una ventana de prueba real donde medían latencia, pérdida de paquetes, estadísticas de conexión SMB y latencia de almacenamiento bajo carga controlada.
También tenían un estándar sin glamour: todos los bordes VPN de oficina tenían MTU idénticas, reglas de MSS clamping y políticas de timeouts documentadas. Cada vez que alguien reemplazaba un firewall, aplicaban la misma baseline antes del corte. No “lo afinamos después”. Después es cuando los usuarios gritan.
Un día un ISP cambió algo upstream y PMTUD dejó de funcionar bien para una oficina. En horas, su monitor captó un aumento de retransmisiones TCP y latencia de apertura SMB. El helpdesk casi no tuvo tickets porque el equipo proactivamente redujo la MTU en ese túnel y ajustó el MSS clamping antes de que los usuarios notaran mucho.
La práctica no era sofisticada. Era medición repetible y una configuración base. Salvó el día precisamente porque era aburrida y por tanto se hacía consistentemente.
Errores comunes: síntoma → causa raíz → solución
Estos son los patrones que aparecen una y otra vez. El truco es dejar de tratarlos como misterios.
1) Síntoma: “Funciona con archivos pequeños, cuelga en copias grandes”
Causa raíz: MTU/PMTUD blackhole a través del VPN; fragmentación bloqueada; MSS demasiado alto.
Solución: Determina MTU efectiva con pings con DF; configura MTU en la interfaz VPN; aplica clamp TCP MSS en los bordes del túnel; asegúrate de que ICMP “frag needed” no esté bloqueado.
2) Síntoma: Desconexiones después de exactamente 30/60 minutos de inactividad
Causa raíz: Timeout de inactividad de firewall/VPN más corto que las expectativas de sesión SMB; expiración de tabla NAT.
Solución: Aumenta timeouts TCP established; configura keepalives/DPD en VPN; verifica que dispositivos intermedios (incluido CPE del ISP) no estén matando flujos.
3) Síntoma: “Abrir archivo” lento pero copia grande rápida
Causa raíz: Latencia y verbosidad de metadatos; escaneo AV; enumeración de directorios; alto await de almacenamiento en I/O pequeño.
Solución: Mide latencia de apertura y await de almacenamiento; afina exclusiones AV; reduce tamaño de carpetas; considera caché local/replicación DFS para ese share.
4) Síntoma: Solo una oficina tiene problemas, las demás bien
Causa raíz: Enrutamiento asimétrico; pérdida en ISP local; problemas Wi‑Fi/VLAN; resolución DNS al servidor equivocado.
Solución: Valida simetría de rutas con ip route get; corre mtr desde ambos extremos; confirma resolución DNS y mapeo de sitio AD.
5) Síntoma: “Network name no longer available” durante guardados
Causa raíz: Flap/rekey del túnel causando reset TCP; firewall eliminando estado; pausa del servidor (stall de almacenamiento) lo bastante larga para que el cliente aborte.
Solución: Revisa logs de VPN por renegociaciones; revisa conntrack/timeouts de estado; monitorea latencia de disco del servidor y CPU ready time.
6) Síntoma: Mensajes de autenticación o “access denied” intermitentes
Causa raíz: Kerberos falla por deriva de tiempo/DNS; caída a NTLM; alcance intermitente de DC por VPN.
Solución: Arregla sincronización de tiempo; asegura que clientes alcancen un DC local o un DC accesible; valida SPN; limpia DNS de split horizon.
7) Síntoma: Throughput bajo solo cuando firma/cifrado está activado
Causa raíz: Limitación de CPU en servidor/NAS/appliance VPN; falta de aceleración crypto; overhead de doble cifra.
Solución: Mide CPU bajo carga; escala hacia arriba; habilita aceleración hardware donde esté disponible; usa cifrado selectivo por share cuando corresponda.
8) Síntoma: Conflictos aleatorios de “archivo bloqueado” entre oficinas
Causa raíz: La app no maneja bien leases/oplocks; expectativas de caché desajustadas; comportamiento de conflicto por consistencia eventual (DFS‑R).
Solución: Para esa carga: separa el share, ajusta la estrategia de oplock/lease con cuidado, o rediseña el flujo (no editar el mismo archivo desde dos sitios vía replicación).
Listas de verificación / plan paso a paso
Plan paso a paso: estabilizar SMB entre oficinas en 10 movimientos
- Inventaria el camino. Dibuja la ruta real de paquetes: cliente → switch/Wi‑Fi → router de sucursal → ISP → borde HQ → firewall → VLAN de servidor → servidor. Incluye dispositivos NAT.
- Mide latencia, jitter y pérdida base. Usa mtr y bucles simples de apertura de archivos durante horas de mayor actividad.
- Bloquea MTU/MSS. Elige una MTU que sobreviva la encapsulación. Fíjala. Aplica MSS clamp. Verifica con pings con DF.
- Verifica simetría de enrutamiento. Confirma que los caminos de retorno usan el mismo túnel, no “la ruta por defecto que gana hoy”.
- Arregla DNS y mapeo de sitio AD. Asegura que clientes de sucursal resuelvan servidores correctamente y contacten los controladores de dominio adecuados.
- Alinea timeouts. Timeouts TCP established del firewall, timers de inactividad VPN y DPD/keepalives deben soportar sesiones abiertas de varias horas.
- Instrumenta el servidor. Vigila await de disco, CPU, eventos del servidor SMB y errores de NIC. Prueba que el servidor no sea el cuello de botella.
- Controla tráfico de fondo. Aplica QoS o programa backups/sincronizaciones para que SMB interactivo no quede detrás de transferencias a granel.
- Detén cargas hostiles a WAN. No ejecutes PST de Outlook sobre SMB a través de VPN. No edites grandes ensamblajes CAD directamente desde un share remoto a menos que disfrutes del sufrimiento.
- Elige una arquitectura a largo plazo. Si latencia/pérdida es inevitable, despliega cache/replica local o mueve la colaboración fuera de SMB.
Lista de verificación: cómo es “bueno”
- MTU conocida y validada end‑to‑end; sin blackholes PMTU.
- El túnel no flaquea y no rekeyea de manera que derribe flujos TCP activos.
- La pérdida es casi cero en los bordes de la sucursal; el jitter es moderado.
- Los timeouts de estado del firewall soportan sesiones de larga duración (horas).
- DNS determinista para nombres de servidor de archivos; sin sorpresas de resolución pública.
- Latencia de almacenamiento del servidor se mantiene baja en picos; el escaneo AV está controlado.
- El dialecto SMB es moderno (3.x) y SMB1 está deshabilitado.
Preguntas frecuentes
1) ¿Deberíamos usar IPsec o WireGuard/OpenVPN para SMB?
Usa lo que tu equipo pueda operar de forma fiable. Para SMB, la estabilidad y comportamiento predecible de MTU importan más que la marca. Los VPNs basados en rutas son generalmente más fáciles de razonar que túneles basados en políticas, especialmente al escalar a múltiples subredes.
2) ¿Está “soportado” SMB sobre VPN para trabajo de oficina en producción?
Sí, dentro de límites. Si tienes latencia consistente baja y pérdida mínima, puede ser perfectamente viable. Si tu WAN es poco fiable o de alta latencia, terminarás diseñando soluciones alrededor de la física: usa caching/replicación o cambia el flujo de trabajo.
3) ¿Por qué se desconectan las unidades mapeadas cuando nadie está copiando archivos?
Porque “inactivo” en términos humanos aún significa “sesión abierta” en términos de protocolo. Firewalls, NAT y dispositivos VPN expulsan flujos. Alinea timeouts y habilita keepalives para que la red recuerde que la sesión existe.
4) ¿Aumentar los timeouts SMB en los clientes arregla las desconexiones?
A veces enmascara síntomas, pero rara vez arregla la causa raíz. Si un dispositivo intermedio está borrando el estado TCP, el cliente puede esperar más y aún así perder la sesión. Arregla MTU, pérdida, simetría de enrutamiento y timeouts de firewall primero.
5) ¿Debemos habilitar cifrado SMB si ya tenemos VPN?
Sólo si necesitas defensa en profundidad a nivel de aplicación o tienes enrutamientos complejos donde el tráfico pueda eludir el VPN. De lo contrario, mantén la firma y confía en el cifrado del VPN. Mide CPU antes y después si habilitas cifrado SMB.
6) ¿Por qué la navegación de carpetas es lenta pero la copia de archivos es rápida?
La navegación de carpetas desencadena muchas operaciones pequeñas de metadatos. Sobre WAN, esas son bound por latencia. La copia de archivos puede estar bound por throughput y pipelined. Arregla latencia/jitter, reduce el tamaño de carpetas, controla escaneo AV o usa réplicas locales.
7) ¿DFS puede arreglar nuestros problemas SMB multi‑oficina?
DFS Namespaces puede arreglar problemas de nombres y referrals y facilitar migraciones. DFS Replication puede reducir tráfico entre sitios para datasets adecuados. No hará seguro editar el mismo archivo desde dos sitios simultáneamente.
8) ¿Cuál es la causa raíz más común de “cuelgues SMB” aleatorios sobre VPN?
Problemas de MTU/PMTUD son clásicos, especialmente cuando alguien habilitó jumbo frames internamente y olvidó el overhead del VPN. La segunda más común son timeouts de firewall/state que no coinciden con sesiones SMB de larga duración.
9) ¿Deberíamos desactivar SMB multichannel para enlaces VPN?
Probar. Multichannel puede ayudar en redes correctamente diseñadas y perjudicar cuando hay NAT, múltiples caminos o enrutamiento asimétrico. No lo hagas por copia: mide el comportamiento de conexión y decide según estabilidad.
10) ¿Es alguna vez aceptable ejecutar bases de datos o archivos PST sobre SMB entre oficinas?
“Aceptar” es una palabra fuerte. Muchas aplicaciones se comportan mal sobre SMB WAN porque asumen latencia de LAN y bloqueos estables. Si debes, rediseña: servidores de aplicación locales, escritorio remoto hacia HQ o un enfoque de replicación soportado.
Conclusión: pasos prácticos siguientes
Si quieres SMB entre oficinas sin desconexiones constantes, deja de tratarlo como una función de copia de archivos y empieza a tratarlo como un servicio distribuido con dependencias estrictas.
Haz lo siguiente:
- Ejecuta la guía rápida de diagnóstico en horas pico y captura evidencia: pérdida/jitter, MTU, enrutamiento, timeouts, latencia de almacenamiento del servidor.
- Arregla MTU/MSS y timeouts de estado primero. Estos son los dos principales generadores de “desconexión aleatoria”.
- Instrumenta el servidor y el almacenamiento para separar “red lenta” de “disco lento” en minutos, no en días.
- Decide la arquitectura intencionalmente: servidor central si la latencia es baja y estable; DFS/caché/servidores locales si no lo es; o mueve la colaboración fuera de SMB si los usuarios necesitan editar entre sitios todo el día.
El objetivo final es la fiabilidad aburrida: el recurso compartido permanece montado, las aperturas de archivo son predecibles y nadie aprende qué significa “SMB session teardown”. Manténlo así.