TCO de VPN corporativo: nube vs on‑prem para 100, 500 y 1000 usuarios

Introducción: por qué es relevante este tema y qué aprenderás

El VPN corporativo sigue siendo la base para el acceso remoto y la conectividad entre oficinas incluso en la era de Zero Trust y SASE. Pero en la práctica, es el costo total de propiedad, no la tecnología en sí, lo que determina la arquitectura y la elección de la plataforma. ¿Cuál es el TCO de las soluciones cloud y on-prem para 100, 500 y 1000 usuarios en 2026, considerando rendimiento, cifrado, redundancia, soporte, cumplimiento y costos ocultos de operación? En esta guía calcularemos de forma ordenada el costo total de propiedad para escenarios típicos, ofreceremos fórmulas y marcos comprobados, instrucciones paso a paso para evaluación y optimización, mostraremos casos y trampas comunes. El resultado será tu propio modelo de TCO confiable para planificar presupuesto y arquitectura técnica.

Fundamentos: conceptos clave de TCO y arquitectura de VPN empresarial

¿Qué es el TCO para VPN?

TCO (Total Cost of Ownership) es el costo total de propiedad en un periodo definido (usualmente 36–60 meses), incluyendo: CAPEX (equipos, licencias perpetuas, implementación), OPEX (mantenimiento, soporte, suscripciones, electricidad, espacio en rack, tráfico), así como costos de riesgos y tiempos de inactividad (penalizaciones por SLA, ingresos perdidos, costos reputacionales y de cumplimiento). En proyectos VPN hasta el 60% del TCO suele ser operación y personal, mientras que los costos tecnológicos dependen del protocolo elegido, arquitectura del túnel y perfil de tráfico.

Arquitecturas clave y términos

• VPN de acceso remoto: usuarios se conectan con clientes (WireGuard, OpenVPN, IKEv2, SSTP, L2TP) a un concentrador de acceso.
• VPN site-to-site: conectividad entre sedes, data centers y nubes.
• Túnel completo (full tunnel) vs túnel dividido (split tunnel): en el primero, todo el tráfico del usuario pasa por el VPN; en el segundo, sólo las subredes y aplicaciones corporativas.
• Cloud VPN: desplegado en IaaS o servicio VPN gestionado del proveedor. Pagas por recursos computacionales, tráfico, IP públicas y soporte.
• On-prem: infraestructura propia en data center o oficina: servidores o dispositivos físicos, canales de comunicación, alimentación y operación bajo tu responsabilidad.
• Protocolos: WireGuard (moderno, alto rendimiento), OpenVPN (clásico probado), IKEv2/IPsec (estándar para S2S y clientes empresariales), SSTP y L2TP para compatibilidad.

Vida útil y amortización

En hardware on-prem lo típico es amortización de 3 a 5 años. En la nube depende de la reserva, optimización para picos y posible migración entre instancias. Para planear el TCO, establece un horizonte de 36 meses y añade un escenario a 60 meses para sensibilidad. Así verás el impacto de reemplazos y evolución de carga en la elección.

Profundizando: impulsores del costo, rendimiento y riesgos

Factores que impulsan el TCO

• Rendimiento y escala: conexiones concurrentes, carga criptográfica, ancho de banda por usuario, eventos pico (videoconferencias, actualizaciones).
• Confiabilidad y disponibilidad: clusters HA, activo-activo o activo-pasivo, geo-redundancia, RTO y RPO. Más SLA implica nodos y canales adicionales más costosos.
• Seguridad y cumplimiento: MFA, PKI, HSM, auditorías, logs en SIEM, DLP, requerimientos regulatorios sectoriales. Cada control suma componentes y OPEX.
• Madurez operacional: automatización (IaC), monitoreo, actualizaciones, pruebas de fallos, documentación y capacitación. Reduce incidentes pero requiere expertos dedicados.
• Tráfico y routing: split vs full tunnel cambia radicalmente el costo del egress en la nube y capacidad de canales on-prem.
• Licencias y soporte: clientes comerciales, soporte del proveedor, planes premium en la nube vs open source y expertise propia.

Modelado de carga 2026: cambios clave

• Más videocomunicaciones y apps interactivas, por tanto mayor demanda pico de ancho de banda y sensibilidad al jitter.
• Amplia adopción de WireGuard por su mejor rendimiento por núcleo y criptografía simplificada.
• Requisitos de auditoría más estrictos: retención de logs de conexión 180–365 días, correlación con EDR e IdP, MFA por defecto.
• Crecimiento de topologías híbridas: parte de usuarios usan SASE, otros VPN corporativo (p.ej. acceso a sistemas de segundo nivel).

Enfoque basado en riesgos

Incluye en el TCO el costo de eventos: una caída del concentrador VPN por 2 horas en día laborable puede significar decenas de miles en productividad perdida. Si la empresa vende servicios online, la pérdida de transacciones eleva la cifra. Inclúyelo como costo esperado: probabilidad de incidente por daño. Medidas arquitectónicas (HA, activo-activo) reducen probabilidad y/o daño, pero suben el TCO base. El óptimo es un balance.

Método 1. Marco de TCO: fórmulas, estructura y pasos

Estructura de costos

• CAPEX: equipos (servidores, NIC, HSM), licencias perpetuas, implementación y migración.
• OPEX: instancias cloud, tráfico egress, IPs, espacio en rack y electricidad, canales DIA, soporte del proveedor, suscripciones (MFA), redundancia, monitoreo y SIEM.
• PeopleEx: FTE en operación (NOC, NetSec), guardias, capacitación y documentación.
• RiskEx: pérdidas esperadas por downtime e incidentes de seguridad, multas por cumplimiento.

Fórmulas

TCO = (CAPEX/plazo) + OPEX + PeopleEx + RiskEx. Para unificar, convierte CAPEX a amortización mensual. Unit Economics: CPUU costo por usuario/mes = TCO / número de usuarios. CPGb costo por capacidad Gbps = (costo mensual de recursos) / capacidad entregada. CPConn costo por conexión concurrente = (costo) / máximo de conexiones simultáneas.

Parámetros de carga

• Concurrencia: 20–40% de usuarios activos simultáneamente (promedio 30% para trabajadores de oficina). Picos se calculan con factor 1.5–2.0 sobre promedio.
• Perfil de tráfico: split tunnel 10–20 GB por usuario/mes; full tunnel 40–80 GB. Tomaremos base de 15 GB y 60 GB respectivamente.
• Velocidad pico por usuario activo: 2–5 Mbps para trabajo de oficina, 5–8 Mbps en videollamada HD. Usamos 5 Mbps para picos y 2.5 Mbps para margen del 50%.

Lista de verificación de supuestos

• Número de usuarios, SLA requerido (ej. 99.9%), requerimientos regulatorios.
• Split vs full tunnel, proporción Mac/Windows/Linux, clientes móviles.
• Protocolos: WireGuard por defecto, OpenVPN/IKEv2 para compatibilidad.
• Geografía y latencias: ubicación de usuarios y aplicaciones.
• Existencia de canales y data centers propios.
• Nivel de automatización y competencias del equipo.

Método 2. Cálculo de TCO: 100, 500 y 1000 usuarios (nube vs on-prem)

Supuestos generales para comparación

• Horizonte: 36 meses. Moneda: USD para neutralidad (conversión según región al implementar).
• MFA: 1 dólar por usuario/mes (a menudo es licencia corporativa, aquí se considera incremento al proyecto VPN).
• SIEM y auditoría: 150–300 USD/mes según escala (pocos logs pero con retención y correlación).
• Costos de personal: 100 mil USD anuales fully loaded por FTE en seguridad de red (8333 USD mensuales). En nube menor proporción por menos infraestructura física.
• WireGuard como protocolo base para ancho de banda; OpenVPN e IKEv2 para compatibilidad.
• Concurrencia: 30% usuarios activos simultáneamente; factor pico 2x para capacidad.

Modelado de capacidad

• 100 usuarios: 30 activos. Pico 30 × 5 Mbps × 2 = 300 Mbps (full tunnel). En split, 40% de esa carga: aprox. 120 Mbps.
• 500 usuarios: 150 activos. Pico 150 × 5 × 2 = 1500 Mbps (1.5 Gbps full). Split ~ 600 Mbps.
• 1000 usuarios: 300 activos. Pico 300 × 5 × 2 = 3000 Mbps (3 Gbps full). Split ~ 1200 Mbps.

Nube: costos mensuales

Componentes: instancias computacionales (HA 2–6 nodos), tráfico egress (0.06 USD por GB con descuentos), IP y disco (20–80 USD), soporte proveedor (300–800), operación (0.2–0.6 FTE), MFA (1 USD por usuario), SIEM (50–300). Se asume optimización por instancias y cercanía regional al usuario.

100 usuarios

• Instancias: 2 × clase media c = 68 USD total 136.
• Tráfico: split 1.5 TB ≈ 92; full 6 TB ≈ 369.
• IP y disco: 20.
• Soporte: 300.
• Operación: 0.2 FTE ≈ 1667.
• MFA: 100.
• SIEM y auditoría: 50.

Total nube 100: split ≈ 2398 USD/mes (≈ 24 USD por usuario), full ≈ 2675 USD (≈ 26.8 por usuario).

500 usuarios

• Instancias: split 400, full 600 (más nodos/clases).
• Tráfico: split 7.5 TB ≈ 461; full 30 TB ≈ 1843.
• IP y disco: 50.
• Soporte: 500.
• Operación: 0.4 FTE ≈ 3333.
• MFA: 500.
• SIEM: 150.

Total nube 500: split ≈ 5361 (≈ 10.7 por usuario), full ≈ 6943 (≈ 13.9 por usuario).

1000 usuarios

• Instancias: split 700, full 900.
• Tráfico: split 15 TB ≈ 922; full 60 TB ≈ 3686.
• IP y disco: 80.
• Soporte: 800.
• Operación: 0.6 FTE ≈ 5000.
• MFA: 1000.
• SIEM: 300.

Total nube 1000: split ≈ 7802 (≈ 7.8 por usuario), full ≈ 11766 (≈ 11.8 por usuario).

On-prem: costos mensuales

Componentes: servidores/appliances (amortización 36 meses), canales DIA (dos líneas para resiliencia), espacio en rack y electricidad, soporte proveedor, operación (0.4–1.0 FTE), MFA, SIEM, repuestos. Se asume stack open source en servidores commodity; si se usan licencias comerciales por usuario, añadir aparte.

100 usuarios

• Servidores: 2 × 2500 USD = 5000, amortización 139 USD/mes (incluye 2000 para NIC y extras, total 139).
• Canales DIA: 2 × 500 Mbps ≈ 1200.
• Espacio en rack y electricidad: 480.
• Soporte: 100.
• Operación: 0.4 FTE ≈ 3333.
• MFA: 100.
• SIEM y auditoría: 150.
• Repuestos y gastos menores: 100.

Total on-prem 100: ≈ 5479 USD/mes (≈ 54.8 por usuario).

500 usuarios

• Servidores: 2 × 4000 = 8000 más extras, amortización ≈ 166.
• Canales DIA: 2 × 1 Gbps ≈ 2400.
• Espacio en rack y electricidad: 500.
• Soporte: 200.
• Operación: 0.6 FTE ≈ 5000.
• MFA: 500.
• SIEM: 250.
• Repuestos: 150.

Total on-prem 500: ≈ 9166 USD/mes (≈ 18.3 por usuario).

1000 usuarios

• Servidores: 3 × 5000 = 15000 más extras, amortización ≈ 300.
• Canales DIA: 2 × 2 Gbps ≈ 4000.
• Espacio en rack y electricidad: 600.
• Soporte: 300.
• Operación: 1.0 FTE ≈ 8333.
• MFA: 1000.
• SIEM: 400.
• Repuestos: 200.

Total on-prem 1000: ≈ 15133 USD/mes (≈ 15.1 por usuario).

Conclusiones del análisis básico

• En los tres tamaños, la nube con split tunnel resulta más económica que on-prem, especialmente para 100 y 500 usuarios.
• El túnel completo en nube sigue siendo competitivo hasta 1000 usuarios gracias al ahorro en FTE y ausencia de canales DIA en data center, pero el costo de tráfico egress es notablemente mayor.
• On-prem gana sólo cuando hay canales DIA y data center ya pagados, alta pericia interna y aumento de carga administrativo no superior a 0.2–0.3 FTE. En ese caso, el TCO para 1000 usuarios puede bajar a 9–11 USD por usuario/mes.

Escenarios alternativos y análisis de sensibilidad

• Si los canales DIA ya están pagados (costos nulos): on-prem 1000 baja a ≈ 11133 USD (≈ 11.1 por usuario).
• Si el costo del FTE es mayor (ej. 140 mil USD anuales): la nube se encarece menos que on-prem, porque la proporción de FTE es menor en nube.
• Si se incluyen licencias comerciales de VPN (20–40 USD por usuario/año): tanto on-prem como nube aumentan en costo, pero on-prem sufre más por los canales DIA.
• Si el egress en nube es más caro (0.09 USD por GB): el túnel completo para 1000 usuarios agregaría ≈ 1843 USD en tráfico, acercándose al costo de on-prem.

Método 3. Normalización técnico-económica: cómo dimensionar infraestructura correctamente

Rendimiento de protocolos

• WireGuard: escala linealmente por núcleo, 1–2 Gbps por vCPU en hosts modernos con aceleración criptográfica. Excelente para alta densidad de usuarios.
• OpenVPN: 200–400 Mbps por núcleo con AES-NI y optimizaciones. Bueno para compatibilidad, menos eficiente.
• IKEv2/IPsec: estable para S2S, rendimiento cercano a WireGuard en hardware con aceleración.

Dimensionamiento paso a paso

1. Determina concurrencia y Mbps pico por usuario activo.
2. Calcula capacidad pico (activos × pico × margen).
3. Elige protocolo. Para clientes masivos, WireGuard; para S2S, IKEv2/IPsec; para clientes antiguos, OpenVPN.
4. Ajusta con perfil de instancias: empieza con 2 vCPU y escala a 4–8 vCPU, probando rendimiento criptográfico y cambio de contexto.
5. Planifica HA: mínimo 2 nodos activo-activo; para 500+ usuarios, considera 3–4 nodos por región.
6. Verifica MTU y MSS, especialmente con doble encapsulación y S2S; son causa común de degradación.
7. Considera límites en handshakes y rate limiting contra DoS por flood UDP.

Observabilidad y experiencia usuario

• Recolecta métricas: sesiones activas, renegociaciones, latencia a apps, PLR, ancho de banda por usuario. Visualiza en Grafana.
• Detecta anomalías: picos de egress, países fuera de patrón, intentos múltiples de login — automatiza playbooks SOC.
• Prueba degradaciones: caídas de nodo, pérdida de región, aumento repentino de carga 30–50%.

Método 4. Construir calculadora de TCO: artefactos y plantillas

Plantilla de datos de entrada

• Usuarios, porcentaje activos, split vs full, GB por usuario.
• Protocolos y distribuidores por cliente.
• Lista de regiones, latencias, requerimientos HA y DR.
• Precios de instancias/canales/espacio eléctrico, tasas FTE.

Campos calculados

• Capacidad pico, número de nodos por región, costo total instancias.
• Tráfico egress y costo asociado.
• Amortización CAPEX y OPEX.
• Personal en fracciones FTE y guardias.
• RiskEx: probabilidad × daño para 2–3 escenarios clave.

Instrucciones paso a paso

1. Recolecta baseline para 1 mes en piloto: actividad, GB, Mbps pico.
2. Aplica coeficientes de crecimiento (estacionalidad, contrataciones, nuevas apps).
3. Calcula dos escenarios: 100% split y 100% full — límites superior e inferior.
4. Agrega HA y DR encima del cálculo de nodos.
5. Detalla FTE: administración, automatización, soporte de primer nivel.
6. Realiza pruebas de estrés y ajusta dimensionamiento.
7. Consolida modelo final TCO a 36 meses y unidad económica por usuario.

Método 5. Implementación práctica: nube paso a paso

Objetivos y criterios

• SLA 99.9%, RTO 15 minutos.
• Split por defecto, full para roles privilegiados y según política.
• MFA e integración con IdP (SAML/OIDC).

Pasos

1. Selecciona regiones de instancias cercanas a usuarios.
2. Despliega 2–4 nodos WireGuard/OpenVPN en activo-activo, conecta balanceadores (L4/UDP-aware).
3. Automatiza configuración con IaC y plantillas de cliente.
4. Configura rutas split y políticas por grupos (RRHH, Dev, Finanzas).
5. Integra MFA y establece política de rotación de claves/certificados.
6. Habilita logs centralizados en SIEM, alertas por anomalías.
7. Realiza pruebas de carga y despliega siguiendo principio canario.

Checklist

• Pruebas de recuperación por caída de nodo o región.
• Procedimientos de rotación y revocación de claves.
• Documentación para soporte L1/L2.
• Revisión periódica de egress y descuentos Reserved/Committed.

Método 6. Implementación práctica: on-prem paso a paso

Objetivos y criterios

• Baja latencia hacia sistemas internos, control de canales.
• Flexibilidad en uso de HSM/PKI y cumplimiento de estándares sectoriales.

Pasos

1. Selecciona data center y configura 2 conexiones DIA independientes.
2. Compra 2–3 servidores con soporte AES-NI, NIC 10G, alimentación redundante.
3. Despliega WireGuard/IKEv2 en hipervisores o bare metal, configura activo-activo.
4. Implementa routing split, y si es necesario, IPsec basado en rutas hacia nube externa.
5. Integra MFA, IdP, logging centralizado y HSM/TPM para gestión de claves.
6. Implementa monitoreo y backups de configuración.
7. Realiza pruebas de falla: caída de un DIA, nodo, degradación de rutas.

Checklist

• Licencias comerciales y open source, acuerdos de soporte y tiempos de entrega.
• SLA con proveedores de canales, acuerdos de tiempo de reparación.
• Procedimientos Spire: repuesto NIC, servidor backup, verificación compatibilidad firmware.

Método 7. Optimización del TCO: 12 palancas de ahorro

• Split tunnel por defecto y full tunnel sólo para roles específicos. Ahorra en egress y capacidad de canal.
• WireGuard como protocolo base: mejor rendimiento por núcleo, menos CPU y menos nodos.
• Geolocalización de nodos: bajar RTT mejora eficiencia y reduce Mbps pico para mismas tareas.
• Descuentos Reserved/Committed en instancias cloud y tráfico.
• Autoescalado durante horas pico.
• Ruteo directo de tráfico SaaS (local breakout) en lugar de pasar por data center.
• Clientes unificados con configuraciones según grupos y políticas.
• Pruebas continuas de rendimiento y ajuste de MSS/MTU.
• Reducir FTE con IaC, GitOps y módulos de despliegue predefinidos.
• Agrupar logs y retención inteligente (metadata por más tiempo, logs detallados más cortos con archivo frío).
• Comprar canales con capacidad burst y SLA en jitter/latencia.
• Configurar keepalive apropiadamente para no mantener conexiones activas sin necesidad.

Errores típicos: qué evitar al construir TCO y arquitectura

• Ignorar concurrencia y picos: calcular con valores promedio sin margen autorizados causa sobrecargas y caídas.
• Elegir mal el protocolo: usar OpenVPN donde se debe WireGuard o IKEv2 genera nodos y costos excesivos.
• Túnel completo sin razón: incrementa mucho el egress y costo de canales.
• Falta de HA o redundancia en canales: ahorrar decenas de USD puede costar miles en caídas.
• No considerar operación: FTE y guardias siempre son más caros de lo esperado. Documentación y automatización se pagan solas.
• Licencia comercial sin justificación TCO: pagar por usuario duplica TCO donde open source y expertise cumplen.
• Geografía subóptima: nodos lejos de usuario aumentan latencia y costos operativos de capacidad.

Herramientas y recursos: qué usar en la práctica

Stack de protocolos y servidores

• WireGuard para acceso de usuario eficiente y S2S.
• OpenVPN para compatibilidad con clientes legacy y escenarios proxy específicos.
• strongSwan/Libreswan para IKEv2/IPsec, especialmente S2S y BGP-over-IPsec.
• SoftEther como opción multiprotocolo con NAT traversal avanzado.

Gestión y automatización

• Infraestructura como código: Terraform/Ansible para despliegue de nodos y políticas.
• CI/CD para configuraciones: GitOps, revisión de reglas de routing y ACLs.
• Monitoreo: Prometheus, Grafana, exporters para WireGuard/OpenVPN.
• Seguridad: PKI, integración con IdP (AD/Entra, Okta, Keycloak), MFA como política por defecto.
• Logs: centralizar en SIEM, normalizar formatos, monitorear login fallidos y anomalies geográficas.

Opción práctica para pilotos y PoC rápidos

Cuando quieres validar hipótesis, probar split vs full, medir carga real y generar baseline rápido sin ciclos largos de compra, es útil un servicio como vpn.how. Es un servidor VPN personal (no compartido, IP dedicada), soporta WireGuard, OpenVPN, IKEv2, L2TP, SSTP con selección según tarea, 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 (incluye Tinkoff y Ozon), SBP, USDT/BTC; tarifas desde 490 rublos diarios y 2490 rublos mensuales con descuentos por largo plazo; activación en 5 minutos tras pago. En práctica, es ideal para pilotos y POC: despliegas nodo rápido, recolectas métricas de tráfico, pruebas compatibilidad de clientes y políticas de routing. Para producción a largo plazo es mejor migrar a infraestructura propia (nube u on-prem) o soluciones certificadas como ГОСТ-VPN, según requisitos de seguridad y cumplimiento.

Casos y resultados: cómo los números impactan la elección

Caso 1: 100 usuarios, equipo de desarrollo distribuido

Objetivo: acceso seguro a Git, CI, staging. Requisitos: split tunnel, 99.9% SLA, WireGuard. Resultado: nube 2398 USD/mes (24 USD por usuario), on-prem 5479 (54.8 USD). Elección: nube con 2 nodos y IaC. De piloto a producción en 2 semanas. Ahorro del 55% respecto on-prem. Retorno de inversión en automatización (Ansible + CI/CD configs) en 3 meses por reducción de FTE de 0.3 a 0.2.

Caso 2: 500 usuarios, fintech con requisito de filtrado total de tráfico

Objetivo: túnel completo a través de contornos corporativos, inspección y registro de logs. Resultado: nube 6943 USD/mes, on-prem 9166. Sorpresa: egress subió mucho, pero FTE aún dominó en on-prem. Elección: híbrido. 60% usuarios en split (SaaS directo), 40% en full tunnel nube con inspección. Costos finales ≈ 5600 USD/mes.

Caso 3: 1000 usuarios, empresa manufacturera, baja latencia a MES

Objetivo: acceso a apps internas en DC con latencia mínima. Piloto: nube con nodos cerca de plantas mostró rendimiento aceptable, pero egress en túnel completo para algunos usuarios elevó mucho la factura. Resultado: on-prem con canales DIA y espacio ya pagados redujo TCO a 11 USD por usuario. Elección: on-prem con WireGuard e IKEv2 para S2S, modelo híbrido para usuarios en movilidad.

FAQ: preguntas profundas

1. ¿Se puede calcular el TCO sin incluir downtime y riesgos de seguridad?

Técnicamente sí, pero es un punto de referencia erróneo: una caída en hora pico puede consumir el ahorro anual de elegir opción más barata. Incluye al menos dos escenarios de riesgo con evaluación de probabilidad y daño.

2. ¿Qué tan crítico es elegir el protocolo para el TCO?

Bastante. WireGuard permite manejar misma carga con menos núcleos, reduciendo costos de nodos y consumo. Para escalas de 500+ usuarios, el ahorro puede ser 20–30% en computo.

3. ¿El split tunnel es seguro para empresas?

Sí, con política de rutas adecuada, MFA obligatorio, control de dispositivos (MDM/EDR) e inspección sólo de tráfico corporativo. Full tunnel es recomendable para roles privilegiados, admins y escenarios de cumplimiento estricto.

4. ¿Qué impacta más en el TCO cloud: computo o egress?

Hasta 500 usuarios, computo y FTE. Después de 500 con full tunnel, egress iguala o supera costos, especialmente sin descuentos ni ruteo SaaS directo.

5. ¿Cuándo on-prem es claramente mejor?

Cuando ya tienes canales DIA y espacio propio pagados, además de equipo experimentado para aumentar carga sólo 0.2–0.3 FTE. También si cumplimiento exige módulos hardware y aislamiento estricto.

6. ¿Cómo estimar número necesario de nodos?

Con base en Mbps pico y utilización objetivo por nodo (no sobrepasar 60–70%), multiplicar por factor HA. Validar en piloto y dejar 20% extra para picos inesperados.

7. ¿Qué hay de IPv6?

Habilitar IPv6 ayuda en estabilidad y rendimiento en redes móviles, pero complica rutas y políticas. Asegura soporte correcto en clientes y servidores, y que ACL y SIEM manejen dual-stack.

8. ¿Cómo incluir licencias comerciales VPN?

Cuentalas como costo incremental por usuario/mes y compáralo con open source más soporte. A menudo clientes comerciales justifican por compatibilidad y mejor telemetría.

9. ¿Se pueden mezclar protocolos?

Sí, es común. Usa WireGuard como default, mantiene OpenVPN para compatibilidad e IKEv2 para S2S y algunos móviles. Refleja proporciones en calculadora TCO.

10. ¿Cómo saber rápido si pagamos demasiado por egress?

Mira GB por usuario/mes. Si full tunnel supera 80–100 GB sin motivo claro, revisa rutas SaaS y caching, aplica split para apps no críticas.

Conclusión: resumen y próximos pasos

El costo de propiedad de un VPN corporativo no está en la marca sino en arquitectura, protocolo y madurez operativa. Para un horizonte de 36 meses, soluciones cloud con split tunnel suelen ser más económicas que on-prem hasta 1000 usuarios por menor parte de FTE y sin CAPEX. El full tunnel en nube requiere disciplina en egress y rutas SaaS para no disparar el TCO. On-prem conviene con canales propios pagados, equipo especializado y necesidades de aislamiento estrictas. Lo mejor es validar hipótesis en piloto, recoger métricas y fijar TCO para arquitectura production con SLA claros y procesos definidos. Tus siguientes pasos: 1) en 1–2 semanas armar piloto, medir concurrencia, capacidad pico y egress real; 2) construir calculadora TCO según marco presentado; 3) adoptar split por defecto, WireGuard como protocolo base y HA como requisito; 4) planear optimización con automatización, monitoreo y geografía inteligente. Así tendrás presupuesto predecible, riesgos controlados y experiencia estable para usuarios; el VPN dejará de ser una caja negra y será una herramienta con precio y valor claros.