Cisco 300-410: VPN, Tunelamento e Conectividade Remota — Guia de estudos

By Laurynas Brazys · 16 August 2026 · #cisco #300-410 #certification #exam-prep #study-guide

Faz parte do Cisco CCNP Enterprise 300-410 ENARSI — Guia de estudos. Pratique com respostas verificadas no centro de exames da Cisco, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

Técnicas de VPN, tunelamento e conectividade remota permitem comunicação privada e controlada por políticas sobre redes compartilhadas. Os projetos dependem das escolhas de encapsulamento (GRE, IPsec, VTIs), troca de chaves (IKEv1/2), resolução do plano de controle (NHRP em DMVPN) e realidades do transporte (MTU, NAT, failover). Esta seção explica como combinar esses componentes para criar redes de sobreposição (overlay) escaláveis, seguras e resilientes, tanto para casos de uso site-to-site quanto de acesso remoto.

Fundamentos de GRE e IPsec

O Generic Routing Encapsulation (GRE) é um encapsulamento simples e sem estado (stateless) que transporta quase qualquer protocolo de Camada 3 sobre uma rede de base (underlay) IP. Propriedades principais:

• Comportamento e encapsulamento: O GRE adiciona um cabeçalho IP externo de 20 bytes mais um cabeçalho GRE de 4 bytes (24 bytes no total). O GRE não possui criptografia ou autenticação nativas.
• Roteamento: O GRE fornece uma interface de túnel numerada que participa do roteamento e suporta adjacências de IGP sobre a rede de sobreposição.
• MTU, fragmentação, MSS: O overhead adicionado reduz o MTU efetivo da carga útil (payload). Sem mitigação, o “blackholing” do PMTUD e a fragmentação de IP podem degradar o desempenho. A melhor prática é definir um MTU menor na interface do túnel e limitar (clamp) o TCP MSS para evitar fragmentação na rede de sobreposição.

Exemplo de GRE ponto a ponto com MTU e 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

O IPsec fornece confidencialidade, integridade e proteção anti-replay:

• Modos: O modo de transporte (Transport mode) protege apenas a carga útil (payload); o cabeçalho IP original é mantido. O modo de túnel (Tunnel mode) encapsula todo o pacote IP com um novo cabeçalho IP externo. GRE sobre IPsec geralmente usa o modo de transporte do IPsec para minimizar o overhead; VTIs baseadas em rota usam o modo de túnel do IPsec.
• Seletores (proxy IDs / traffic selectors): Definem quais fluxos de 5-tupla são protegidos. VPNs baseadas em política (policy-based) usam ACLs para definir os seletores; VPNs baseadas em rota (route-based) usam seletores 0.0.0.0/0 (ou ::/0) vinculados a uma interface de túnel, com o roteamento determinando o tráfego.
• Criptografia e integridade: O AES-GCM fornece criptografia autenticada em uma única transformação e reduz o overhead por pacote em comparação com AES-CBC + HMAC. Use grupos DH modernos (14/19+) e PFS para “forward secrecy”. Alinhe as capacidades de transformação/proposta (transform/proposal) em ambos os peers.

Fragmentação e trade-offs de throughput:

• A pré-fragmentação (look-ahead fragmentation) funciona apenas no modo de túnel. Pode melhorar o throughput ao evitar a remontagem no host final que descriptografa, ao custo de fragmentos IP adicionais na rede de base.
• A fragmentação após a criptografia (fragmentation after-encryption) é frequentemente usada com GRE sobre IPsec em modo de transporte e NAT-T; combinada com a limitação de MSS, reduz a chance de “PMTUD black holes”.
• PMTUD vs. MTU fixo: Se o ICMP da rede de base for filtrado, confie em um MTU de túnel conservador e na limitação de MSS.

Aplicando IPsec ao GRE com proteção 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

Troca de Chaves, NAT Traversal e Estilos de VPN

O IKE negocia as SAs para o IPsec.

• IKEv1: Modos Main e Aggressive para a Fase 1; modo Quick para a Fase 2. Configure políticas (“crypto isakmp policy”), autenticação (PSK ou certificados), tempo de vida (lifetime) e grupos DH. Solucione problemas com show crypto isakmp sa e debugs para as trocas MM/AM/QM e incompatibilidades de proxy ID.
• IKEv2: Modelo de troca única com propostas (proposals), políticas e perfis (profiles). Suporta múltiplas SAs filhas (child SAs), EAP para acesso remoto e melhor sinalização de erros. O FlexVPN padroniza o uso de IKEv2 e o comportamento baseado em rota via VTIs. Solucione problemas com show crypto ikev2 sa/session, show crypto ipsec sa e debugs.

NAT traversal e keepalives:

• O NAT-T detecta a presença de NAT no caminho e encapsula o ESP em UDP/4500. Garanta que ambos os peers habilitem o NAT-T. Os keepalives do IKE e o Dead Peer Detection (DPD) removem SAs obsoletas; ajuste os temporizadores para corresponder às necessidades da aplicação.
• A alcançabilidade da origem/destino do túnel é fundamental: a rede de base deve rotear para os endpoints do túnel. Forneça rotas estáticas ou roteamento dinâmico na rede de base para garantir que os IPs externos permaneçam alcançáveis durante eventos de failover.
• Os keepalives do GRE funcionam para GRE ponto a ponto, mas não para mGRE. Para redes de sobreposição, use temporizadores de IGP, temporizadores de NHRP ou BFD. Os pacotes de controle do BFD usam a porta UDP 3784 e podem detectar falhas de caminho rapidamente; integre-o com IGPs para convergência em menos de um segundo.

VPNs baseadas em política vs. baseadas em rota:

• Baseada em política (Policy-based): Usa um “crypto map” com seletores de “tráfego de interesse” definidos por ACL. Prós: simples para conexões site-to-site pequenas e estáticas. Contras: complexo com muitos prefixos, problemas de roteamento assimétrico e suporte ruim para comunicação spoke-to-spoke.
• Baseada em rota (Route-based): Usa interfaces de túnel virtuais (VTI/dVTI/FlexVPN) com seletores padrão (any/any); o roteamento determina os fluxos protegidos. Prós: escalável, suporta roteamento dinâmico e hairpin/spoke-to-spoke, criptografia mais simples. Preferível para projetos modernos.

Acesso remoto com IKEv2/FlexVPN:

• Use perfis IKEv2, autenticação EAP e dVTIs para atribuir políticas por usuário/por grupo. Diagnostique com show crypto ikev2 sa e logs AAA. A limitação de MSS e o “split tunneling” mitigam problemas de MTU e desempenho em diversas redes de clientes.

Roteamento baseado em políticas (PBR) para fallback:

• Ao direcionar fluxos que de outra forma não seriam roteados para um túnel ou para uma saída específica, use PBR com set ip default next-hop para especificar um “next hop” padrão quando a RIB não tiver uma rota correspondente, minimizando a dependência de rotas padrão estáticas durante o failover.

Projeto e Operação do DMVPN

O DMVPN combina mGRE, NHRP e IPsec para construir topologias hub-and-spoke ou spoke-to-spoke escaláveis.

• mGRE: Uma única interface de túnel termina dinamicamente em múltiplos peers; não é necessário um túnel por spoke no hub. O endpoint do túnel é um único endereço NBMA “any-to-any”.
• NHRP: Resolve os next hops do overlay para os endereços do underlay NBMA. O spoke se registra com o NHRP Next Hop Server (NHS) no hub. As consultas NHRP permitem a resolução spoke-to-spoke sob demanda.
• Spokes e IPs dinâmicos: Spokes atrás de NAT ou com endereços dinâmicos podem exigir o comando ip nhrp registration no-unique para permitir o registro sem um NBMA globalmente exclusivo.
• Fases:
  • Fase 1: Os spokes usam o hub para todo o tráfego; não há comunicação direta spoke-to-spoke.
  • Fase 2: Os spokes formam túneis diretos após a resolução NHRP; o roteamento deve anunciar os prefixos dos spokes sem sumarização que oculte os next hops.
  • Fase 3: Adiciona o redirecionamento/atalho (redirect/shortcut) do NHRP para reescrever dinamicamente os next hops; permite a sumarização no hub e o encaminhamento otimizado spoke-to-spoke.
• OSPF sobre DMVPN: O mGRE usa por padrão o modo broadcast do OSPF; o hub deve se tornar o DR para estabilizar as adjacências — defina a prioridade do OSPF > 1 no hub e 0 nos spokes. Alternativamente, use o modo point-to-multipoint para evitar DR/BDR, mas aceite um overhead maior de LSAs.
• IPv6: Construa adjacências IPv6 sobre DMVPN usando tunnel mode gre multipoint ipv6 e NHRP para mapeamentos IPv6. Overlays dual-stack podem executar IPv4 e IPv6 simultaneamente na mesma interface mGRE.
• Integração com IPsec: Proteja o mGRE com um único perfil IPsec usando tunnel protection. Prefira o modo de transporte (transport mode) para GRE sobre IPsec.
• MTU e fragmentação: Aplique valores conservadores de ip mtu e ip tcp adjust-mss e considere usar crypto ipsec fragmentation after-encryption para maximizar o TCP MSS negociado e evitar falhas de PMTUD.

Excertos típicos da 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

Travessia de NAT (NAT traversal): Garanta que o NAT-T esteja habilitado e que o hub esteja acessível nas portas UDP/500 e UDP/4500. Túneis dinâmicos spoke-to-spoke exigem que o underlay permita tráfego direto UDP/4500 e ESP/UDP entre os spokes se não houver relays NAT-T no caminho.

Operações e solução de problemas:

• Use show dmvpn, show ip nhrp e show crypto ipsec sa para verificar os registros NHRP e as SAs do IPsec.
• Para o roteamento, confirme que os anúncios do hub não ocultam as especificidades dos spokes na Fase 2 e que os redirecionamentos/atalhos (redirects/shortcuts) do NHRP estão ocorrendo na Fase 3.
• O mGRE não suporta keepalives GRE; dependa dos temporizadores do NHRP/IGP ou do BFD para detecção de falhas.

IPv6, Segurança Dual-Stack e Conectividade Remota Resiliente

Túneis IPv6 sobre IPv4:

• O GRE sobre um underlay IPv4 transporta payloads IPv6 de forma transparente; proteja com IPsec como descrito acima.
• O 6in4 (tunnel mode ipv6ip) é uma opção ponto a ponto simples, mas não possui a escalabilidade do DMVPN/mGRE.
• Overlays dual-stack executam tanto IPv4 quanto IPv6 no mesmo GRE/mGRE, protegidos por um único conjunto de associações IPsec, ou por SAs separadas se exigido pela política.

Notas de segurança do IPv6:

• O RA Guard filtra anúncios de roteador IPv6 maliciosos (rogue) em segmentos L2, mas não consegue inspecionar dentro dos túneis; ele não protege quando o tráfego IPv6 é tunelado. Aplique a segurança nos endpoints do túnel e no plano de roteamento do overlay.

Diagnóstico de acesso remoto e design resiliente:

• Instrumentação:

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

,

! 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

,

undefined

e logs de contabilidade por cliente. Capture em UDP/500/4500 e ESP/UDP para observar o comportamento do NAT-T. Verifique se as rotas de split-tunnel estão instaladas no cliente.

• Otimização de MTU: Os clientes atravessam redes de acesso arbitrárias; habilite o TCP MSS clamping nos headends e considere um MSS de 1200–1360 para um desempenho estável. A perda de pacotes combinada com o blackholing do PMTUD é uma causa comum de má experiência do usuário (UX).
• Alta disponibilidade: Use múltiplas origens de túnel (multi-WAN) com object tracking e probes de SLA para fazer o failover do default do underlay. Para overlays IGP, considere o BFD para reduzir os temporizadores de detecção de falha no túnel. Mantenha temporizadores de rekey de IKE/child SA curtos e alinhados com o clustering do headend para minimizar a perda de estado de criptografia durante o failover.
• Política de acesso e seletores: Prefira o acesso remoto baseado em rota (dVTI) para que todo o tráfego do cliente (ou apenas os prefixos do split) seja roteado para a interface virtual; isso evita incompatibilidades frágeis de seletores baseados em política.
• Alcançabilidade do endpoint: Sempre verifique o roteamento do underlay para os endereços públicos do headend a partir das redes do cliente. Se estiver direcionando o tráfego dentro da WAN, o roteamento baseado em política (PBR) com

undefined

pode direcionar fluxos que, de outra forma, não seriam roteados para a saída correta quando as buscas na RIB falharem.

Cenário de Problema Prático

A Contoso Retail opera 150 filiais conectadas por banda larga. Eles precisam de conectividade hub-and-spoke segura com comunicação dinâmica spoke-to-spoke para replicação de Ponto de Venda (Point-of-Sale), suporte a dual-stack e resiliência a problemas de MTU/NAT.

Abordagem:

1. Construir um overlay DMVPN Fase 3 com mGRE no hub e nos spokes, protegido por IPsec em modo de transporte.

• Justificativa: O mGRE escala para muitos spokes sem a necessidade de configuração por túnel no hub. A Fase 3 permite comunicação spoke-to-spoke sob demanda via NHRP shortcut/redirect, otimizando os fluxos de replicação e economizando a largura de banda do hub. O modo de transporte minimiza o overhead do GRE sobre IPsec.

2. Padronizar o IKEv2 com criptografia moderna e NAT-T.

• Justificativa: O IKEv2 simplifica as negociações, suporta múltiplos child SAs e possui um tratamento de erros mais limpo, ideal para implantações de grande porte. O NAT-T (UDP/4500) acomoda o NAT das filiais. Use AES-GCM com grupo DH 19 ou 20 e PFS para desempenho e segurança.

3. Projetar o MTU de ponta a ponta e habilitar a fragmentação após a criptografia.

• Justificativa: Provedores de banda larga frequentemente bloqueiam ICMP, o que quebra o PMTUD. Configurar

undefined

e

undefined

nas interfaces de Túnel, além de

undefined

, previne o blackholing e maximiza o TCP MSS efetivo.

4. Habilitar recursos do NHRP para resolução dinâmica e spokes com NAT.

• Justificativa:

undefined

no hub e

undefined

nos spokes criam os atalhos da Fase 3.

undefined

permite que spokes com endereços NBMA dinâmicos/com NAT se registrem com sucesso.

5. Executar OSPF sobre o overlay com o hub como DR e BFD para detecção rápida de falhas.

• Justificativa: O mGRE tem como padrão o modo broadcast; definir a prioridade OSPF do hub > 1 e a dos spokes como 0 garante uma eleição de DR/BDR estável e menos adjacências. O BFD (UDP/3784) com temporizadores agressivos proporciona convergência em menos de um segundo em caso de falhas no túnel.

6. Adicionar IPv6 junto com IPv4 na mesma interface DMVPN.

• Justificativa:

undefined

habilita a adjacência IPv6 sobre o mGRE. O roteamento dual-stack evita infraestruturas paralelas. O RA Guard é ineficaz dentro do túnel, portanto, aplique a segurança IPv6 por meio de ACLs de overlay e política de roteamento.

7. Reforçar a troca de chaves e as operações.

• Justificativa: Use chaves pré-compartilhadas inicialmente (

undefined

para fallback legado de IKEv1, ou keyrings/profiles de IKEv2) e migre para certificados. Defina tempos de vida (lifetimes) apropriados e DPD para limpar SAs obsoletas. Instrumente com

undefined

,

undefined

,

undefined

,

undefined

e syslog.

8. Garantir a alcançabilidade do underlay e direcionar o failover com roteamento/PBR onde necessário.

• Justificativa: Rotas estáticas ou roteamento dinâmico de underlay devem manter as origens do túnel alcançáveis durante mudanças na WAN. Onde o direcionamento provisório for necessário, o PBR com

undefined

pode direcionar o tráfego para a saída preferencial se as buscas na RIB falharem.

Este design resulta em uma conectividade dual-stack escalável e criptografada, com caminhos spoke-to-spoke otimizados, comportamento de MTU previsível, travessia de NAT robusta e recuperação rápida de falhas.

← Qualidade de Serviço e Proteção do Plano de Controle · Todos os domínios · Serviços de Rede →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →