La scelta di come collegare la rete on-premises (o un data center Cisco) al cloud è la prima decisione di design in un progetto ENCC. Le due famiglie di opzioni — IPsec VPN sull’Internet pubblico e interconnessione privata dedicata (Azure ExpressRoute, AWS Direct Connect, Google Cloud Interconnect) — rispondono a requisiti diversi di costo, banda, latenza e SLA. Capire il trade-off, e non solo la meccanica, è ciò che l’esame verifica.
IPsec VPN sull’Internet pubblico
Un tunnel site-to-site IPsec costruisce un canale cifrato (ESP, tipicamente in tunnel mode) sopra la connettività Internet esistente. Su Cisco IOS/IOS-XE si realizza con IKEv2 + route-based VPN tramite tunnel protection ipsec profile, spesso su una Virtual Tunnel Interface (VTI), che semplifica il routing rispetto alle vecchie crypto map perché il traffico è instradato dalla routing table verso la tunnel interface.
I punti di forza sono economicità e rapidità di attivazione: nessun circuito da ordinare, si sfrutta la banda Internet già presente. I limiti derivano proprio dal transito su Internet:
- Banda vincolata al link Internet e al throughput di crypto dell’edge device.
- Latenza e jitter non deterministici, soggetti al best-effort dell’Internet pubblico.
- SLA end-to-end assente: il provider cloud garantisce solo il proprio gateway VPN, non il percorso Internet.
La cifratura, però, è nativa e sempre presente: è il punto chiave del confronto.
Interconnessione privata dedicata
Le interconnessioni private bypassano l’Internet pubblico fornendo un percorso Layer 2/Layer 3 dedicato verso il cloud provider, spesso attestato presso una colocation/meet-me room o via un partner (NSP). Esempi: ExpressRoute (Azure), Direct Connect (AWS), Cloud Interconnect (Google, nelle varianti Dedicated e Partner).
Caratteristiche tipiche:
- Banda elevata e garantita (da centinaia di Mbps fino a 10/100 Gbps), con circuiti dimensionati e riservati.
- Latenza bassa e prevedibile grazie al percorso privato.
- SLA contrattuale sul circuito (availability), assente sulle VPN Internet.
- Peering BGP verso il cloud per scambiare le route; su IOS-XE si configura una eBGP session verso il gateway del provider.
Lo svantaggio è il costo (canone del circuito + port + eventuale partner) e i tempi di provisioning, misurabili in settimane.
Confronto sintetico
| Criterio | IPsec VPN (Internet) | Interconnect privato |
|---|---|---|
| Costo | Basso | Alto (canone + port) |
| Banda | Limitata dal link Internet | Dedicata, fino a 10/100 Gbps |
| Latenza/jitter | Variabile, best-effort | Bassa e deterministica |
| SLA percorso | Nessuno | Contrattuale |
| Cifratura | Nativa (ESP) | Assente di default |
| Time-to-deploy | Minuti/ore | Giorni/settimane |
Quando basta la VPN e quando serve il circuito
La VPN IPsec è sufficiente per workload tolleranti alla latenza, traffico modesto, ambienti di sviluppo/test, filiali, o come soluzione tattica in attesa del circuito. L’interconnect privato diventa necessario con volumi elevati e costanti (replica dati, backup, storage), applicazioni sensibili alla latenza, esigenze di SLA formalizzato o requisiti di compliance che vietano il transito su Internet.
Coesistenza per la resilienza
I due modelli non si escludono: il pattern di design più diffuso usa l’interconnect privato come percorso primario e una IPsec VPN come backup su Internet. Il failover si governa con BGP, manipolando local preference, AS-path prepend o MED in modo che il traffico preferisca il circuito dedicato e ricada sul tunnel solo se il peering primario cade. Alcuni provider offrono anche l’incapsulamento IPsec sopra il circuito privato per aggiungere cifratura mantenendo il percorso dedicato.
Trappole tipiche d’esame
- Scenario: “il traffico su ExpressRoute/Direct Connect è cifrato perché è privato” → FALSO. Il circuito dedicato è privato ma non cifra i dati di default. Serve MACsec (Layer 2, dove supportato sulla porta) o un IPsec/VTI esplicito sopra il circuito per garantire confidenzialità.
- Scenario: requisito di SLA di disponibilità garantito → interconnect privato, non VPN Internet: la VPN best-effort non offre SLA sul percorso end-to-end.
- Scenario: attivazione rapida a basso costo per un ambiente di test → IPsec VPN site-to-site, non un circuito dedicato che richiede settimane e canone.
- Scenario: primario dedicato + backup VPN, come far preferire il circuito? → BGP (local preference in ingresso/uscita, AS-path prepend), non metriche statiche o floating route generiche.
- Scenario: throughput della VPN inferiore all’atteso → limite di crypto dell’edge device o del link Internet, non del gateway cloud; verificare capacità hardware e MTU/MSS (frammentazione IPsec).