Cisco 300-410: VPN, Tunneling e Connettività Remota — Guida allo studio

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

Fa parte della Cisco CCNP Enterprise 300-410 ENARSI — Guida allo studio. Esercitati con risposte verificate nel centro esami Cisco, oppure fai test cronometrati su ExamRoll.io.

Panoramica

Le tecniche di VPN, tunneling e connettività remota consentono comunicazioni private e regolate da policy su reti condivise. I design dipendono dalle scelte di incapsulamento (GRE, IPsec, VTI), dallo scambio di chiavi (IKEv1/2), dalla risoluzione del control-plane (NHRP in DMVPN) e dalle realtà del trasporto (MTU, NAT, failover). Questa sezione spiega come combinare questi elementi costitutivi per produrre reti di overlay scalabili, sicure e resilienti sia per casi d’uso site-to-site che di accesso remoto.

Fondamenti di GRE e IPsec

Il Generic Routing Encapsulation (GRE) è un incapsulamento semplice e stateless che trasporta quasi ogni protocollo di Livello 3 su un underlay IP. Proprietà chiave:

• Comportamento e incapsulamento: GRE aggiunge un header IP esterno di 20 byte più un header GRE di 4 byte (24 byte totali). GRE non ha crittografia o autenticazione nativa.
• Routing: GRE fornisce un’interfaccia tunnel numerata che partecipa al routing e supporta adiacenze IGP sull’overlay.
• MTU, frammentazione, MSS: L’overhead aggiunto riduce l’MTU effettivo del payload. Senza mitigazione, il blackholing di PMTUD e la frammentazione IP possono degradare le performance. La best practice consiste nell’impostare un MTU più piccolo sull’interfaccia del tunnel e nel limitare (clamp) l’MSS TCP per evitare la frammentazione nell’overlay.

Esempio di GRE point-to-point con MTU e MSS sicuri:

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 fornisce riservatezza, integrità e anti-replay:

• Modalità: La modalità Transport protegge solo il payload; l’header IP originale viene mantenuto. La modalità Tunnel incapsula l’intero pacchetto IP con un nuovo header IP esterno. GRE over IPsec utilizza tipicamente la modalità Transport di IPsec per minimizzare l’overhead; le VTI route-based utilizzano la modalità Tunnel di IPsec.
• Selettori (proxy ID / selettori di traffico): Definiscono quali flussi a 5 tuple sono protetti. Le VPN policy-based usano ACL per definire i selettori; le VPN route-based usano selettori 0.0.0.0/0 (o ::/0) legati a un’interfaccia tunnel, con il routing che determina il traffico.
• Crittografia e integrità: AES-GCM fornisce crittografia autenticata in una singola trasformazione e riduce l’overhead per pacchetto rispetto ad AES-CBC + HMAC. Utilizzare gruppi DH moderni (14/19+) e PFS per la forward secrecy. Allineare le capability di transform/proposal su entrambi i peer.

Frammentazione e compromessi sul throughput:

• Pre-frammentazione (look-ahead fragmentation): funziona solo in modalità Tunnel. Può migliorare il throughput evitando il riassemblaggio sull’end host di decrittografia, al costo di frammenti IP aggiuntivi attraverso l’underlay.
• Frammentazione post-crittografia: è spesso usata con GRE over IPsec in modalità Transport e NAT-T; combinata con il clamping dell’MSS, riduce la possibilità di black hole di PMTUD.
• PMTUD vs MTU fisso: Se l’ICMP dell’underlay è filtrato, affidarsi a un MTU del tunnel conservativo e al clamping dell’MSS.

Applicare IPsec a GRE con protezione del tunnel:

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

Scambio di Chiavi, Attraversamento NAT e Stili di VPN

IKE negozia le SA per IPsec.

• IKEv1: Modalità Main e Aggressive per la Fase 1; modalità Quick per la Fase 2. Configurare le policy (“crypto isakmp policy”), l’autenticazione (PSK o certificati), il lifetime e i gruppi DH. Eseguire il troubleshooting con show crypto isakmp sa e debug per gli scambi MM/AM/QM e le mancate corrispondenze dei proxy ID.
• IKEv2: Modello a scambio singolo con proposal, policy e profili. Supporta SA figlie (child SA) multiple, EAP per l’accesso remoto e una migliore segnalazione degli errori. FlexVPN standardizza su IKEv2 e sul comportamento route-based tramite VTI. Eseguire il troubleshooting con show crypto ikev2 sa/session, show crypto ipsec sa e i relativi debug.

Attraversamento NAT e keepalive:

• NAT-T rileva la presenza di NAT lungo il percorso e incapsula ESP in UDP/4500. Assicurarsi che entrambi i peer abilitino NAT-T. I keepalive IKE e il Dead Peer Detection (DPD) rimuovono le SA obsolete; regolare i timer per soddisfare le esigenze dell’applicazione.
• La raggiungibilità della sorgente/destinazione del tunnel è fondamentale: l’underlay deve poter instradare verso gli endpoint del tunnel. Fornire rotte statiche o routing dinamico dell’underlay per garantire che gli IP esterni rimangano raggiungibili durante gli eventi di failover.
• I keepalive GRE funzionano per GRE point-to-point, ma non per mGRE. Per gli overlay, usare i timer IGP, i timer NHRP o BFD. I pacchetti di controllo BFD usano la porta UDP 3784 e possono rilevare rapidamente i guasti del percorso; integrare con gli IGP per una convergenza sub-secondo.

VPN policy-based vs route-based:

• Policy-based: Crypto map con selettori ACL per il “traffico di interesse”. Pro: semplice per piccole connessioni site-to-site statiche. Contro: complesso con molti prefissi, problemi di routing asimmetrico e scarso supporto per la comunicazione spoke-to-spoke.
• Route-based: Interfacce tunnel virtuali (VTI/dVTI/FlexVPN) con selettori di default (any/any); il routing determina i flussi protetti. Pro: è scalabile, supporta il routing dinamico e l’hairpinning/comunicazione spoke-to-spoke, configurazione crypto più semplice. Preferito per i design moderni.

Accesso remoto con IKEv2/FlexVPN:

• Usare profili IKEv2, autenticazione EAP e dVTI per assegnare policy per utente/per gruppo. Diagnosticare con show crypto ikev2 sa e i log AAA. Il clamping dell’MSS e lo split tunneling mitigano i problemi di MTU e di performance su reti client eterogenee.

Policy-based routing per i fallback:

• Quando si devono instradare flussi altrimenti non instradati in un tunnel o verso un’uscita specifica, usare il PBR con set ip default next-hop per specificare un next-hop di default quando la RIB non ha una rotta corrispondente, minimizzando la dipendenza da rotte di default statiche durante il failover.

Progettazione e Funzionamento di DMVPN

DMVPN combina mGRE, NHRP e IPsec per costruire topologie hub-and-spoke o spoke-to-spoke scalabili.

• mGRE: Un’unica interfaccia tunnel termina dinamicamente più peer; non è richiesto un tunnel per ogni spoke sull’hub. L’endpoint del tunnel è un singolo indirizzo NBMA “any-to-any”.
• NHRP: Risolve i next hop dell’overlay in indirizzi NBMA dell’underlay. Lo spoke si registra con il Next Hop Server (NHS) NHRP sull’hub. Le query NHRP abilitano la risoluzione spoke-to-spoke on-demand.
• Spoke e IP dinamici: Gli spoke dietro NAT o con indirizzi dinamici potrebbero richiedere ip nhrp registration no-unique per consentire la registrazione senza un NBMA globalmente univoco.
• Fasi:
  • Fase 1: Gli spoke utilizzano l’hub per tutto il traffico; nessuna comunicazione diretta spoke-to-spoke.
  • Fase 2: Gli spoke formano tunnel diretti dopo la risoluzione NHRP; il routing deve pubblicizzare i prefissi degli spoke senza sumarizzazione che possa oscurare i next hop.
  • Fase 3: Aggiunge il redirect/shortcut NHRP per riscrivere dinamicamente i next hop; consente la sumarizzazione sull’hub e l’inoltro ottimale spoke-to-spoke.
• OSPF su DMVPN: mGRE utilizza di default il tipo di rete OSPF broadcast; l’hub dovrebbe diventare il DR per stabilizzare le adiacenze — impostare la priorità OSPF > 1 sull’hub e 0 sugli spoke. In alternativa, usare il tipo point-to-multipoint per evitare DR/BDR ma accettare un overhead LSA maggiore.
• IPv6: Costruire adiacenze IPv6 su DMVPN usando tunnel mode gre multipoint ipv6 e NHRP per i mapping IPv6. Gli overlay dual-stack possono eseguire IPv4 e IPv6 simultaneamente sulla stessa interfaccia mGRE.
• Integrazione IPsec: Proteggere mGRE con un singolo profilo IPsec utilizzando tunnel protection. Preferire la modalità transport per GRE over IPsec.
• MTU e frammentazione: Applicare valori conservativi per ip mtu e ip tcp adjust-mss e considerare crypto ipsec fragmentation after-encryption per massimizzare il TCP MSS negoziato ed evitare fallimenti di PMTUD.

Estratti tipici della 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

Attraversamento NAT (NAT traversal): Assicurarsi che NAT-T sia abilitato e che l’hub sia raggiungibile su UDP/500 e UDP/4500. I tunnel dinamici spoke-to-spoke richiedono che l’underlay permetta il traffico diretto UDP/4500 e ESP/UDP tra gli spoke se non ci sono relay NAT-T nel percorso.

Operatività e troubleshooting:

• show dmvpn, show ip nhrp e show crypto ipsec sa per verificare le registrazioni NHRP e le SA IPsec.
• Per il routing, confermare che gli advertisement dell’hub non oscurino le specifiche degli spoke nella Fase 2 e che i redirect/shortcut NHRP si stiano verificando nella Fase 3.
• mGRE non supporta i keepalive GRE; affidarsi ai timer NHRP/IGP o a BFD per il rilevamento dei guasti.

IPv6, sicurezza Dual-Stack e connettività remota resiliente

Tunnel IPv6 su IPv4:

• L’underlay GRE su IPv4 trasporta i payload IPv6 in modo trasparente; si protegge con IPsec come descritto sopra.
• 6in4 (tunnel mode ipv6ip) è un’opzione point-to-point semplice, ma priva della scalabilità di DMVPN/mGRE.
• Gli overlay dual-stack eseguono sia IPv4 che IPv6 sullo stesso GRE/mGRE, protetti da un unico set di associazioni IPsec (SA), o da SA separate se richiesto dalla policy.

Note sulla sicurezza IPv6:

• RA Guard filtra i Router Advertisement IPv6 non autorizzati (rogue) sui segmenti L2 ma non può ispezionare all’interno dei tunnel; non fornisce protezione quando il traffico IPv6 è incapsulato in un tunnel. Applicare la sicurezza agli endpoint del tunnel e sul piano di routing dell’overlay.

Diagnostica dell’accesso remoto e progettazione resiliente:

• Strumentazione: show crypto ikev2 sa/session, show crypto ipsec sa, show crypto session e log di accounting per client. Effettuare catture su UDP/500/4500 e ESP/UDP per osservare il comportamento di NAT-T. Verificare che le route di split-tunnel siano installate sul client.
• Ottimizzazione della MTU: I client attraversano reti di accesso arbitrarie; abilitare il TCP MSS clamping sugli headend e considerare un MSS di 1200–1360 per prestazioni stabili. La perdita di pacchetti combinata con il blackholing di PMTUD è una causa comune di scarsa esperienza utente (UX).
• Alta disponibilità: Utilizzare sorgenti di tunnel multiple (multi-WAN) con object tracking e probe SLA per il failover del default dell’underlay. Per gli overlay IGP, considerare BFD per ridurre i timer di rilevamento dei guasti sul tunnel. Mantenere timer di rekey brevi per IKE/child SA, allineati con il clustering degli headend per minimizzare la perdita di stato della crittografia durante il failover.
• Policy di accesso e selettori: Preferire l’accesso remoto basato su route (dVTI) in modo che tutto il traffico del client (o solo i prefissi dello split-tunnel) sia instradato nell’interfaccia virtuale; questo evita fragili discrepanze nei selettori basati su policy.
• Raggiungibilità degli endpoint: Verificare sempre il routing dell’underlay verso gli indirizzi pubblici dell’headend dalle reti dei client. Se si dirige il traffico all’interno della WAN, il policy-based routing con set ip default next-hop può indirizzare i flussi altrimenti non instradati verso l’egress corretto quando le ricerche nella RIB falliscono.

Scenario pratico

Contoso Retail gestisce 150 filiali connesse tramite banda larga. Necessitano di connettività hub-and-spoke sicura con collegamenti dinamici spoke-to-spoke per la replica dei sistemi Point-of-Sale, supporto dual-stack e resilienza ai problemi di MTU/NAT.

Approccio:

1. Costruire un overlay DMVPN Phase 3 con mGRE sull’hub e sugli spoke, protetto da IPsec in modalità transport.

• Motivazione: mGRE scala a un gran numero di spoke senza richiedere configurazioni per singolo tunnel sull’hub. La Phase 3 permette connessioni on-demand spoke-to-spoke tramite NHRP shortcut/redirect, ottimizzando i flussi di replica e risparmiando banda sull’hub. La modalità transport minimizza l’overhead per GRE su IPsec.

2. Standardizzare su IKEv2 con crittografia moderna e NAT-T.

• Motivazione: IKEv2 semplifica le negoziazioni, supporta multiple child SA e una gestione degli errori più pulita, ideale per implementazioni su larga scala. NAT-T (UDP/4500) gestisce il NAT delle filiali. Utilizzare AES-GCM con DH group 19 o 20 e PFS per prestazioni e sicurezza.

3. Progettare la MTU end-to-end e abilitare la frammentazione dopo la cifratura.

• Motivazione: I provider di banda larga spesso bloccano ICMP, interrompendo il funzionamento di PMTUD. Impostare ip mtu 1400 e ip tcp adjust-mss 1360 sulle interfacce Tunnel, oltre a crypto ipsec fragmentation after-encryption, previene il blackholing e massimizza l’MSS effettivo del TCP.

4. Abilitare le funzionalità NHRP per la risoluzione dinamica e gli spoke dietro NAT.

• Motivazione: ip nhrp redirect sull’hub e ip nhrp shortcut sugli spoke creano gli shortcut della Phase 3. ip nhrp registration no-unique permette agli spoke con indirizzi NBMA dinamici/nattati di registrarsi con successo.

5. Eseguire OSPF sull’overlay con l’hub come DR e BFD per il rilevamento rapido dei guasti.

• Motivazione: mGRE ha come default la modalità broadcast; impostare la priorità OSPF dell’hub > 1 e quella degli spoke a 0 assicura un’elezione stabile di DR/BDR e un minor numero di adiacenze. BFD (UDP/3784) con timer aggressivi fornisce una convergenza sub-secondo in caso di guasti del tunnel.

6. Aggiungere IPv6 accanto a IPv4 sulla stessa interfaccia DMVPN.

• Motivazione: tunnel mode gre multipoint ipv6 abilita l’adiacenza IPv6 su mGRE. Il routing dual-stack evita di dover creare infrastrutture parallele. RA Guard è inefficace all’interno del tunnel, quindi la sicurezza IPv6 deve essere applicata tramite ACL sull’overlay e policy di routing.

7. Rafforzare lo scambio di chiavi e le operazioni.

• Motivazione: Inizialmente, utilizzare chiavi pre-condivise (preshared keys) (con crypto isakmp key Test address 0.0.0.0 0.0.0.0 per il fallback a IKEv1 legacy, oppure keyring/profili IKEv2) e migrare poi ai certificati. Impostare lifetime appropriati e DPD per eliminare le SA obsolete. Strumentare con show dmvpn, show ip nhrp, show crypto ikev2 sa, show crypto ipsec sa e syslog.

8. Garantire la raggiungibilità dell’underlay e pilotare il failover con routing/PBR dove necessario.

• Motivazione: Le route statiche o il routing dinamico dell’underlay devono mantenere le sorgenti dei tunnel raggiungibili durante i cambiamenti della WAN. Dove è necessario un indirizzamento del traffico transitorio, il PBR con set ip default next-hop può dirigere il traffico verso l’egress preferito se le ricerche nella RIB falliscono.

Questo design produce una connettività dual-stack scalabile e crittografata, con percorsi spoke-to-spoke ottimali, un comportamento prevedibile della MTU, un attraversamento del NAT robusto e un rapido ripristino dai guasti.

← Qualità del Servizio e Protezione del Control-Plane · Tutti i domini · Servizi di Rete →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →