Il problema: cifrare il traffico tra sedi

Collegare in sicurezza decine o centinaia di sedi richiede di scegliere non solo come cifrare (IPsec resta il denominatore comune) ma soprattutto quale modello di trasporto adottare. Cisco offre quattro approcci sul piano IOS/IOS-XE: sVTI, DMVPN, FlexVPN e GETVPN. La differenza chiave sta nel fatto che i primi tre costruiscono un overlay (un tunnel con nuovo header IP esterno), mentre GETVPN è tunnel-less.

sVTI: il tunnel statico punto-punto

Lo static Virtual Tunnel Interface (sVTI) è la forma più semplice: un’interfaccia Tunnel logica che incapsula IPsec verso un singolo peer. Il routing dinamico (OSPF, EIGRP, BGP) gira nativamente sull’interfaccia, senza crypto map ACL. È pulito e robusto, ma non scala: ogni coppia di sedi richiede un tunnel configurato manualmente. Per una full-mesh servirebbero n·(n-1)/2 tunnel. Ideale per pochi collegamenti fissi (es. sede centrale ↔ datacenter DR).

DMVPN: mGRE + NHRP per lo spoke-to-spoke dinamico

Il DMVPN risolve la scalabilità combinando tre tecnologie:

  • mGRE (multipoint GRE): una sola interfaccia tunnel sull’hub parla con tutti gli spoke.
  • NHRP (Next Hop Resolution Protocol): mappa dinamicamente l’indirizzo overlay dello spoke al suo indirizzo pubblico NBMA. Gli spoke si registrano presso l’hub (NHS).
  • IPsec come profilo di protezione del tunnel.

Le phase definiscono il comportamento:

Phase Spoke-to-spoke Routing hub Note
1 No, tutto via hub next-hop = hub Solo hub-and-spoke
2 Sì, diretto serve no ip next-hop-self e no split-horizon Niente summarization all’hub
3 Sì, via NHRP redirect/shortcut summarization consentita Più scalabile, preferita

In Phase 2 l’hub deve preservare il next-hop originale, quindi non può sommarizzare le rotte. La Phase 3 introduce l’NHRP redirect sull’hub e lo shortcut sullo spoke: l’hub può annunciare una default/summary e lo spoke costruisce comunque il tunnel diretto on-demand. È il modello preferito per hub-and-spoke scalabile su Internet.

FlexVPN: il framework unificato IKEv2

Il FlexVPN non è una tecnologia a sé ma un framework unico basato interamente su IKEv2 che copre site-to-site, hub-and-spoke, remote access e spoke-to-spoke, sostituendo la frammentazione di crypto map, EzVPN e DMVPN con IKEv1. Usa virtual-template e virtual-access interface create dinamicamente, con configurazione centralizzabile via IKEv2 (attributi push al peer). Vantaggi: un solo set di comandi coerente, IKEv2 nativo (più robusto e resiliente di IKEv1), routing e QoS per-tunnel. Si sceglie quando si vuole standardizzare su IKEv2 e unificare topologie eterogenee.

GETVPN: cifratura di gruppo tunnel-less

Il GETVPN è concettualmente diverso: nessun overlay, nessun tunnel punto-punto. Usa GDOI (Group Domain of Interpretation) per distribuire una chiave di gruppo condivisa. Gli attori:

  • Key Server (KS): autentica i membri, genera e distribuisce le chiavi KEK (protegge il rekey) e TEK (cifra il traffico), gestisce i rekey periodici.
  • Group Member (GM): applica la policy IPsec di gruppo al traffico.

La caratteristica distintiva è la header preservation: GETVPN cifra il payload ma mantiene l’header IP sorgente/destinazione originale. Questo permette any-to-any istantaneo (nessuna negoziazione di tunnel tra coppie) e soprattutto la replica multicast nella rete di transito. È la scelta ideale per una WAN privata MPLS dove l’operatore instrada già gli indirizzi interni e serve multicast efficiente.

Guida alla scelta per scenario

  • Molte sedi su Internet, spoke-to-spoke dinamico → DMVPN Phase 3 o FlexVPN.
  • Standardizzazione su IKEv2, topologie miste → FlexVPN.
  • MPLS privato, any-to-any, multicast → GETVPN.
  • Pochi link fissi e stabili → sVTI.

Trappole tipiche d’esame

  • Scenario: “cifratura di gruppo su Internet pubblico” → sbagliato scegliere GETVPN. GETVPN preserva l’IP sorgente/destinazione originale (spesso privato/RFC1918): non è instradabile su Internet e non crea overlay. Su Internet servono DMVPN o FlexVPN.
  • Scenario: “serve summarization delle rotte sull’hub mantenendo spoke-to-spoke” → risposta DMVPN Phase 3 (NHRP redirect/shortcut). La Phase 2 impone next-hop preservato e vieta la summarization.
  • Scenario: “replica multicast efficiente su WAN MPLS gestita dal provider” → GETVPN, grazie alla header preservation che sfrutta il multicast del core.
  • Scenario: “unificare remote access e site-to-site su un solo framework IKEv2” → FlexVPN (non DMVPN classico, legato storicamente a IKEv1/crypto profile).
  • Scenario: “spoke-to-spoke non funziona in DMVPN Phase 2” → verificare no ip next-hop-self e no ip split-horizon (EIGRP) sull’hub: senza di essi lo spoke non impara il next-hop reale del peer e il tunnel diretto non si forma.