Cisco 300-410: VPN, Tunelización y Conectividad Remota — Guía de estudio
Forma parte de la Cisco CCNP Enterprise 300-410 ENARSI — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Cisco, o realiza tests cronometrados en ExamRoll.io.
Resumen
Las técnicas de VPN, tunelización y conectividad remota permiten la comunicación privada y regida por políticas sobre redes compartidas. Los diseños dependen de las elecciones de encapsulación (GRE, IPsec, VTIs), el intercambio de claves (IKEv1/2), la resolución del plano de control (NHRP en DMVPN) y las realidades del transporte (MTU, NAT, failover). Esta sección explica cómo combinar estos componentes básicos para producir redes superpuestas (overlay) escalables, seguras y resilientes, tanto para casos de uso de sitio a sitio como de acceso remoto.
Fundamentos de GRE e IPsec
Generic Routing Encapsulation (GRE) es una encapsulación simple y sin estado que transporta casi cualquier protocolo de Capa 3 sobre una red subyacente (underlay) IP. Propiedades clave:
- Comportamiento y encapsulación: GRE añade una cabecera IP externa de 20 bytes más una cabecera GRE de 4 bytes (24 bytes en total). GRE no tiene cifrado ni autenticación nativos.
- Enrutamiento: GRE proporciona una interfaz de túnel numerada que participa en el enrutamiento y admite adyacencias de IGP sobre la red superpuesta.
- MTU, fragmentación, MSS: La sobrecarga añadida reduce el MTU efectivo de la carga útil (payload). Sin mitigación, los agujeros negros de PMTUD y la fragmentación IP pueden degradar el rendimiento. La mejor práctica es establecer un MTU más pequeño en la interfaz del túnel y limitar (clamp) el MSS de TCP para evitar la fragmentación en la red superpuesta.
Ejemplo de GRE punto a punto con MTU y MSS seguros:
interface Tunnel1
ip address 172.20.1.2 255.255.255.0
ip mtu 1400
ip tcp adjust-mss 1360
tunnel source 10.10.2.2
tunnel destination 10.10.1.1
IPsec proporciona confidencialidad, integridad y anti-repetición:
- Modos: El modo de transporte asegura solo la carga útil (payload); la cabecera IP original se mantiene. El modo túnel encapsula todo el paquete IP con una nueva cabecera IP externa. GRE sobre IPsec típicamente usa el modo de transporte de IPsec para minimizar la sobrecarga; las VTI basadas en rutas usan el modo túnel de IPsec.
- Selectores (proxy IDs / selectores de tráfico): Definen qué flujos de 5-tupla están protegidos. Las VPN basadas en políticas usan ACLs para definir los selectores; las VPN basadas en rutas usan selectores 0.0.0.0/0 (o ::/0) vinculados a una interfaz de túnel, donde el enrutamiento determina el tráfico.
- Cifrado e integridad: AES-GCM proporciona cifrado autenticado en una sola transformación y reduce la sobrecarga por paquete en comparación con AES-CBC + HMAC. Use grupos DH modernos (14/19+) y PFS para la confidencialidad directa (forward secrecy). Alinee las capacidades de transformación/propuesta en ambos pares (peers).
Compromisos entre fragmentación y rendimiento (throughput):
- La pre-fragmentación (look-ahead fragmentation) solo funciona en modo túnel. Puede mejorar el rendimiento al evitar el reensamblaje en el host final que descifra, a costa de fragmentos IP adicionales a través de la red subyacente.
- La fragmentación después del cifrado se usa a menudo con GRE sobre IPsec en modo de transporte y NAT-T; combinada con la limitación de MSS, reduce la posibilidad de agujeros negros de PMTUD.
- PMTUD vs. MTU fijo: Si el ICMP de la red subyacente está filtrado, confíe en un MTU de túnel conservador y en la limitación de MSS.
Aplicando IPsec a GRE con protección de túnel:
crypto isakmp policy 10
encr aes 256
hash sha256
authentication pre-share
group 14
lifetime 28800
crypto isakmp key Test address 0.0.0.0 0.0.0.0
crypto ipsec transform-set TS esp-gcm 256 mode transport
!
crypto ipsec profile GRE-PROF
set transform-set TS
!
interface Tunnel10
ip address 10.10.10.1 255.255.255.0
ip mtu 1400
ip tcp adjust-mss 1360
tunnel mode gre multipoint
tunnel protection ipsec profile GRE-PROF
Intercambio de Claves, NAT Traversal y Estilos de VPN
IKE negocia las SAs para IPsec.
- IKEv1: Modos Main y Aggressive para la Fase 1; modo Quick para la Fase 2. Configure políticas (“crypto isakmp policy”), autenticación (PSK o certificados), tiempo de vida (lifetime) y grupos DH. Solucione problemas con
show crypto isakmp say depuraciones (debugs) para los intercambios MM/AM/QM y las discrepancias de proxy ID. - IKEv2: Modelo de intercambio único con propuestas, políticas y perfiles. Admite múltiples SAs hijas (child SAs), EAP para acceso remoto y una mejor señalización de errores. FlexVPN estandariza el uso de IKEv2 y el comportamiento basado en rutas a través de VTIs. Solucione problemas con
show crypto ikev2 sa/session,show crypto ipsec say depuraciones (debugs).
NAT traversal y keepalives:
- NAT-T detecta la presencia de NAT en la ruta y encapsula ESP en UDP/4500. Asegúrese de que ambos pares habiliten NAT-T. Los keepalives de IKE y la Detección de Par Inactivo (DPD) eliminan las SAs obsoletas; ajuste los temporizadores para que coincidan con las necesidades de la aplicación.
- La alcanzabilidad del origen/destino del túnel es fundamental: la red subyacente debe poder enrutar hacia los puntos finales del túnel. Proporcione rutas estáticas o enrutamiento dinámico en la red subyacente para garantizar que las IP externas sigan siendo alcanzables durante los eventos de failover.
- Los keepalives de GRE funcionan para GRE punto a punto, pero no para mGRE. Para redes superpuestas, use temporizadores de IGP, temporizadores de NHRP o BFD. Los paquetes de control de BFD usan el puerto UDP 3784 y pueden detectar fallos de ruta rápidamente; intégrelo con los IGPs para una convergencia por debajo del segundo.
VPNs basadas en políticas vs. basadas en rutas:
- Basadas en políticas: Crypto map con selectores de “tráfico interesante” mediante ACL. Pros: simple para conexiones sitio a sitio pequeñas y estáticas. Contras: complejo con muchos prefijos, problemas de enrutamiento asimétrico y soporte deficiente para la comunicación entre spokes.
- Basadas en rutas: Interfaces de túnel virtuales (VTI/dVTI/FlexVPN) con selectores por defecto (any/any); el enrutamiento determina los flujos protegidos. Pros: escalable, admite enrutamiento dinámico y hairpin/comunicación entre spokes, criptografía más simple. Es el método preferido para diseños modernos.
Acceso remoto con IKEv2/FlexVPN:
- Use perfiles de IKEv2, autenticación EAP y dVTIs para asignar políticas por usuario/por grupo. Diagnostique con
show crypto ikev2 say los registros de AAA. La limitación de MSS y el túnel dividido (split tunneling) mitigan los problemas de MTU y rendimiento en redes de clientes diversas.
Enrutamiento basado en políticas (PBR) para fallbacks:
- Al dirigir flujos que de otro modo no estarían enrutados hacia un túnel o una salida específica, use PBR con
set ip default next-hoppara especificar un siguiente salto por defecto cuando la RIB no tiene una ruta coincidente, minimizando la dependencia de rutas estáticas por defecto durante un failover.
Diseño y operación de DMVPN
DMVPN combina mGRE, NHRP e IPsec para construir topologías hub-and-spoke o spoke-to-spoke escalables.
- mGRE: Una interfaz de túnel termina múltiples peers dinámicamente; no se requiere un túnel por cada spoke en el hub. El punto final del túnel es una única dirección NBMA “any-to-any”.
- NHRP: Resuelve los siguientes saltos de la red superpuesta (overlay) a las direcciones de la red subyacente (underlay) NBMA. El spoke se registra con el NHRP Next Hop Server (NHS) en el hub. Las consultas NHRP permiten la resolución spoke-to-spoke bajo demanda.
- Spokes e IP dinámicas: Los spokes detrás de un NAT o con direcciones dinámicas pueden requerir
ip nhrp registration no-uniquepara permitir el registro sin una NBMA globalmente única. - Fases:
- Fase 1: Los spokes usan el hub para todo el tráfico; no hay comunicación directa spoke-to-spoke.
- Fase 2: Los spokes forman túneles directos después de la resolución NHRP; el enrutamiento debe anunciar los prefijos de los spokes sin sumarización que oculte los siguientes saltos.
- Fase 3: Añade redirección/atajo (redirect/shortcut) de NHRP para reescribir dinámicamente los siguientes saltos; permite la sumarización en el hub y el reenvío óptimo spoke-to-spoke.
- OSPF sobre DMVPN: mGRE utiliza por defecto el modo broadcast de OSPF; el hub debería convertirse en el DR para estabilizar las adyacencias—establezca la prioridad de OSPF > 1 en el hub y 0 en los spokes. Alternativamente, use el modo point-to-multipoint para evitar DR/BDR, pero acepte una mayor sobrecarga de LSA.
- IPv6: Construya adyacencias IPv6 sobre DMVPN usando
tunnel mode gre multipoint ipv6y NHRP para los mapeos de IPv6. Las redes superpuestas de doble pila (dual-stack) pueden ejecutar IPv4 e IPv6 simultáneamente en la misma interfaz mGRE. - Integración con IPsec: Proteja mGRE con un único perfil de IPsec usando
tunnel protection. Prefiera el modo de transporte para GRE sobre IPsec. - MTU y fragmentación: Aplique valores conservadores de
ip mtueip tcp adjust-mssy considerecrypto ipsec fragmentation after-encryptionpara maximizar el MSS de TCP negociado y evitar fallos de PMTUD.
Extractos típicos de la Fase 3:
! Hub
interface Tunnel10
ip address 10.0.0.1 255.255.255.0
ip nhrp map multicast dynamic
ip nhrp network-id 10
ip nhrp redirect
tunnel mode gre multipoint
tunnel protection ipsec profile DMVPN-PROF
ip ospf network broadcast
ip ospf priority 100
! Spoke
interface Tunnel10
ip address 10.0.0.11 255.255.255.0
ip nhrp network-id 10
ip nhrp nhs 10.0.0.1
ip nhrp map multicast dynamic
ip nhrp shortcut
ip nhrp registration no-unique
ip mtu 1400
ip tcp adjust-mss 1360
tunnel mode gre multipoint
tunnel protection ipsec profile DMVPN-PROF
Traducción de NAT (NAT traversal): Asegúrese de que NAT-T esté habilitado y que el hub sea accesible en los puertos UDP/500 y UDP/4500. Los túneles dinámicos spoke-to-spoke requieren que la red subyacente (underlay) permita el tráfico directo UDP/4500 y ESP/UDP entre los spokes si no hay relés de NAT-T en la ruta.
Operaciones y solución de problemas:
show dmvpn,show ip nhrpyshow crypto ipsec sapara verificar los registros de NHRP y las SAs de IPsec.- Para el enrutamiento, confirme que los anuncios del hub no ocultan los detalles de los spokes en la Fase 2, y que las redirecciones/atajos (redirects/shortcuts) de NHRP están ocurriendo en la Fase 3.
- mGRE no soporta keepalives de GRE; dependa de los temporizadores de NHRP/IGP o de BFD para la detección de fallos.
← Calidad de Servicio y Protección del Plano de Control · Todos los dominios · Servicios de Red →
Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Aprueba tu examen →