MDM corporativo y VPN: Intune, Kaspersky, MDM nacionales y Always-on

1. Introducción: por qué el tema es relevante y qué aprenderás

En los últimos años, la movilidad corporativa dejó de ser una función secundaria: los empleados trabajan desde oficinas, hogares, coworkings, aeropuertos y redes móviles en todo el mundo. El acceso a las aplicaciones internas debe ser fluido, seguro y transparente. Always-on VPN es el mecanismo clave que garantiza una conexión continua y protegida de los dispositivos con la red corporativa, sin importar tiempo ni lugar. En este artículo analizaremos detalladamente cómo diseñar e implementar Always-on VPN en Windows 10/11, Android Enterprise y iOS/iPadOS, utilizando Microsoft Intune, Kaspersky Endpoint (a través de Kaspersky Security Center) y MDM/UEM nacionales (incluyendo escenarios para SO corporativos y soluciones certificadas por FSTEC/FSB). Recorreremos desde los fundamentos hasta arquitecturas avanzadas, proporcionando instrucciones claras, listas de verificación, marcos de implementación y casos reales. El objetivo es que puedas abrir este artículo en cualquier fase del proyecto y obtener respuestas concretas: qué hacer, cómo hacerlo y por qué es lo correcto.

2. Fundamentos: conceptos clave

2.1. ¿Qué es Always-on VPN?

Always-on VPN es un modo en el que un túnel seguro se establece automáticamente ante cualquier actividad de red del dispositivo o según políticas definidas (disparadores), sin requerir intervención manual del usuario. En escritorios (Windows) se distinguen el device tunnel (se activa en inicio de sesión del sistema, a nombre de la máquina) y el user tunnel (una vez que el usuario ha iniciado sesión). En plataformas móviles (Android, iOS/iPadOS) existen los modos always-on y per-app VPN con opción de on-demand por dominios o aplicaciones.

2.2. Componentes

• MDM/UEM: sistema de gestión centralizada de dispositivos (Intune, políticas móviles de Kaspersky Security Center, MDM nacionales para Android Enterprise, iOS/iPadOS y sistemas especializados).
• Gateway VPN: concentradores IPsec/IKEv2, SSL VPN, WireGuard, L2TP, SSTP, etc., o gateways virtuales en la nube.
• PKI/Certificados: EAP-TLS, certificados de dispositivo/usuario, SCEP/PKCS para emisión masiva.
• DNS/DHCP/ruteo: diseño de túnel dividido/completo, rutas, NRPT (Windows), exclusiones/inclusiones.
• Identidades y políticas de acceso: Entra ID (Azure AD) y Conditional Access, AD local, MFA, verificaciones de postura.

2.3. Tipos de topologías

• Full-tunnel: todo el tráfico pasa por la VPN. Máximo control, pero mayor carga y demandas de ancho de banda en los concentradores.
• Split-tunnel: subredes corporativas y FQDNs navegando por VPN, internet directamente. Balancín entre seguridad y rendimiento, requiere ruteo y políticas DNS precisas.
• Per-app VPN: solo aplicaciones corporativas inician túneles. Modelo ideal para Zero Trust y minimizar la superficie de ataque.

2.4. Por qué Always-on es crítico hoy

• El perímetro se expande a “en todas partes y en ninguna parte”. Los perímetros tradicionales ya no funcionan.
• Aumento de ataques en redes Wi-Fi públicas, MITM y tácticas de phishing.
• Normas de cumplimiento exigen canales seguros y acceso controlado fuera de redes de oficina.
• Integración con arquitecturas SASE/Zero Trust — VPN se vuelve base o parte de un stack más amplio.

3. Profundización: aspectos avanzados

3.1. Dispositivo vs túnel de usuario en Windows

El device tunnel se usa para acceso temprano: autenticación de dominio, GPO, scripts de inicio, gestión antes del login. Usa certificado máquina. El user tunnel es para acceso a apps de usuario, usando certificado usuario e integraciones con Entra ID/SSO.

3.2. Protocolos y sus características

• IKEv2/IPsec: moderno, resistente a cambios de red (MOBIKE), ideal para Always-on, soporte nativo en Windows, iOS y parte de Android.
• SSL VPN/SSTP: sobre TLS, atraviesa la mayoría de proxies/firewalls, pero puede ser más intensivo en recursos.
• WireGuard: alto rendimiento, gestión simple de claves, excelente en móviles, pero no tiene integración Always-on nativa en Windows via MDM, requiere app cliente y políticas de gestión.
• L2TP/IPsec: anticuado, mantenido por compatibilidad, usar con precaución en nuevos proyectos.

3.3. PKI y emisión automática de certificados

Para escalar, usa SCEP a través de Intune Certificate Connector o equivalentes en Kaspersky/MDM nacionales. Para escenarios de alta resistencia — contorno CA separado, CRL/OCSP accesibles externamente vía DMZ, plantillas diferenciadas para dispositivo/usuario, vida corta de certificados, rotación automática.

3.4. DNS y NRPT

Windows utiliza NRPT — reglas de selección DNS para dominios. En túnel dividido — define dominios internos y sus servidores DNS mediante perfil VPN. En iOS/Android — usa DNS per-app y ruteo por FQDN según soporte.

3.5. Rendimiento y estabilidad

• MTU/MSS: vigila fragmentación. Para IPsec sobre UDP suele reducirse MTU 40-60 bytes respecto al enlace. Para SSL, mide PMTU y ajusta MSS clamping en el gateway.
• DPD/Keepalive: equilibrio entre duración de túnel y consumo batería en móviles.
• QoS/DSCP: para aplicaciones de voz/video sobre túnel.
• HA/Scale-out: clúster activo-activo, BGP para ruteo dinámico, GSLB/Anycast IP en escenarios globales.

4. Práctica: Always-on VPN para Windows 10/11 con Microsoft Intune

4.1. Arquitectura

• MDM: Microsoft Intune.
• Identidades: Entra ID, híbridas o en la nube, Conditional Access.
• PKI: Intune Certificate Connector, SCEP para dispositivo y usuario.
• Gateway VPN: IKEv2/SSTP en dispositivo especializado o Windows Server RRAS (para POC). En producción, preferibles gateways hardware/virtuales enterprise.

4.2. Secuencia de pasos

1. Prepara la PKI: despliega NDES/SCEP, publica CRL/OCSP, crea plantillas DeviceAuth y UserAuth (Client Authentication, IPsec IKEv2).
2. Configura Intune Certificate Connector en servidor con acceso a CA.
3. Crea perfiles de certificado en Intune: SCEP Device y SCEP User. Asigna a grupos de dispositivos/usuarios.
4. Define modelo de túneles: Device tunnel (rutas mínimas a AD/DC, KMS, gestión) + User tunnel (acceso completo a subredes corporativas).
5. Crea perfil VPN (Windows 10/11) en Intune: tipo IKEv2, autenticación EAP-TLS, FQDN gateway, CA raíz/intermedia, perfil NRPT, túnel dividido/completo, lista de rutas.
6. Activa Always-on: en configuración del perfil marca conexión automática y disparadores (todas red, SSID confiables/no confiables — opcional).
7. Añade OMA-URI personalizado para Device tunnel si es necesario: ./Device/Vendor/MSFT/VPNv2/DeviceVPN/ProfileXML con valores EAP-TLS y configuraciones de rutas. Separado — UserVPN.
8. Verifica cumplimiento: política compliance en Intune, cifrado de disco, versión mínima SO, bloqueo jailbreak/root.
9. Piloto y escalado: inicia con 10-20 dispositivos, luego expande en oleadas.

4.3. Consejos prácticos

• Separa rutas: DeviceVPN — solo servicios necesarios (AD, PKI, gestión); UserVPN — aplicaciones LOB.
• Excluye Microsoft 365 en split-tunneling: usa listas oficiales de FQDN/rangos para optimizar rendimiento.
• Revisa logs: Registros Windows — RasClient, DeviceManagement-Enterprise-Diagnostics-Provider; recopilación vía Intune.
• Fallback: si IKEv2 bloqueado, ofrece SSTP como respaldo.

4.4. Mini checklist Windows Intune Always-on

• CA/NDES configurados, CRL/OCSP públicos
• EAP-TLS probado (device y user)
• NRPT y rutas validadas
• Perfiles Device y User diferenciados
• Split-tunneling acordado con red
• HA gateway confirmado con pruebas failover

5. Práctica: Android Enterprise Always-on con Intune y MDM nacionales

5.1. Arquitectura

• Modos Android: Work Profile (BYOD), Fully Managed (COPE/COBO), Dedicated.
• Cliente VPN: nativo (IKEv2/IPsec) o app proveedor. Para WireGuard/SSL — app cliente y Managed Config.
• MDM: Intune o MDM/EMM nacional con soporte API Android Enterprise, políticas always-on y bloqueo VPN.

5.2. Pasos en Intune

1. Registra Android Enterprise en Intune, define perfil de gestión (Fully Managed recomendado para dispositivos corporativos).
2. Instala cliente VPN vía Managed Google Play y asigna grupos.
3. Crea configuración VPN: tipo (IKEv2/IPsec, SSL o vía configuración de app), parámetros de gateway, certificados (SCEP User/Device), algoritmos, DPD.
4. Activa Always-on y si es necesario Block connections without VPN (lockdown).
5. Configura Per-app VPN: asigna apps del perfil de trabajo para usar VPN.
6. Piloto y monitoreo: seguimiento en Intune, diagnóstico conexiones en dispositivo (estado VPN, logs cliente).

5.3. Pasos en MDM nacionales

• Importa cliente VPN: distribuye APK vía tienda corporativa o catálogo integrado.
• Configuración gestionada: llena parámetros JSON del cliente (servidores, claves, certificados), asigna a grupos de dispositivos.
• Política Always-on/lockdown: activa flag de plataforma para bloquear tráfico sin VPN.
• Cumplimiento: detección de root, prohibición de fuentes inseguras, control versión SO y agente.

5.4. Consejos prácticos

• Batería: amplía intervalo keepalive donde sea posible sin perder SLAs.
• Cambios de red: IKEv2 con MOBIKE y WireGuard toleran mejor cambios Wi-Fi/LTE.
• DNS: usa DNS corporativo y split por FQDN si cliente lo permite.

5.5. Mini checklist Android

• Modo gestión elegido (preferible Fully Managed)
• Cliente VPN certificado y probado
• Always-on y lockdown activados según necesidad
• Per-app asignado a apps corporativas
• Certificados emitidos y renovados automáticamente

6. Práctica: iOS/iPadOS — VPN per-app y on-demand

6.1. Arquitectura

iOS/iPadOS ofrece un stack maduro: perfiles IKEv2, Per-app VPN, On-Demand por dominios/redes, bloqueo de tráfico fuera de VPN. A través de Intune o MDM nacionales se crean configuraciones de perfil asignables a apps.

6.2. Pasos

1. Certificación: SCEP/PKCS para certificados usuario EAP-TLS.
2. Creación perfil IKEv2: servidor, identificadores, autenticación, renegociación, DPD, algoritmos.
3. Per-app VPN: lista bundle IDs de apps que usarán VPN.
4. Reglas On-Demand: por dominios, interfaces (Wi-Fi, celular), disparadores SSID (por ejemplo, todo Wi-Fi desconocido — vía VPN).
5. Cumplimiento: bloqueo jailbreak, versiones mínimas iOS, políticas de código.

6.3. Consejos útiles

• Prueba esquemas DNS: On-Demand basado en dominios requiere resolución correcta y lista FQDN.
• Per-app como predeterminado: reduce fugas de datos y mejora usabilidad.
• Cuidado con proxies: en redes públicas on-demand vía IKEv2 evita problemas con inspección SSL en el camino.

7. Práctica: Kaspersky Endpoint y políticas móviles KSC, además de MDM nacionales para SO corporativos

7.1. Kaspersky Security Center (KSC) y dispositivos móviles

KSC permite gestionar perfiles VPN para iOS y Android mediante políticas MDM integradas, basándose en stacks VPN nativos de las plataformas. La lógica general: distribuimos certificados, creamos perfil VPN, activamos always-on/lockdown o per-app, asignamos a dispositivos/usuarios.

7.2. Pasos en KSC

1. Integración con PKI: importa certificados raíz, configura emisión de certificados usuario/dispositivo (SCEP o manual via PKCS).
2. Crea política VPN: tipo IKEv2/IPsec, parámetros gateway, algoritmos, EAP-TLS, lista de rutas/dominios (split vs full).
3. Always-on/Per-app: activa opciones en el perfil según plataforma. En Android — activa always-on y bloqueo de tráfico no VPN; en iOS — on-demand y per-app.
4. Asignación: por grupos, etiquetas, colecciones, considerando contexto (rol, ubicación).
5. Monitoreo: reportes de instalación de perfiles y estado de túneles (integrable con logs cliente y SIEM).

7.3. MDM nacionales y SO especializados

En ambientes corporativos se usan frecuentemente MDM/UEM nacionales, especialmente bajo requerimientos de certificación y plataformas especializadas (por ejemplo, SO móvil corporativo). Escenario típico: política IPsec/IKEv2 obligatoria, VPN requerida, ruteo solo a redes corporativas, bloqueo estricto de tiendas y canales externos. Gestión de certificados vía integración con CA interna o importación PKCS.

7.4. Consejos operativos

• Nomenclatura uniforme de perfiles: mismos nombres y versiones para coherencia cross-MDM.
• Diferenciación estricta de accesos: grupos MFA en MDM alineados con segmentación en VPN.
• Rotación de claves: automática forzada por políticas MDM ante incidentes.

8. Errores comunes y cómo evitarlos

• Mezclar device y user tunnels: causa autenticación inestable y rutas inesperadas. Separa perfiles y objetivos.
• Full-tunnel para todo sin analizar capacidad: congestiona concentradores, genera quejas de velocidad. Haz dimensionamiento y usa split/per-app cuando puedas.
• Falta de diseño NRPT/DNS: falla resolución de nombres, timeouts. Define reglas y prueba resoluciones.
• Certificados con vida larga: riesgo de compromisos. Acorta vidas y automatiza rotación.
• No considerar proxies e inspección SSL: caídas de túneles. Añade exclusiones y protocolos fallback.
• Sin pruebas de roaming: cambios rompen sesiones. Testea switches Wi-Fi/LTE, clientes VPN con MOBIKE/UDP.
• Un solo perfil para todos los SO: ignorar o romper parámetros específicos. Crea perfiles separados.

9. Herramientas y recursos

9.1. Gestión y automatización

• Intune Graph API: automatiza emisión de perfiles, reportes, cumplimiento.
• SDK/CLI MDM nacionales: cambios masivos en políticas, integraciones con CMDB/ITSM.
• Ansible/Terraform para gateways VPN gestionados y políticas de red, plantillas IaC.

9.2. Monitoreo y diagnóstico

• Windows: RasClient, DeviceManagement-Enterprise-Diagnostics-Provider, logs IKE/AuthIP, recopilación vía Intune.
• Android/iOS: perfiles diagnósticos, logs cliente VPN, exportación a SIEM.
• Sensores de red: pruebas sintéticas a gateways, medición MTU, latencias, pérdidas.

9.3. Seguridad

• Monitoreo OCSP/CRL: disponibilidad de puntos de verificación.
• Verificación configuración de criptoperfiles: cumplimiento de estándares corporativos y regulatorios.
• Segmentación: ACL/SGT/NAC sincronizados con grupos MDM.

10. Casos y resultados

10.1. Distribución global con Windows e Intune

Organización en 8 países, 4500 laptops. Arquitectura: DeviceVPN (IKEv2) para autenticación temprana, UserVPN con split-tunnel para LOB, exclusiones Microsoft 365. Resultado: casi cero incidentes de login fuera de oficina, reducción de tráfico en gateways por split 35-45%, aumento de satisfacción de usuarios.

10.2. Android Enterprise en producción

1500 terminales COBO. Always-on con bloqueo de tráfico no VPN, ruteo per-app para WMS y MES. Resultado: sin fugas desde apps externas, desempeño predecible en Wi-Fi en almacenes, menos trabajo manual en revisiones de seguridad.

10.3. iOS per-app en ventas

700 iPads para personal de campo. On-Demand para dominios CRM/ERP, per-app VPN. Usuarios no notan VPN, SLA se cumple aun en redes con filtros. Reducción de soporte por problemas de red en 30% tras migrar a on-demand.

10.4. MDM nacional y SO especializados

Organización con altos requerimientos de cumplimiento. Política obligatoria IPsec/IKEv2 para SO móvil corporativo, emisión centralizada de certificados vía CA interna. Resultado: cumplimiento confirmado, gestión y tráfico predecible, auditorías externas exitosas.

11. FAQ: 10 preguntas clave

P1. ¿Siempre se necesita full-tunnel?

No. Full-tunnel es válido bajo regulaciones estrictas o necesidad de control total del tráfico. En otros casos split-tunnel o per-app ofrecen mejor balance rendimiento/seguridad.

P2. ¿Cómo elegir protocolo?

Opción inicial: IKEv2/EAP-TLS para Windows y iOS; clientes con soporte IKEv2 o WireGuard para Android. Para evitar proxies/firewalls — SSTP/SSL como fallback. Considera soporte MDM para always-on.

P3. ¿Certificados o contraseñas?

Para Always-on solo certificados (EAP-TLS). Reduce riesgos de phishing y aumenta automatización.

P4. ¿Cómo combinar con Zero Trust?

Usa per-app VPN y segmentación en gateway, verifica postura del dispositivo (compliance MDM), limita acceso con principio mínimo privilegio y aplica Conditional Access.

P5. ¿Qué pasa con Microsoft 365 y SaaS?

Generalmente excluidos del túnel (split) para ahorro de tráfico y rendimiento, pero mantienen control con CASB/MDM App Protection.

P6. ¿Cómo garantizar alta disponibilidad?

Duplica gateways (activo-activo), usa GSLB/Anycast, sincroniza estados, garantiza independencia de CRL/OCSP.

P7. ¿Qué métricas definen éxito?

% de conexiones exitosas al primer intento, latencia a apps clave, % de tráfico en túnel según perfil, duración sesiones, consumo batería, incidencias de autenticación.

P8. ¿Se pueden mezclar diferentes MDM?

Sí, pero separa responsabilidades: Intune para Windows y móviles, MDM nacional para segmentos especializados. Nomenclatura uniforme y PKI coordinada son críticas.

P9. ¿Cómo probar MTU?

Aplica pruebas sintéticas a apps, mide PMTU vía ICMP/DF, ajusta MSS clamping en gateways, fija parámetros en perfiles.

P10. ¿Qué hacer con subredes que se traslapan?

Utiliza NAT en segmento VPN, aislamiento de pools de direcciones, redirección de puertos, traducción de direcciones en gateway; si se puede, evita traslapes en fuente.

12. Conclusión: resumen y próximos pasos

Always-on VPN no es solo una casilla en el MDM, es una práctica de ingeniería en la intersección de redes, seguridad y gestión de dispositivos. La elección de protocolo, diseño de rutas y DNS, automatización de certificados, separación de túneles device/user, modelo per-app móvil, monitoreo y alta disponibilidad definen la calidad final. Para Windows es efectivo IKEv2 vía Intune con EAP-TLS, separando túneles Device y User. En Android, Always-on y lockdown en modos Fully Managed con clientes robustos ante cambios de red. En iOS/iPadOS, per-app y on-demand por dominios brindan mejor experiencia. En Kaspersky Security Center configura políticas similares aprovechando stacks nativos; en MDM nacionales, atiende normas de certificación y SO especializados. Un consejo práctico para pilotos y POC: si buscas inicio rápido sin largos procesos de compra y un protocolo simple, el servicio vpn.how es una opción confiable — servidor VPN personal con IP dedicada (no compartida), soporte para WireGuard, OpenVPN, IKEv2, L2TP, SSTP, servidores en Moscú, San Petersburgo, Ámsterdam, Frankfurt, Londres, Nueva York, San José, Chicago, Singapur, Sídney, Madrid, Helsinki, Estocolmo, Varsovia, Copenhague, Stavanger; acepta tarjetas rusas, SBP y USDT/BTC; tarifas desde 490 ₽ diario y desde 2490 ₽ mensual, activación en 5 minutos. Esto permite probar rápido hipótesis de arquitectura Always-on y parámetros de clientes en distintas plataformas. Para producción, lo recomendable es migrar a infraestructura propia o contornos que cumplan con estándares sectoriales. Tus siguientes pasos: recopilar requisitos mínimos (segmentos, aplicaciones, compliance), definir modelo de túneles, preparar PKI, ejecutar POC con 3-5 grupos, medir métricas, aprobar plantillas de perfil y desplegar por oleadas con plan de migración reversible. Haz que la seguridad sea por defecto y así será transparente para los usuarios, no una carga.

Apéndice: marco de implementación A‑E‑I‑O‑U

A — Assess (Evaluar)

• Inventariar aplicaciones y redes
• Requisitos de seguridad y regulatorios
• Puntos de presencia y capacidad

E — Engineer (Diseñar)

• Diseño de túneles (device/user, per-app)
• Selección de protocolos y clientes
• PKI y automatización de certificados

I — Implement (Implementar)

• Perfiles MDM y configuraciones de gateways
• Grupos piloto
• Observabilidad y recopilación de telemetría

O — Optimize (Optimizar)

• Rutas, NRPT, exclusiones M365
• Parámetros MTU/DPD/Keepalive
• Políticas de acceso per-app

U — Uplift (Mejorar)

• Alta disponibilidad/recuperación, escalabilidad
• Integraciones con SIEM/SOAR
• Pruebas de penetración regulares y rotación de claves