Quien necesita conectar de forma segura redes Cloud-VPC se encuentra rápidamente con un conflicto de objetivos: lo más estable y con mejor rendimiento posible, pero al mismo tiempo comprensible, segmentado y operativo/seguro en operación. En la práctica rara vez se trata solo de „una conexión a la nube“. Se trata de un acoplamiento de red entre dominios de seguridad (p. ej. centro de datos on-premises, Cloud-VPC/VNET, redes de socios) que debe funcionar en el día a día: implementaciones, copias de seguridad, monitorización, identidad/directorio, procesos de actualización y parcheo, flujos de datos para software empresarial y soluciones de software cercanas al proceso.
Este artículo compara Site-to-Site-VPN (IPsec) con conexiones dedicadas como AWS Direct Connect y Azure ExpressRoute. El enfoque no está en promesas de marketing, sino en la operación: requisitos previos, riesgos, trampas típicas, pasos de comprobación, resolución de problemas y una estrategia de contingencia. Términos como VPC (Virtual Private Cloud, red en la nube lógicamente aislada) y VNET (Azure Virtual Network, equivalente de Azure a la VPC) se ubican de entrada en ese contexto.
Conectar de forma segura redes Cloud-VPC en la práctica
Antes de comparar VPN o Direct Connect/ExpressRoute, conviene una breve comprobación de la realidad. Muchas decisiones erróneas surgen porque los requisitos se formulan solo como „necesitamos acceso“. Mejor son criterios verificables:
- Disponibilidad y riesgo: ¿Qué tan crítica es la conexión? ¿Qué ocurre ante una interrupción de 15 minutos? ¿Y ante 2 horas? ¿Qué objetivos RTO/RPO (objetivos de recuperación/objetivos de pérdida de datos) dependen de ello?
- Perfil de tráfico: Muchos flujos pequeños (API, autenticación, administración) frente a transferencias grandes (copias de seguridad, replicación, procesamiento por lotes). Importante, porque VPN y conexiones dedicadas reaccionan de forma distinta respecto a rendimiento, jitter y MTU.
- Sensibilidad a la latencia: flujos de directorio y autenticación (p. ej. LDAP/Kerberos), accesos a bases de datos o servicios de terminal son claramente más sensibles que integraciones asíncronas.
- Modelo de seguridad: confianza basada en la red (clásica) vs. Zero-Trust (acceso según identidad/política). Aunque Zero-Trust suele implementarse en la capa de aplicación/identidad, influye en la segmentación, el logging y el radio de impacto en la red.
- Complejidad de enrutamiento: ¿Una subred en la nube o muchas redes, múltiples ubicaciones, socios, varias nubes? Aquí se decide si aún puede trabajarse de forma ordenada con rutas estáticas o si se necesita BGP.
- Frecuencia de cambios: ¿Con qué frecuencia cambian las redes, los workloads, las regiones? Los cambios frecuentes abogan por patrones claramente estandarizados (p. ej. hub-and-spoke, tránsito centralizado) y una automatización limpia.
Si esos puntos están claros, la selección tecnológica es mucho más sencilla — y evitará el clásico: una „solución VPN rápida“ que más tarde entra en crisis por enrutamiento, segmentación y operación.
VPN vs Direct Connect/ExpressRoute: principios básicos y características típicas
Site-to-Site VPN suele significar IPsec (Internet Protocol Security, cifrado y autenticación a nivel de red) sobre Internet público. La conexión normalmente se establece en dos fases: IKE (Internet Key Exchange, negociación de las Security Associations) y a continuación el canal de datos ESP (Encapsulating Security Payload). Opcionalmente aparece NAT-T (NAT Traversal) cuando hay NAT en el camino y por eso IPsec debe encapsularse en UDP.
Direct Connect (AWS) und ExpressRoute (Azure) sind dedizierte, private Anbindungen über Provider/Carrier. Sie nutzen zwar ebenfalls Routing (oft BGP, Border Gateway Protocol – enrutamiento dinámico entre sistemas autónomos), laufen aber nicht über das öffentliche Internet. Wichtig: „privat“ heißt nicht automatisch „verschlüsselt“. Viele Designs setzen für sensible Daten weiterhin auf zusätzliche Verschlüsselung (z. B. IPsec über die private Leitung oder TLS auf Applikationsebene).
Was spricht im Alltag für ein Site-to-Site VPN?
- Schnelle Verfügbarkeit: Oft in Stunden bis Tagen umsetzbar, ohne Provider-Bereitstellung.
- Geringe Einstiegshürde: Gut für erste Hybrid-Szenarien, Pilot, temporäre Migrationen.
- Flexibel für mehrere Standorte: Besonders wenn Sie ohnehin Internet-Uplinks und ein Edge-Gateway betreiben.
Typische Grenzen: schwankende Latenz/Jitter, Abhängigkeit von Internet-Qualität, MTU-Fallen, sowie Performance-Limits auf den VPN-Gateways. Außerdem kann Betrieb unübersichtlich werden, wenn viele Netze und Policy-Ausnahmen wachsen.
Was spricht im Alltag für Direct Connect/ExpressRoute?
- Stabilere Latenz und oft besser planbarer Durchsatz, weil der Pfad nicht „Internet-best-effort“ ist.
- Skalierung für viele Netze/Standorte, insbesondere wenn Sie BGP sauber nutzen.
- Betriebsintegration: Provider liefern häufig klarere SLAs und besser messbare Leitungszustände.
Typische Grenzen: Vorlaufzeiten (Bereitstellung, Cross-Connects), Kosten und mehr Abhängigkeiten (Provider, Meet-Me-Room, Port-Kapazitäten). Außerdem ist die Architekturentscheidung wichtiger: Ein falsch gebauter Hub kann schnell zum Single Point of Failure werden.
Architektur-Patterns: Hub-and-Spoke, Transit und Segmentierung
Unabhängig vom Transport (VPN oder dedizierte Leitung) entscheidet die Netzwerkarchitektur darüber, ob Sie langfristig sicher und operativ stabil arbeiten. Drei Muster sind im Enterprise-Alltag häufig:
1) Punkt-zu-Punkt (direkt) – nur für kleine Umfänge
Ein Standort spricht direkt eine VPC/VNET an. Das ist schnell, aber skaliert schlecht: Jede neue VPC/VNET und jedes neue Subnetz erhöht die Anzahl an Tunneln, Routen und Firewall-Regeln. Das Risiko für Asymmetrie (Hin- und Rückweg unterschiedlich) steigt.
2) Hub-and-Spoke – zentrale Kontrolle
Sie bauen einen Hub (z. B. zentrale Netzwerk-VPC/VNET) und hängen Spokes (Workload-VPCs/VNETs) daran. Im Hub liegen zentrale Services: Firewalling, NAT, DNS-Resolver, Proxies, Logging, ggf. Bastion/Jump. Das unterstützt Segmentierung (Trennung von Zonen) und erleichtert Audits, weil „Kontrollpunkte“ klarer sind.
3) Transit/Virtual WAN – Routing als Plattform
En AWS eso suele ser un Transit Gateway (router/transito central para muchas VPC y conexiones on‑prem). En Azure un equivalente frecuente es Virtual WAN (orquestación WAN, conectividad centralizada mediante hubs). Ventaja: enrutamiento dinámico, conexiones estandarizadas, mejor escalabilidad. Desventaja: debe diseñar las políticas de enrutamiento y seguridad con mucha deliberación para evitar que, de pronto, „todo hable con todo“.
Mejor práctica para diseños seguros: Segmentación antes de la conectividad. Defina zonas (p. ej. Management, Shared Services, Producción, Partner, Dev/Test) y decida qué flujos están permitidos. A continuación implemente los enlaces (VPN/Direct Connect/ExpressRoute) de modo que la segmentación se aplique técnicamente (Security Groups/NSGs, políticas de firewall, tablas de rutas).
Ordenar el enrutamiento: BGP, rutas estáticas y Route Propagation
Muchos incidentes parecen „VPN roto“, pero en realidad son temas de enrutamiento o de políticas. Dos términos deberían figurar en cada runbook:
- Rutas estáticas: Next-Hops configurados de forma fija. Sencillas, pero propensas a errores ante cambios y en escenarios con redundancia (el failover debe planificarse activamente).
- BGP: enrutamiento dinámico en el que se intercambian prefijos (redes). BGP puede representar el failover y el crecimiento con mucha más fidelidad, pero exige disciplina (listas de prefijos, filtros, métricas/Local Preference, estrategias de community).
En entornos en la nube aparece un tercer factor: Route Propagation (propagación de rutas). Según la plataforma, las rutas pueden incorporarse automáticamente a las tablas de rutas o no. Trampa típica: el túnel está establecido, BGP está „up“, pero la subred no tiene ruta al destino porque la tabla de rutas no se propagó o no está asociada.
Trampas típicas de enrutamiento (y por qué ocurren)
- Espacios de direcciones IP superpuestos: si on‑prem y la nube usan las mismas redes RFC1918 (p. ej. 10.0.0.0/8 sin coordinación), el enrutamiento será poco fiable. Esto no es un „problema de la nube“, sino de gestión de direcciones. Solución: limpiar el plan IP; si es necesario, aplicar una estrategia de NAT con reglas claras de registro (logging).
- Enrutamiento asimétrico: ida por VPN, vuelta por Internet/NAT o por otro enlace. Muchas firewalls y gateways VPN son stateful y descartan paquetes de retorno si el flujo no vuelve por la misma ruta.
- Ruta por defecto dentro del túnel sin planificación: un „0.0.0.0/0 hacia el VPN“ puede cambiar por completo los puntos de salida a Internet y el egress desde la nube. Eso provoca fallos, no solo „más seguridad“.
- Prefijos demasiado grandes o demasiadas rutas: límites de la plataforma (máx. rutas en tablas de rutas, máx. prefijos por sesión BGP) suelen detectarse tarde. Resultado: enrutamiento parcial, „algunas redes funcionan, otras no“.
Buenas prácticas de seguridad: cifrado, políticas, registros y gestión de claves
„Conectar de forma segura“ significa en operación: confidencialidad, integridad, trazabilidad y propagación controlada. Para VPN y enlaces dedicados surgen ámbitos de actuación similares:
Cifrado: ¿Qué es obligatorio y qué es recomendable?
En IPsec VPN el cifrado es una parte integral. Es importante elegir parámetros que se ajusten a su entorno (p. ej., IKEv2 en lugar de IKEv1, suites de cifrado fuertes) y garantizar la compatibilidad con los gateways en la nube. Para Direct Connect/ExpressRoute vale: el transporte es privado, pero no está automáticamente cifrado de extremo a extremo. Por eso muchas empresas optan por añadir además TLS (Transport Layer Security, cifrado a nivel de aplicación) o incluso IPsec over private link, especialmente para protocolos administrativos y flujos de datos sensibles.
Política: „Least Privilege“ en la red
El principio de Least Privilege en la red significa: solo los puertos/protocolos realmente necesarios, únicamente entre las subredes/workloads requeridas. En la nube intervienen varias capas: Security Groups/NSGs (cercanas a la workload), firewalls centrales (p. ej. en el hub) y el enrutamiento (qué es alcanzable). Una práctica recomendada:
- Primero definir los flujos como matriz de comunicación (origen, destino, puerto, propósito, responsable).
- Luego imponer la segmentación mediante subredes y tablas de enrutamiento.
- Solo después implementar reglas en Security Groups/NSGs y firewalls.
Así evita el «firewall como parche», que acaba generando demasiadas excepciones.
Registro y trazabilidad: sin datos no hay operación
Planifique desde el inicio dónde verá estados de conexión y flow-logs: estado del VPN (IKE/ESP), estado de BGP, drops en firewalls, flow-logs en VPC/VNET y la conexión central a Syslog/SIEM. Suelen ser útiles IDs correlacionables (Tunnel-ID, Peer-IP, BGP-Neighbor, Subnet/ENI/NIC) y la sincronización temporal (NTP), para que los eventos coincidan entre sistemas.
Práctica: configurar correctamente la operación de VPN (Lista de verificación)
Para la categoría VPN lo más importante es: estabilidad ante perturbaciones, secuencias de prueba claras y redundancia bien definida. La siguiente lista de verificación está deliberadamente orientada a la operación.
Preparación
- Validar el plan IP: sin solapamientos; si es inevitable, diseño NAT que incluya monitorización y documentación.
- Estrategia de MTU: IPsec reduce la MTU efectiva (overhead). Planifique MSS-clamping o una MTU de túnel adecuada (según la plataforma). Sin esto obtendrá problemas inesperados con determinados protocolos.
- Redundancia: al menos dos túneles (o dos proveedores/edges). Defina qué significa «Active/Active» frente a «Active/Standby» y cómo se mide el failover.
- IKEv2 y perfiles criptográficos: elija parámetros modernos y compatibles. Verifique las duraciones (rekey) y DPD (Dead Peer Detection, alcance del peer).
- Definir el enrutamiento: estático (pequeño) o BGP (en crecimiento). En BGP: defina filtros de prefijos y protección de máximo número de prefijos (max-prefix).
Implementación: pasos mínimos de verificación para la puesta en marcha
Si el túnel „está activo“, eso es solo el comienzo. Compruebe en este orden:
- IKE/ESP-Status: ¿Existe una Security Association activa? ¿Hay errores de rekey?
- Routen: ¿La red de destino es alcanzable y la ruta apunta realmente al túnel/transit?
- Security/Firewall: ¿Se permiten los flujos o se están descartando?
- Path MTU: ¿Funcionan paquetes más grandes? Si no, observe fragmentación/descartes.
- DNS: Con frecuencia un “la red no funciona” es en realidad un problema de DNS/Split-DNS.
Quick-Checks vom Linux-Host (Cloud o On-Prem)
Die folgenden Kommandos helfen, Symptome einzuordnen. Sie ersetzen kein Gateway-Debugging, sind aber im Incident schnell verfügbar.
# Routing zum Ziel prüfen
ip route get 10.20.30.40
# Pfad-MTU testen (Don't Fragment). Schrittweise Payload erhöhen.
# Achtung: je nach Umgebung ist ICMP gefiltert; dann ist das Ergebnis begrenzt.
ping -M do -s 1372 -c 3 10.20.30.40
ping -M do -s 1400 -c 3 10.20.30.40
# Traceroute mit TCP (falls ICMP blockiert ist) auf einen Zielport
traceroute -T -p 443 10.20.30.40
# Pakete mitschneiden (Interface anpassen), um SYN/SYN-ACK bzw. ICMP-Frag-needed zu sehen
sudo tcpdump -ni any host 10.20.30.40Por qué ayuda: Si ip route get no muestra el Next-Hop esperado, no busque en la VPN. Si ping -M do falla a partir de cierto tamaño, MTU/MSS es un candidato realista. Y tcpdump muestra rápidamente si los paquetes salen del sistema, si vuelven respuestas o si aparecen mensajes ICMP de error.
Resolución de problemas: patrones de fallo frecuentes y contramedidas específicas
En producción vale su peso en oro reconocer patrones de fallo. Aquí los patrones típicos en conectividad híbrida.
Patrón de fallo 1: el túnel está „UP“, pero no pasa tráfico
- Causas: falta de asociación a la tabla de rutas, propagación de rutas deshabilitada, Security Group/NSG bloqueando, firewall On-Prem bloqueando la ruta de retorno, selectores incorrectos/Traffic-Selectors (en VPN basada en políticas), asimetría.
- Comprobar: ruta hacia el destino (Cloud y On-Prem), puertos permitidos, Flow Logs/descartes, ruta de retorno (Reverse Path).
- Solución: corregir rutas, activar propagación (o configurar estática deliberadamente), definir la policy de forma más estricta, verificar reglas de firewall con estado.
Patrón de fallo 2: „Algunas aplicaciones funcionan, otras se quedan colgadas“
- Causas: problemas de MTU/MSS, PMTUD (Path MTU Discovery) falla, se descarta la fragmentación, protocolos con mucho UDP son sensibles al jitter.
- Comprobar: pruebas PMTU, tcpdump en busca de ICMP «fragmentation needed», comparación de payloads pequeños/grandes.
- Solución: MSS-Clamping en el Edge/firewall, ajustar MTU del túnel, manejar ICMP correctamente (no bloquearlo a ciegas).
Patrón de fallo 3: Verbindungsabbrüche alle X Minuten
- Causas: parámetros de Rekey incompatibles, DPD/Keepalive demasiado agresivo, NAT-Timeout en el proveedor, picos de carga en el gateway.
- Comprobar: registros del gateway (IKE-Rekey), timeouts de sesión, CPU/throughput en el dispositivo VPN, pérdidas de paquetes.
- Solución: armonizar intervalos de rekey, estabilizar NAT-T, distribuir la carga (más túneles/más gateways), evaluar, si procede, una línea dedicada.
Problema 4: BGP está activo, pero faltan rutas o presentan „flapping“
- Causas: filtros de prefijos demasiado estrictos o demasiado laxos, Max-Prefix-Limit disparado, conexión de underlay inestable, timers mal configurados, preferencias poco claras con múltiples caminos.
- Comprobar: rutas anunciadas/recibidas, registros relativos a Max-Prefix, estabilidad de la conexión underlay, consistencia de Communities/LocalPref.
- Solución: corregir filtros, establecer límites de forma deliberada, estabilizar el underlay, documentar y estandarizar la política de enrutamiento.
Uso correcto de conexiones dedicadas: Direct Connect/ExpressRoute en la práctica
Las conexiones dedicadas resuelven muchos problemas del „Internet“, pero introducen nuevas tareas. Tres puntos se subestiman con frecuencia en los proyectos:
1) La redundancia no es un „nice to have“
Un único puerto o un único enlace de proveedor es operacionalmente arriesgado. Planifique al menos dos rutas independientes (idealmente PoPs/Meet-Me-Rooms y proveedores diferentes). Defina criterios de failover: enlace caído, BGP down, umbrales de pérdida de paquetes/latencia. Y pruebe el failover no solo en el Go-Live, sino de forma periódica en la ventana de mantenimiento.
2) Una conexión privada no sustituye a los controles de seguridad
La conectividad „privada“ reduce la superficie de ataque (no hay Internet abierto como transporte), pero el riesgo interno persiste: errores de configuración, movimiento lateral, exposición accidental. La segmentación, el registro (logging) y el control de accesos siguen siendo obligatorios. Para accesos administrativos suele ser mejor usar bastion/jump y una identidad fuerte (MFA, Conditional Access) que permitir „RDP/SSH en todas partes“.
3) La disciplina de enrutamiento determina la estabilidad
Con ExpressRoute/Direct Connect el número de prefijos suele crecer rápidamente. Sin listas de filtro claras y ownership (¿quién puede anunciar qué redes?) se genera progresivamente una situación en la que cambios en un sitio tienen efectos imprevisibles. Mejor práctica: documentar la Prefix-Ownership, tramitar cambios mediante un proceso de change, y fijar Max-Prefix-Limits de modo que las malas configuraciones no afecten a todo el enrutamiento.
Estrategia de migración y reversión: planificar para dormir tranquilo por la noche
Una estrategia de reversión bien definida no es un documento adicional, sino parte del diseño. Para la conectividad híbrida han demostrado ser eficaces los siguientes principios:
Operación en paralelo en lugar de Big Bang
Cuando sea posible, implemente VPN y conexión dedicada en paralelo. Use prioridades de enrutamiento (p. ej., BGP-Pref, métricas) para conmutar gradualmente. Ventaja: puede medir bajo carga real (latencia, drops, tasas de error) y, ante problemas, revertir rápidamente.
Pasos de cutover explícitos con puntos de medición
Defina para el cutover una lista de verificación: accesibilidad de servicios centrales (DNS, Identity, Monitoring), flujos de negocio críticos, ventanas de backup, accesos administrativos. Es importante un criterio de detención: ¿ante qué síntoma se detiene y revierte?
Rollback no solo „posible“, sino ensayado
Los rollback suelen fallar porque, bajo estrés, alguien „rápidamente“ cambia rutas y políticas y al final nadie recuerda cuál fue el último estado estable. En la práctica ayuda:
- Versionar las configuraciones (también para dispositivos de red/objetos de enrutamiento en la nube).
- Realizar cambios en unidades pequeñas y reversibles.
- Registrar medidas antes/después (latencia, pérdida de paquetes, conteo de flujos, tasas de error).
Runbook: Estándar operativo para conectividad híbrida segura
Un buen runbook evita que cada incidente comience desde cero. Estos contenidos han demostrado ser eficaces para equipos de administración:
1) Comprobaciones de salud estandarizadas
- Estado de túneles (IKE/ESP), eventos de rekey, estado de DPD
- Vecinos BGP up/down, número de rutas recibidas/advertidas
- CPU/rendimiento del gateway, drops/errores
- Registros de flujo/drops del firewall para flujos de prueba definidos
2) Flujos de prueba definidos (sintéticos)
Elija por zona uno o dos endpoints y puertos que revise regularmente (p. ej., HTTPS en el endpoint de monitorización, DNS al resolvedor, SSH al bastión). Así detectará errores de enrutamiento/política de forma temprana, antes de que lleguen tickets de usuarios.
3) Puntos de escalado claros
¿Quién es el responsable de: IP-Plan, Cloud-Routing, On-Prem-Firewall, enlace del proveedor, DNS? Sin esta asignación, cada incidencia se convierte en una cuestión organizativa.
Conclusión: ¿Qué opción es adecuada en cada caso?
VPN es en el día a día la elección correcta cuando necesita empezar rápido, el alcance es manejable y tiene controladas las trampas típicas (enrutamiento, MTU, rekey, redundancia). Direct Connect/ExpressRoute compensa cuando la estabilidad y la escalabilidad son prioritarias, cuando se conectan muchas redes/sedes o cuando las cargas de trabajo son sensibles a las fluctuaciones de Internet. En ambos casos no decide la etiqueta del producto, sino su arquitectura: segmentación, disciplina de enrutamiento, monitorización y un plan de retroceso practicado.
Si está planificando su conexión híbrida o necesita estabilizar una configuración existente, el siguiente paso normalmente no es „más ancho de banda“, sino una matriz de comunicaciones limpia, un diseño claro de tránsito/hub y un runbook con comprobaciones medibles.