Compartir archivos de forma segura con SMB sobre QUIC

Compartir archivos de forma segura por Internet sin montar una VPN tradicional ya no es una idea futurista: con SMB sobre QUIC es algo totalmente real y, bien configurado, muy robusto. Este enfoque combina el protocolo SMB de toda la vida con QUIC, un transporte moderno pensado para redes hostiles como Internet, ofreciendo una experiencia casi transparente para el usuario.

En las siguientes líneas vas a ver cómo funciona SMB sobre QUIC, qué necesitas para ponerlo en marcha, cómo se administra y cómo encaja en tu estrategia de seguridad. También veremos dudas habituales (como si puede sustituir a OneDrive o si sirve en grupos de trabajo), así como las mejoras que trae Windows Server 2025 alrededor de este protocolo.

Qué es SMB sobre QUIC y por qué importa para el acceso remoto

SMB sobre QUIC es, en la práctica, una “VPN SMB” integrada en el propio protocolo de archivos. En lugar de transportar SMB sobre TCP (puerto 445), encapsula la comunicación dentro de QUIC usando UDP 443, el mismo puerto que usa HTTPS, creando un túnel cifrado con TLS 1.3 entre el cliente y el servidor de archivos.

QUIC es un estándar de IETF que aporta varias ventajas claras frente a TCP: todos los paquetes van siempre cifrados, el handshake se autentica con TLS 1.3, permite flujos paralelos fiables y no fiables, puede enviar datos de aplicación en el primer viaje de ida y vuelta (0‑RTT) y mejora el control de congestión y la recuperación de pérdidas, sobreviviendo incluso a cambios de IP o puerto del cliente (típico en redes móviles o con cambios de Wi‑Fi a 4G).

Desde el punto de vista del usuario, SMB sigue comportándose como siempre: acceso a recursos compartidos por rutas UNC, uso del Explorador de archivos, scripts con NET USE o New-SmbMapping, etc. Funciones avanzadas como multicanal, firma, compresión, disponibilidad continua o leasing de directorios siguen operando dentro del túnel QUIC sin que el usuario lo note.

La gran clave es que todo el tráfico SMB (incluida la autenticación y autorización) viaja dentro del túnel TLS 1.3 y nunca se expone en claro a la red intermedia. Esto convierte a SMB sobre QUIC en una opción muy atractiva para teletrabajadores, dispositivos móviles y organizaciones que quieren reducir su dependencia de VPN clásicas.

Requisitos previos para usar SMB sobre QUIC

Antes de ponerse a hacer clic en el botón de “Configurar” en Windows Admin Center, hay una serie de requisitos que deben cumplirse tanto en el lado del servidor como en el del cliente. Si alguno falla, la experiencia será frustrante.

Servidor SMB compatible

Necesitas un servidor SMB ejecutándose en una versión de Windows compatible, típicamente Windows Server 2022 Datacenter: Azure Edition (especialmente en entornos Azure Stack HCI o Azure Local) o versiones posteriores como Windows Server 2025, donde SMB sobre QUIC llega aún más integrado y con nuevas capacidades.

Clientes Windows aptos

En el lado del cliente, hoy la pieza clave es Windows 11 (ediciones orientadas a empresa), que incorpora el cliente SMB con soporte para QUIC. A partir de Windows 11 24H2 se suman mejoras como auditoría avanzada de conexiones SMB sobre QUIC en el Visor de eventos.

Integración con Active Directory o grupo de trabajo

La recomendación de Microsoft es usar SMB sobre QUIC con dominios de Active Directory, de forma que el servidor SMB y el cliente estén unidos al mismo dominio o a dominios de confianza. El servidor debe poder hablar al menos con un controlador de dominio para autenticar, aunque ese DC no tenga por qué salir a Internet.

No obstante, no es obligatorio tener dominio. También puedes montar SMB sobre QUIC en entornos de grupo de trabajo usando cuentas locales y NTLM, o incluso en servidores IaaS unidos a Microsoft Entra (antes Azure AD), con matices: estos últimos no pueden usar credenciales de Entra para operaciones de seguridad remotas porque Entra ID no gestiona SID de usuario o grupo, así que en la práctica seguirás tirando de cuentas locales o de dominio clásico para acceder al recurso compartido.

Puertos y firewall

Uno de los puntos más críticos es la configuración de red. El servidor debe ser accesible para los clientes en su interfaz pública mediante una regla de firewall que permita el tráfico entrante UDP/443. Es importante no abrir el puerto TCP/445 a Internet: el acceso SMB clásico por 445 debe quedar bloqueado en el perímetro.

Si necesitas cambiar el puerto por defecto (por políticas internas o colisiones con otros servicios), se pueden configurar puertos alternativos para SMB, pero lo habitual y recomendable para QUIC es mantener UDP 443, ya que facilita atravesar firewalls y proxys típicos.

Windows Admin Center y PKI

Para facilitar la administración, se recomienda usar Windows Admin Center (WAC) en su versión más reciente, que trae asistentes específicos para habilitar y gestionar SMB sobre QUIC. Eso sí, como comentan algunos usuarios, si el botón “Configurar” no responde, casi siempre es síntoma de que falta algún prerrequisito (rol no instalado, permisos insuficientes, WAC antiguo, navegador con problemas, etc.).

Además del WAC, necesitas una infraestructura de clave pública (PKI) capaz de emitir certificados de servidor adecuados, ya sea una CA de Active Directory Certificate Services o una CA pública de confianza como Digicert, Let’s Encrypt, etc. Sin un certificado correcto, QUIC no va a establecer el túnel.

Certificados y configuración básica de SMB sobre QUIC

El corazón de SMB sobre QUIC es el certificado de servidor. Sin él, no hay túnel TLS 1.3 ni autenticación del extremo, así que es lo primero que hay que tener bien atado.

Características del certificado de servidor

El certificado de servidor que vayas a usar para QUIC debe cumplir una serie de requisitos técnicos:

• Uso de clave: firma digital.
• Propósito (EKU): autenticación de servidor (OID 1.3.6.1.5.5.7.3.1).
• Algoritmo de firma: SHA256RSA o superior, con hash SHA256 o superior.
• Clave pública: preferiblemente ECDSA_P256 o superior; también se admite RSA con mínimo 2048 bits.
• Subject Alternative Name (SAN): debe incluir entradas DNS para todos los FQDN que los clientes usarán para acceder al servidor SMB.
• Subject (CN): puede ser “casi” lo que quieras, pero debe existir y seguir las buenas prácticas de emisión.
• Clave privada incluida: obligatoriamente sí, almacenada en el equipo servidor.

Si trabajas con una CA de Microsoft Enterprise, lo más cómodo es crear una plantilla de certificado específica para SMB sobre QUIC. El admin del servidor de archivos podrá pedir el certificado indicando los nombres DNS adecuados. La documentación de Microsoft sobre diseño e implementación de PKI explica el proceso de plantillas en detalle.

Solicitud del certificado desde el servidor

En un entorno con CA de Active Directory, el flujo típico sería:

1. Arrancar MMC en el servidor de archivos y añadir el complemento de Certificados para la cuenta de equipo.
2. Navegar a Certificados (equipo local) > Personal > Certificados y elegir “Solicitar nuevo certificado”.
3. Seleccionar la directiva de inscripción de Active Directory y pulsar Siguiente hasta llegar a la lista de plantillas.
4. Marcar la plantilla creada para SMB sobre QUIC.
5. Rellenar el Subject con un nombre común útil para que los usuarios identifiquen el servidor y añadir en los SAN todos los nombres DNS que se usarán.
6. Confirmar y completar la inscripción para que el certificado quede instalado en el almacén de equipo.

Si usas una CA pública de terceros, el proceso se basa en generar una CSR desde el servidor y seguir la guía específica del proveedor para emitir un certificado con los EKU, SAN y algoritmos adecuados.

Habilitar SMB sobre QUIC en el servidor

Una vez tienes el certificado, llega el momento de activar SMB sobre QUIC. El servidor no lo habilita por defecto y los clientes no pueden “forzarlo” de manera unilateral, por razones obvias de seguridad.

La configuración puede hacerse vía Windows Admin Center o PowerShell. En WAC tendrás un asistente que te pide seleccionar el certificado y activar QUIC. En PowerShell, el proceso pasa por los cmdlets de mapeo del certificado de servidor SMB sobre QUIC (New-SmbServerCertificateMapping y Set-SmbServerCertificateMapping, según el escenario).

En cuanto al tráfico de clientes, Windows seguirá intentando primero SMB sobre TCP de forma normal. Solo probará QUIC si el intento TCP falla o si explícitamente le indicas que use QUIC mediante comandos como:

• NET USE /TRANSPORT:QUIC
• New-SmbMapping -TransportType QUIC

Conexión de clientes a recursos compartidos SMB sobre QUIC

Desde el punto de vista de los usuarios, el acceso a recursos SMB sobre QUIC es casi idéntico al acceso tradicional, con la diferencia de que ahora ese tráfico va protegido dentro del túnel QUIC/TLS 1.3 y circula por Internet sin exponer el puerto 445.

Preparar el cliente y la resolución de nombres

Si el cliente pertenece a un dominio, lo normal es unir el dispositivo Windows al dominio correspondiente y asegurarse de que los nombres de servidor usados en las rutas UNC están publicados en DNS y coinciden con los SAN del certificado del servidor de archivos.

En escenarios donde DNS no resuelva esos nombres, se puede recurrir al archivo HOSTS del cliente para mapear FQDN del servidor a su IP pública. Lo importante es que el nombre que escriba el usuario en la ruta UNC sea uno de los incluidos en el certificado de servidor.

Conexión desde redes externas

El escenario típico de uso es que el cliente se encuentre fuera de la red corporativa, sin acceso directo ni a los controladores de dominio internos ni a las IP privadas del servidor de archivos. Ahí es donde QUIC brilla: el túnel se establece a través de Internet usando UDP 443, sin necesidad de VPN adicional.

Para el usuario, el acceso puede hacerse simplemente desde el Explorador de archivos, escribiendo la ruta UNC al recurso compartido (por ejemplo, \\fsedge1.contoso.com\ventas). También se puede usar:

• NET USE * \\fsedge1.contoso.com\ventas (intenta TCP y luego QUIC automáticamente si falla TCP).
• NET USE * \\fsedge1.contoso.com\ventas /TRANSPORT:QUIC (fuerza QUIC).
• New-SmbMapping -LocalPath 'Z:' -RemotePath '\\fsedge1.contoso.com\ventas' -TransportType QUIC (vía PowerShell).

Si la conexión falla cuando fuerzas QUIC, suele ser síntoma de que el túnel se está intentando establecer pero algo en firewall, certificado o configuración de mapeos no está bien montado.

Autenticación: NTLMv2, Kerberos y proxy de KDC

Por defecto, cuando el cliente se conecta a un servidor de archivos SMB sobre QUIC desde Internet, no tiene visibilidad directa de los controladores de dominio internos. En ese contexto, la autenticación cae en NTLMv2, donde el servidor se autentica en nombre del usuario, pero siempre dentro del túnel TLS 1.3 (no se exponen credenciales fuera de QUIC).

Aunque NTLMv2 dentro del túnel es aceptable, Microsoft recomienda mantener Kerberos siempre que sea posible, porque ofrece un modelo de seguridad más robusto y evita depender de NTLM en el largo plazo.

Proxy de KDC para habilitar Kerberos vía Internet

Para seguir usando Kerberos sin exponer directamente los controladores de dominio a Internet, puedes configurar el proxy de KDC. Este servicio recibe peticiones de tickets Kerberos por HTTPS (puerto TCP 443), las reenvía a los DC internos y responde al cliente, todo ello sin sacar credenciales en claro a la red externa.

La configuración incluye varios pasos en el servidor de archivos:

1. Registrar una URL de escucha para el proxy con NETSH, usualmente en https://+:443/KdcProxy, con la cuenta “NT AUTHORITY\Network Service”.
2. Configurar ciertas claves de registro del servicio KPSSVC (proxy de KDC) para ajustar la autenticación HTTPS y permitir escenarios necesarios.
3. Vincular el certificado adecuado al puerto 443 con Add-NetIPHttpsCertBinding, usando la huella del certificado de SMB sobre QUIC.
4. Agregar nombres SMB sobre QUIC del servidor como SPN en Active Directory (por ejemplo, con NETDOM computername).
5. Configurar el servicio kpssvc para inicio automático y arrancarlo.

En el lado del cliente, se usa directiva de grupo para especificar servidores proxy KDC para clientes Kerberos, asociando el dominio de AD (por ejemplo, corp.contoso.com) con la URL externa del proxy (algo del estilo https fsedge1.contoso.com:443:kdcproxy /).

Con esto, cuando un usuario de corp.contoso.com intente acceder a fsedge1.contoso.com, el cliente sabrá que debe contactar con ese proxy para obtener tickets Kerberos, sin necesidad de hablar directamente con los DC internos.

Caducidad y renovación de certificados

Uno de los puntos que más se pasa por alto en la práctica es la gestión del ciclo de vida de los certificados. Cuando el certificado de SMB sobre QUIC caduca y se emite uno nuevo, la huella digital cambia, aunque sea renovado automáticamente por la misma CA.

Eso implica que hay que actualizar la configuración de SMB sobre QUIC para asociar el nuevo certificado. Puedes hacerlo desde Windows Admin Center seleccionando el nuevo certificado en la configuración existente, o vía PowerShell con Set-SMBServerCertificateMapping para apuntar a la huella fresca.

Para evitar cortes de servicio por caducidad inesperada, Microsoft propone usar herramientas como Azure Automanage para Windows Server, que ayudan a monitorizar y automatizar renovaciones de certificados y otras tareas de mantenimiento.

Control de acceso de clientes con certificados

Además del túnel cifrado y la autenticación de usuario, SMB sobre QUIC puede aplicar un control de acceso adicional basado en certificados de cliente. Es una capa extra de seguridad que permite definir de forma explícita qué dispositivos pueden establecer conexiones QUIC al servidor.

Cómo funciona el control de acceso de clientes

El servidor mantiene una lista de control de acceso de certificados (listas de permitidos y bloqueados) y, cuando un cliente intenta conectarse, valida primero la cadena de certificados de ese cliente. El servidor comprueba:

• Que la cadena de certificados sea válida y emitida por una CA en la que confíe.
• Que el certificado o su emisor estén presentes (permitidos o denegados) en las listas de control de acceso.

Se pueden usar certificados de cliente con SAN, igual que en el caso de servidor, y la decisión de acceso se toma evaluando si hay entradas de permiso o de bloqueo para el certificado hoja o para alguno de los emisores de la cadena. Una sola entrada de denegación en la cadena tiene prioridad sobre las de permiso.

Esto permite escenarios flexibles: puedes permitir todos los certificados emitidos por una CA determinada, pero denegar algunos dispositivos concretos añadiendo sus hashes como bloqueados, o al revés, bloquear a toda una CA salvo excepciones muy controladas.

Requisitos para el control de acceso de clientes

En servidor necesitas Windows Server 2022 Datacenter: Azure Edition con la actualización KB5035857 de marzo de 2024 (y, para ciertas funciones en vista previa, el paquete Feature Preview 240302_030531) o versiones posteriores como Windows Server 2025. Además, obviamente, SMB sobre QUIC debe estar ya habilitado.

En el lado del cliente SMB, debes contar con un sistema operativo soportado y un certificado de cliente con EKU de autenticación de cliente (OID 1.3.6.1.5.5.7.3.2), emitido por una CA que el servidor confíe, e instalado en el almacén de certificados del equipo.

Asignar certificados y conceder acceso

El proceso típico arranca en el cliente, obteniendo la huella de su certificado:

1. Enumerar certificados en Cert:\LocalMachine\My con PowerShell.
2. Filtrar por el Subject que te interese y guardarlo en una variable.
3. Obtener su hash SHA256 con $clientCert.GetCertHashString("SHA256").

Luego se crea el mapeo de certificado de cliente SMB con New-SmbClientCertificateMapping, indicando el namespace (FQDN del servidor) y la huella correspondiente. Desde ese momento, el cliente utilizará ese certificado al conectarse al servidor que coincida con ese namespace.

En el servidor, se obliga a requerir autenticación de cliente con Set-SmbServerCertificateMapping -RequireClientAuthentication $true. A partir de ahí, se conceden permisos a clientes concretos con Grant-SmbClientAccessToServer o se bloquean con Block-SmbClientAccessToServer, usando como identificador el hash SHA256 del certificado hoja o el Subject del emisor.

Auditoría y registros de eventos para SMB sobre QUIC

En entornos serios, la visibilidad es tan importante como la seguridad. SMB sobre QUIC incorpora capacidades de auditoría tanto en el lado del cliente como en el servidor para ayudar a diagnosticar problemas y rastrear accesos.

En clientes a partir de Windows 11 24H2, el Visor de eventos registra información de conectividad SMB sobre QUIC en la ruta Registros de aplicaciones y servicios\Microsoft\Windows\SMBClient\Conectividad, donde, por ejemplo, el evento 30832 refleja detalles de conexiones QUIC.

En el servidor, puedes habilitar la auditoría del acceso por certificados de cliente con Set-SmbServerConfiguration -AuditClientCertificateAccess $true. Los eventos relevantes se registran en:

• SMBServer\Audit (eventos 3007, 3008 y 3009) para el lado servidor.
• SMBClient\Connectivity (evento 30831) para correlacionar conexiones desde el punto de vista del cliente.

Estos eventos incluyen datos sobre los certificados de cliente (excepto el raíz) como asunto, emisor, número de serie, hashes SHA1/SHA256 y qué entradas de control de acceso se aplicaron a cada solicitud, así como un identificador de conexión que facilita cruzar información entre cliente y servidor.

Seguridad de red alrededor de SMB: segmentación y firewall

SMB sobre QUIC no vive en el vacío; forma parte de una estrategia más amplia de seguridad de red. Microsoft recomienda complementar este túnel cifrado con técnicas de segmentación e aislamiento para minimizar movimientos laterales y exposición innecesaria.

Como regla básica, el puerto TCP 445 debe permanecer bloqueado desde y hacia Internet, tanto en sentido entrante como saliente, salvo casos puntuales como Azure Files u otros servicios de nube controlados. Cuando se requiera SMB en la nube pública, se recomienda encapsularlo en VPN o usar directamente SMB sobre QUIC para reducir superficie de ataque.

En la red interna, merece la pena inventariar el tráfico SMB (quién habla con quién, qué recursos se usan, qué servidores exponen recursos compartidos realmente necesarios). Herramientas como módulos PowerShell (por ejemplo, Get-FileShareInfo) y la auditoría de acceso a recursos compartidos ayudan a saber qué está en uso y qué no.

El firewall de Windows Defender con seguridad avanzada es otra pieza clave. Puedes crear reglas de entrada y salida que bloqueen SMB de forma global y usar la acción “Permitir la conexión si es segura” para definir listas de permitidos basadas en autenticación IPsec o Kerberos con encapsulación nula, permitiendo solo a controladores de dominio y servidores de archivos autorizados.

En las versiones recientes de Windows (Windows 11 24H2 y Windows Server 2025), las reglas integradas de firewall ya no abren de forma automática los puertos NetBIOS 137‑139 al crear recursos compartidos, lo que refuerza la seguridad por defecto. Si alguien necesita mantener SMB1 (no recomendable salvo casos heredados extremos), tendrá que abrir esos puertos manualmente.

Escenarios de uso, dudas frecuentes y relación con OneDrive/SharePoint

Uno de los debates más habituales es si SMB sobre QUIC puede sustituir a soluciones como OneDrive o SharePoint. La respuesta corta es que no están pensados para lo mismo, aunque haya solapamientos.

SMB sobre QUIC ofrece acceso remoto directo a recursos compartidos de servidor, con la misma estructura de carpetas, permisos NTFS y flujos de trabajo que ya tienes en tu red local. Es ideal para usuarios y aplicaciones que dependen de rutas UNC, bloqueos de archivos, flujos de datos continuos o características de servidor de archivos clásico.

OneDrive y SharePoint, en cambio, funcionan como servicios SaaS con sincronización, colaboración en línea y ecosistema Microsoft 365. Son mejores para trabajo colaborativo, edición simultánea en Office, control de versiones tipo documento y acceso desde cualquier sitio sin preocuparte por la infraestructura de servidor.

En cuanto a grupos de trabajo sin dominio, SMB sobre QUIC se puede usar, pero no es la panacea ni convierte mágicamente un grupo de PCs en un sistema distribuido tipo “Dropbox P2P”. Sí, una máquina puede actuar como servidor SMB sobre QUIC y exponer recursos al resto, siempre que tenga un certificado válido y esté accesible por UDP 443, pero:

• La máquina que aloja los archivos debe permanecer encendida y accesible para que los demás puedan conectarse.
• No hay sincronización nativa de datos entre todos los equipos; SMB sobre QUIC es acceso remoto, no replicación automática en modo multi-master.
• Montar un “sistema descentralizado” donde todas las máquinas sean servidor y cliente a la vez requeriría otra capa de software de replicación o clúster, no lo resuelve QUIC por sí mismo.

En resumen coloquial: no, no has descubierto la alternativa mágica a OneDrive para sincronizar todo entre todos sin infraestructura. Lo que sí tienes es una forma potentísima y segura de exponer tus recursos de servidor de archivos a Internet sin VPN, manteniendo la lógica de permisos y herramientas ya conocidas.

Novedades de Windows Server 2025 relacionadas con SMB sobre QUIC

Windows Server 2025 llega con varias mejoras que se apoyan directamente en SMB sobre QUIC y en la idea de ofrecer acceso remoto seguro y eficiente a recursos on-prem y de perímetro.

Por un lado, refuerza el soporte de SMB sobre QUIC como pieza central para entornos híbridos y de teletrabajo, con un enfoque claro en conexiones cifradas extremo a extremo sin VPN, mejor rendimiento en redes de alta latencia y preferencia por certificados TLS y Kerberos frente a NTLM.

Por otro, amplía capacidades de gestión y alta disponibilidad gracias a funciones como el hotpatching (aplicar parches críticos sin reiniciar, especialmente en ediciones Datacenter: Azure Edition) y una integración más profunda con Windows Admin Center, Hyper‑V, contenedores y Azure Arc.

Azure Arc y servicios asociados (Monitor, Policy, Automation) permiten tratar servidores físicos o virtuales como recursos de nube, aplicando políticas de seguridad, actualizaciones y auditoría de manera uniforme, algo especialmente útil cuando esos servidores exponen recursos SMB sobre QUIC hacia Internet.

Aunque la versión final de Windows Server 2025 aún está en fase de evaluación técnica, la preview disponible vía Windows Insider ya deja ver claramente que el modelo de acceso remoto pasa por protocolos modernos como QUIC y por integrar el servidor de archivos clásico en escenarios híbridos y multicloud.

SMB sobre QUIC se ha convertido en una pieza estratégica para compartir archivos de forma segura por Internet: combina el protocolo SMB que las empresas ya conocen con un transporte moderno, cifrado y resistente como QUIC, simplifica el acceso remoto sin obligar a desplegar y mantener VPN complejas, permite afinar el control de acceso mediante certificados de cliente, se integra con Kerberos a través de proxy KDC y encaja con las prácticas de segmentación y endurecimiento del tráfico SMB. Bien diseñado (certificados cuidados, firewall afinado, auditoría activa y una buena política de contraseñas o autenticación sin contraseña), ofrece una forma muy sólida de exponer servidores de archivos al exterior manteniendo el control sobre quién entra, desde dónde y con qué garantías.