0% del curso completado
VPNs IPsec: remote access y site-to-site (4.5)
📋 En esta lección
Cierre del módulo: cómo dos sedes — o un empleado en un hotel — se comunican sobre Internet como si compartieran cable, sin que nadie en el camino lea ni altere nada. Aquí aprendes el concepto de túnel, los dos grandes tipos de VPN (site-to-site y remote access), la caja de herramientas de IPsec (IKE, ESP, los modos) a nivel CCNA, y dónde encajan las VPN TLS.
El problema: Internet es de todos
Tu sede de Madrid y la de Barcelona necesitan hablarse — con direcciones privadas (4.2) y datos internos — a través de una red pública donde cada salto es un tercero desconocido. Las líneas dedicadas existen y cuestan fortunas; la alternativa universal es la VPN: un túnel cifrado sobre Internet.
Túnel = encapsular el paquete original (privado) dentro de otro paquete (público) — la muñeca rusa de la lección 1.5, con una capa extra: entre ambos, cifrado e integridad. Los routers del camino solo ven el sobre exterior (IP pública → IP pública, contenido ilegible); el paquete interior — con sus 10.x de origen y destino — viaja intacto y secreto.
[LAN Madrid 10.1.0.0/16]──[R-MAD]═══════ Internet ═══════[R-BCN]──[LAN BCN 10.2.0.0/16]
└── túnel IPsec: paquetes 10.x cifrados dentro de paquetes públicos ──┘
Lo que la VPN garantiza es la tríada de la 10.1 aplicada al tránsito: confidencialidad (cifrado — AES), integridad (hashes — SHA), autenticación (los extremos demuestran ser quienes dicen — PSK o certificados). No garantiza velocidad ni disponibilidad: sigue siendo Internet por debajo.
Los dos tipos
Site-to-site: red con red
Los routers/firewalls de frontera montan el túnel entre ellos; los usuarios ni lo saben — sus paquetes hacia la otra sede se cifran al salir y se descifran al llegar, de forma transparente. Es la interconexión permanente de sedes: el tráfico 10.1.x → 10.2.x entra al túnel según la política ("tráfico interesante") y las tablas de rutas de ambos lados apuntan la sede remota hacia el túnel (el routing de la 7.2, con el túnel como siguiente salto lógico).
Remote access: persona con red
El cliente VPN en el dispositivo del usuario (Cisco Secure Client/AnyConnect y equivalentes) levanta un túnel individual contra el concentrador de la empresa (firewall/router). El portátil recibe una IP interna y "está en la oficina" desde cualquier red — hotel, casa, tren. Aquí la autenticación es por usuario (contra el AAA de la 10.3, MFA incluido — 10.2), y las políticas pueden ser por identidad.
| Site-to-site | Remote access | |
|---|---|---|
| Extremos | Router/firewall ↔ router/firewall | Cliente software ↔ concentrador |
| Quién lo nota | Nadie (transparente) | El usuario (conecta/desconecta) |
| Duración | Permanente | Por sesión |
| Autenticación | Entre equipos (PSK/certificados) | Por usuario (AAA + MFA) |
| Tecnología típica | IPsec | TLS o IPsec |
IPsec: la caja de herramientas
IPsec no es un protocolo sino un marco (suite) estándar para asegurar tráfico IP. Sus piezas, al nivel que exige el CCNA:
Las dos fases (IKE)
IKE (Internet Key Exchange) es la negociación previa — dos fases:
- Fase 1: los extremos se autentican mutuamente (PSK — la clave precompartida del túnel — o certificados) y establecen un canal de gestión seguro, acordando algoritmos e intercambiando claves con Diffie-Hellman (acordar un secreto sobre un canal público sin transmitirlo — la misma familia de magia que viste en SAE, 9.3).
- Fase 2: dentro de ese canal se negocian las SAs (Security Associations) del tráfico real: qué se cifra (el "tráfico interesante", definido — cómo no — con ACLs, 10.5), con qué algoritmos, y las claves de sesión que rotarán periódicamente.
(IKEv2 es la versión actual: más simple, robusta y con soporte de movilidad — la que configuran los despliegues modernos.)
El transporte: ESP
ESP (Encapsulating Security Payload, protocolo IP 50) es quien lleva los datos protegidos: cifra (AES) y autentica/integra (SHA-HMAC) cada paquete. Su hermano AH (protocolo 51) solo autentica sin cifrar — incompatible con NAT y prácticamente en desuso: ESP es la respuesta salvo pregunta muy rebuscada. Y como los protocolos 50/51 no tienen puertos, atravesar NAT/PAT (8.3) exige NAT-T: encapsular ESP en UDP 4500 — el detalle que explica "la VPN no levanta detrás del router de casa".
Los modos
- Modo túnel: se cifra el paquete IP completo y se le pone cabecera IP nueva (las públicas de los extremos). El de las VPN site-to-site — las IPs privadas interiores quedan ocultas.
- Modo transporte: se cifra solo la carga, conservando la cabecera IP original. Para proteger tráfico entre dos hosts concretos (p.ej. asegurar una comunicación servidor-servidor) — no para unir redes.
El resumen ejecutivo de algoritmos
Cifrado: AES (128/256 — GCM en despliegues modernos). Integridad: SHA-2. Intercambio: DH (grupos modernos, 14+). Autenticación de extremos: PSK (simple, común en site-to-site) o certificados (escala mejor). Los nombres exactos importan menos que saber qué papel juega cada familia — eso sí lo pregunta el examen.
VPNs TLS: la otra familia
Las VPN de acceso remoto modernas usan mayoritariamente TLS (el mismo protocolo de HTTPS — TCP 443): atraviesan cualquier red (¿qué firewall bloquea el 443?), sin clientes exóticos ni problemas de NAT. AnyConnect/Secure Client, OpenVPN y WireGuard-adyacentes viven en esta filosofía. La distinción de examen: site-to-site = IPsec; remote access = TLS (o IPsec) — y el porqué: atravesabilidad y experiencia de usuario contra la eficiencia y estandarización router-a-router de IPsec.
📝 📝 Hacia dónde evoluciona esto
El acceso remoto por VPN convive ya con el modelo ZTNA (Zero Trust Network Access): en vez de "entrar a la red" y ver todo lo que las ACLs permitan, cada acceso a cada aplicación se autoriza individualmente por identidad y contexto. Para el CCNA basta la idea; la implementación es territorio de certificaciones de seguridad.
Verificación (conceptual, nivel CCNA)
En un túnel IPsec de IOS, los comandos que leen su estado — reconócelos:
R1# show crypto ike sa ← ¿la fase 1 está arriba? (estado ACTIVE)
R1# show crypto ipsec sa ← las SAs de fase 2: paquetes cifrados/descifrados
#pkts encaps: 48211, #pkts encrypt: 48211
#pkts decaps: 47903, #pkts decrypt: 47903
Los contadores encrypt/decrypt creciendo en ambos sentidos = túnel vivo y tráfico fluyendo. Encrypt sube y decrypt no = enviamos y no vuelve nada — el "camino de vuelta" de la 7.2, versión cifrada. La configuración completa (crypto maps / túneles virtuales) es territorio CCNP; el CCNA pide el modelo y la lectura.
Relación con otros conceptos
- El túnel es encapsulación (1.5) con cifrado (CIA — 10.1); el "tráfico interesante" se define con ACLs extendidas (10.5).
- NAT-T existe por el NAT/PAT de 8.3; las rutas hacia el túnel son las estáticas/dinámicas del Módulo 7.
- La autenticación de usuarios del remote access es el AAA + MFA de 10.2-10.3; DH comparte familia con el SAE de 9.3.
- El túnel CAPWAP (9.2) era encapsulación sin cifrado de datos por defecto — comparar ambos consolida el concepto de túnel.
Resumen
Una VPN monta un túnel (paquete privado dentro de paquete público) con cifrado, integridad y autenticación sobre Internet. Site-to-site: router↔router, transparente y permanente — IPsec en modo túnel. Remote access: cliente↔concentrador, por usuario (AAA+MFA) — mayoritariamente TLS (443: atraviesa todo). IPsec por dentro: IKE negocia en dos fases (1: autenticación de extremos —PSK/certificados— y canal seguro via DH; 2: las SAs del tráfico real, elegido por ACLs), ESP (IP 50) cifra y autentica los datos (AH sin cifrado, en desuso; NAT-T = ESP sobre UDP 4500 para sobrevivir al NAT), algoritmos: AES + SHA-2 + DH. Verificación: show crypto ike sa (fase 1 ACTIVE) y show crypto ipsec sa (contadores encrypt/decrypt creciendo en ambos sentidos).