Interconnessione sicura di reti Cloud-VPC: VPN vs Direct Connect/ExpressRoute e migliori pratiche

Chi deve interconnettere in modo sicuro reti Cloud-VPC si trova rapidamente in un conflitto di obiettivi: il più stabile e performante possibile, ma al contempo tracciabile, segmentato e affidabile in esercizio. Nella pratica raramente si tratta solo di «una connessione verso la cloud». Si tratta di un accoppiamento di rete tra domini di sicurezza (p. es. data center on-premises, Cloud-VPC/VNET, reti partner), che deve funzionare nella quotidianità: Deployments, Backups, Monitoring, Identity/Directory, processi di aggiornamento e patch, flussi di dati per software di business e soluzioni software prossime ai processi.

Questo articolo confronta Site-to-Site-VPN (IPsec) con collegamenti dedicati come AWS Direct Connect e Azure ExpressRoute. Il focus non è sulle promesse di marketing, ma sull’esercizio: prerequisiti, rischi, insidie tipiche, passi di verifica, troubleshooting e una strategia di fallback. Termini come VPC (Virtual Private Cloud, rete cloud logicamente isolata) e VNET (Azure Virtual Network, equivalente Azure alla VPC) vengono contestualizzati allo stesso modo.

Interconnettere in modo sicuro le reti Cloud-VPC nella pratica

Prima di confrontare VPN o Direct Connect/ExpressRoute, vale la pena un breve reality check. Molte decisioni errate nascono perché i requisiti sono formulati solo come «abbiamo bisogno di accesso». Meglio criteri verificabili:

• Disponibilità e rischio: Quanto critica è la connessione? Cosa succede con 15 minuti di interruzione? E con 2 ore? Quali obiettivi RTO/RPO (obiettivi di ripristino/perdita dati) sono collegati?
• Profilo del traffico: Molti piccoli flussi (API, Auth, Admin) vs. grandi trasferimenti (Backup, Replikation, Batch). Importante, perché VPN e circuiti dedicati reagiscono diversamente in termini di throughput, jitter e MTU.
• Sensibilità alla latenza: flussi di directory e Auth (p. es. LDAP/Kerberos), accessi a database o servizi terminali sono molto più sensibili rispetto a integrazioni asincrone.
• Modello di sicurezza: trust basato sulla rete (classico) vs. Zero-Trust (accesso basato su identità/policy). Anche se lo Zero-Trust spesso opera a livello applicativo/identity, influisce su segmentazione, logging e sul «blast radius» nella rete.
• Complessità del routing: una subnet nella cloud o molte reti, più sedi, partner, più cloud? Qui si decide se potete ancora lavorare ordinatamente con rotte statiche o se serve BGP.
• Frequenza di cambiamento: Quanto spesso cambiano reti, workload, regioni? Cambiamenti frequenti suggeriscono pattern chiaramente standardizzati (p. es. hub-and-spoke, transit centrale) e una solida automazione.

Se questi punti sono definiti, la scelta tecnologica è decisamente più semplice – ed eviterete il classico: una «soluzione VPN veloce» che poi, per routing, segmentazione e operatività, entra in difficoltà.

VPN vs Direct Connect/ExpressRoute: principi di base e caratteristiche tipiche

Site-to-Site VPN significa di regola IPsec (Internet Protocol Security, cifratura e autenticazione a livello di rete) su Internet pubblico. La connessione viene in genere stabilita in due fasi: IKE (Internet Key Exchange, negoziazione delle Security Associations) e successivamente il canale dati ESP vero e proprio (Encapsulating Security Payload). Opzionalmente si utilizza NAT-T (NAT Traversal) quando è presente NAT nel percorso e quindi IPsec deve essere incapsulato in UDP.

Direct Connect (AWS) e ExpressRoute (Azure) sono collegamenti dedicati e privati tramite Provider/Carrier. Utilizzano anch’essi routing (spesso BGP, Border Gateway Protocol – instradamento dinamico tra sistemi autonomi), ma non transitano attraverso l’Internet pubblico. Importante: «privato» non equivale automaticamente a «crittografato». Molti design prevedono comunque una crittografia aggiuntiva per dati sensibili (p.es. IPsec sulla linea privata o TLS a livello applicativo).

Cosa, nella pratica, parla a favore di un Site-to-Site VPN?

• Disponibilità rapida: Spesso realizzabile in ore o giorni, senza provisioning da parte del provider.
• Bassa soglia d’ingresso: Adatto per i primi scenari ibridi, progetti pilota, migrazioni temporanee.
• Flessibile per più sedi: Particolarmente se avete già Internet-Uplinks e un Edge-Gateway in esercizio.

Limiti tipici: latenza/jitter variabili, dipendenza dalla qualità di Internet, trappole MTU e limiti di prestazioni sui VPN-Gateways. Inoltre l’operatività può diventare complessa se crescono numerose reti e eccezioni di policy.

Cosa, nella pratica, parla a favore di Direct Connect/ExpressRoute?

• Latenza più stabile e spesso throughput più prevedibile, perché il percorso non è „Internet-best-effort“.
• Scalabilità per numerose reti/sedi, soprattutto se si utilizza BGP in modo corretto.
• Integrazione operativa: i provider forniscono spesso SLA più chiari e stati di linea più facilmente misurabili.

Limiti tipici: tempi di avvio (Bereitstellung, Cross-Connects), costi e maggiori dipendenze (Provider, Meet-Me-Room, capacità delle porte). Inoltre la decisione architetturale è più critica: un hub costruito male può rapidamente diventare un Single Point of Failure.

Pattern architetturali: Hub-and-Spoke, Transit e segmentazione

Indipendentemente dal trasporto (VPN o linea dedicata), è l‘architettura di rete a determinare se lavorerete in modo sicuro e operativo nel lungo periodo. Tre pattern sono frequentemente impiegati nell’ambiente enterprise:

1) Punto a punto (diretto) – solo per ambiti ridotti

Una sede si collega direttamente a una VPC/VNET. È veloce, ma scala male: ogni nuova VPC/VNET e ogni nuovo subnet aumentano il numero di tunnel, rotte e regole del firewall. Il rischio di asimmetria (andata e ritorno differenti) cresce.

2) Hub-and-Spoke – controllo centrale

Si costruisce un Hub (es. VPC/VNET di rete centrale) e si collegano Spokes (Workload-VPCs/VNETs). Nell’Hub risiedono servizi centrali: firewalling, NAT, DNS-Resolver, proxy, logging, eventualmente Bastion/Jump. Questo supporta la segmentazione (separazione delle zone) e facilita gli audit, perché i „punti di controllo“ sono più chiari.

3) Transit/Virtual WAN – il routing come piattaforma

In AWS ist das oft ein Transit Gateway (zentraler Router/Transit für viele VPCs und On-Prem-Verbindungen). In Azure ist ein häufiges Pendant Virtual WAN (WAN-Orchestrierung, zentrale Konnektivität über Hubs). Vorteil: dynamisches Routing, standardisierte Anbindungen, bessere Skalierung. Nachteil: Sie müssen Routing- und Security-Policies sehr bewusst gestalten, damit nicht plötzlich „alles mit allem“ sprechen kann.

Best Practice für sichere Designs: Segmentierung vor Konnektivität. Legen Sie Zonen fest (z. B. Management, Shared Services, Produktiv, Partner, Dev/Test) und entscheiden Sie, welche Flows erlaubt sind. Danach bauen Sie die Wege (VPN/Direct Connect/ExpressRoute) so, dass die Segmentierung technisch durchgesetzt wird (Security Groups/NSGs, Firewall-Policies, Route Tables).

Routing sauber machen: BGP, statische Routen und Route Propagation

Viele Störungen wirken wie „VPN kaputt“, sind aber in Wirklichkeit Routing- oder Policy-Themen. Zwei Begriffe sollten in jedem Runbook stehen:

• Statische Routen: fest konfigurierte Next-Hops. Einfach, aber fehleranfällig bei Änderungen und bei Redundanz (Failover muss aktiv geplant werden).
• BGP: dynamisches Routing, bei dem Prefixe (Netze) ausgetauscht werden. BGP kann Failover und Wachstum deutlich besser abbilden, erfordert aber Disziplin (Prefix-Listen, Filter, Metriken/Local Preference, Community-Strategien).

In Cloud-Setups kommt ein dritter Faktor hinzu: Route Propagation (Routen-Weitergabe). Je nach Plattform können Routen automatisch in Route Tables übernommen werden oder nicht. Typische Stolperfalle: Der Tunnel steht, BGP ist „up“, aber das Subnetz hat keine Route zum Ziel, weil die Route Table nicht propagiert oder nicht assoziiert ist.

Typische Routing-Fallen (und warum sie passieren)

• Überlappende IP-Adressräume: Wenn On-Prem und Cloud die gleichen RFC1918-Netze nutzen (z. B. 10.0.0.0/8 unkoordiniert), wird Routing unzuverlässig. Das ist kein „Cloud-Problem“, sondern ein Adressmanagement-Thema. Lösung: IP-Plan bereinigen, notfalls NAT-Strategie mit klaren Logging-Regeln.
• Asymmetrisches Routing: Hinweg über VPN, Rückweg über Internet/NAT oder über eine andere Leitung. Viele Firewalls/VPN-Gateways sind stateful und verwerfen Rückpakete, wenn der Flow nicht über denselben Pfad zurückkommt.
• Default-Route in den Tunnel ohne Planung: Ein „0.0.0.0/0 ins VPN“ kann centrale Internet-Breakouts und Cloud-Egress komplett verändern. Das führt zu Ausfällen, nicht nur zu „mehr Sicherheit“.
• Zu große Prefixe oder zu viele Routen: Plattformlimits (max. Routen in Route Tables, max. Prefixe pro BGP-Session) werden oft spät bemerkt. Ergebnis: Teilrouting, „manche Netze gehen, manche nicht“.

Security Best Practices: Verschlüsselung, Policy, Logging und Schlüsselbetrieb

„Sicher vernetzen“ heißt im Betrieb: Vertraulichkeit, Integrität, Nachvollziehbarkeit und kontrollierte Ausbreitung. Für VPN und dedizierte Leitungen ergeben sich ähnliche Handlungsfelder:

Verschlüsselung: Was ist Pflicht, was ist sinnvoll?

Con IPsec VPN la cifratura è parte integrante. È importante scegliere parametri adatti al proprio ambiente (p. es. IKEv2 invece di IKEv1, suite di cifratura robuste) e garantire la compatibilità con i gateway cloud. Per Direct Connect/ExpressRoute vale: il trasporto è privato, ma non è automaticamente cifrato end-to-end. Per molte aziende è quindi consueto adottare inoltre TLS (Transport Layer Security, cifratura a livello applicativo) o perfino IPsec over private link – in particolare per i protocolli amministrativi e i flussi di dati sensibili.

Policy: „Least Privilege“ implementare nella rete

Least-Privilege in rete significa: solo le porte/protocolli effettivamente necessari, solo tra le sottoreti/workload richiesti. Nel cloud intervengono più livelli: Security Groups/NSGs (vicini al workload), firewall centrali (p. es. nell’hub) e routing (ciò che è effettivamente raggiungibile). Una prassi consolidata:

• Prima definire i flussi come matrice di comunicazione (origine, destinazione, porta, scopo, responsabile).
• Poi forzare la segmentazione tramite sottoreti e tabelle di routing.
• Solo dopo implementare regole in Security Groups/NSGs e firewall.

In questo modo si evita la „firewall come cerotto“, in cui alla fine si accumulano troppe eccezioni.

Logging e tracciabilità: senza dati nessuna operatività

Pianificate fin dall’inizio dove vedere stati di connessione e flow-logs: stato VPN (IKE/ESP), stato BGP, drop sui firewall, flow-logs in VPC/VNET e collegamento centrale a Syslog/SIEM. Tipicamente utili sono ID correlabili (Tunnel-ID, Peer-IP, BGP-Neighbor, Subnet/ENI/NIC) e la sincronizzazione temporale (NTP), in modo che gli eventi combacino tra i diversi sistemi.

Prassi: configurare correttamente il funzionamento VPN (Checkliste)

Per la categoria VPN conta soprattutto: stabilità sotto disturbi, sequenze di verifica chiare e ridondanza pulita. La seguente checklist è volutamente orientata all’operatività.

Preparazione

• Validare il piano IP: nessuna sovrapposizione; se inevitabile, progettazione NAT inclusi monitoraggio e documentazione.
• Strategia MTU: IPsec riduce l’MTU effettiva (overhead). Pianificate MSS-clamping o una MTU del tunnel adeguata (a seconda della piattaforma). Senza questo potreste riscontrare problemi „strani“ con alcuni protocolli.
• Ridondanza: almeno due tunnel (o due provider/edge). Definite cosa significano „Active/Active“ vs. „Active/Standby“ e come viene misurato il failover.
• IKEv2 e profili crittografici: scegliete parametri moderni e compatibili. Verificate i tempi di vita (rekey) e il DPD (Dead Peer Detection, raggiungibilità del peer).
• Stabilire il routing: statico (per reti piccole) o BGP (per crescita). Se BGP: definire filtri di prefisso e protezione max-prefix.

Esecuzione: passi minimi per la messa in servizio

Se il tunnel è „attivo“, questo è solo l’inizio. Verifichi nell’ordine seguente:

1. IKE/ESP-Status: Esiste una Security Association attiva? Ci sono errori di rekey?
2. Routen: La rete di destinazione è raggiungibile e la route punta effettivamente al tunnel/transit?
3. Security/Firewall: I flow sono permessi o droppati?
4. Path MTU: Pacchetti di dimensione maggiore funzionano? In caso contrario, si rileva frammentazione/scarti.
5. DNS: Spesso un „la rete non funziona“ è in realtà un problema DNS/Split-DNS.

Quick-Checks vom Linux-Host (Cloud oder On-Prem)

I comandi seguenti aiutano a classificare i sintomi. Non sostituiscono il debug al gateway, ma sono rapidamente disponibili durante un incidente.

# Verificare il routing verso la destinazione
ip route get 10.20.30.40

# Testare il Path MTU (Don't Fragment). Aumentare progressivamente il payload.
# Attenzione: a seconda dell'ambiente ICMP può essere filtrato; in tal caso il risultato è limitato.
ping -M do -s 1372 -c 3 10.20.30.40
ping -M do -s 1400 -c 3 10.20.30.40

# Traceroute con TCP (se ICMP è bloccato) verso una porta di destinazione
traceroute -T -p 443 10.20.30.40

# Cattura pacchetti (adattare l'interfaccia) per vedere SYN/SYN-ACK o ICMP "fragmentation needed"
sudo tcpdump -ni any host 10.20.30.40

Perché questo aiuta: se ip route get non punta al Next-Hop previsto, non cercare nel VPN. Se ping -M do fallisce oltre una certa dimensione, MTU/MSS è un candidato realistico. E tcpdump mostra rapidamente se i pacchetti lasciano il sistema, se le risposte tornano o se compaiono messaggi di errore ICMP.

Risoluzione dei problemi: Quadri di errore comuni e contromisure mirate

In esercizio è molto utile saper riconoscere i quadri d’errore. Qui i modelli tipici nella connettività ibrida.

Quadro 1: il tunnel è „UP“, ma nessun traffico passa

• Cause: mancata associazione alla route table, propagazione delle rotte disattivata, Security Group/NSG che bloccano, firewall on-prem che blocca il percorso di ritorno, selector/traffic-selectors errati (per VPN basate su policy), asimmetria.
• Verifiche: rotta verso la destinazione (cloud e on-prem), porte consentite, registri dei flussi/scarti, percorso di ritorno (reverse path).
• Rimedi: correggere le rotte, attivare la propagazione (o impostare staticamente in modo consapevole), definire la policy in modo più restrittivo, verificare le regole della firewall stateful.

Quadro 2: «Alcune applicazioni funzionano, altre si bloccano»

• Cause: problemi MTU/MSS, PMTUD (Path MTU Discovery) fallisce, frammentazione scartata, protocolli a prevalenza UDP sensibili allo jitter.
• Verifiche: test PMTU, tcpdump per ICMP „fragmentation needed“, confronto tra payload piccoli e grandi.
• Rimedi: MSS-clamping su edge/firewall, adattare la MTU del tunnel, gestire l’ICMP correttamente (non bloccarlo ciecamente).

Quadro 3: Cadute di connessione ogni X minuti

• Cause: Rekey-Parameter incompatibili, DPD/Keepalive troppo aggressivo, NAT-Timeout presso il provider, picchi di carico sul gateway.
• Verificare: log del gateway (IKE-Rekey), timeout di sessione, CPU/throughput sul dispositivo VPN, perdite di pacchetti.
• Risoluzione: armonizzare gli intervalli di Rekey, stabilizzare NAT-T, distribuire il carico (più tunnel/più gateway), eventualmente valutare una linea dedicata.

Quadro di errore 4: BGP è up, ma mancano rotte o subiscono flapping

• Cause: filtri sui prefissi troppo restrittivi o troppo permissivi, scatenato il limite Max-Prefix, connessione underlay instabile, timer errati, preferenze poco chiare su percorsi multipli.
• Verificare: rotte annunciate/ricevute, log relativi a Max-Prefix, stabilità della connessione underlay, coerenza di communities/LocalPref.
• Risoluzione: correggere i filtri, impostare i limiti in modo consapevole, stabilizzare l’underlay, documentare e standardizzare la routing policy.

Utilizzo corretto di collegamenti dedicati: Direct Connect/ExpressRoute nella pratica

I collegamenti dedicati risolvono molti problemi legati all“Internet“, ma introducono nuove responsabilità. Tre aspetti vengono frequentemente sottovalutati nei progetti:

1) La ridondanza non è un „nice to have“

Una singola porta o un unico circuito del provider è operativamente rischioso. Pianificate almeno due percorsi indipendenti (idealmente PoP/meet-me-room e provider differenti). Definite criteri di failover: link down, BGP down, soglie di perdita pacchetti/latency. E testate il failover non solo al go-live, ma periodicamente durante le finestre di manutenzione.

2) Una linea privata non sostituisce i controlli di sicurezza

La connettività „privata“ riduce la superficie d’attacco (nessun Internet pubblico come trasporto), ma il rischio interno rimane: configurazioni errate, movimento laterale, esposizione accidentale. Segmentazione, logging e controllo degli accessi restano obbligatori. Per gli accessi amministrativi spesso è preferibile passare tramite bastion/jump e identità forte (MFA, Conditional Access) piuttosto che permettere „RDP/SSH ovunque“.

3) La disciplina di routing determina la stabilità

Con ExpressRoute/Direct Connect il numero dei prefix spesso aumenta rapidamente. Senza liste di filtro chiare e ownership (chi può annunciare quali net?) si crea progressivamente una situazione in cui modifiche in un sito hanno impatti imprevedibili. Buona pratica: documentare la proprietà dei prefissi, gestire le modifiche tramite processo di change, e impostare i Max-Prefix-Limits in modo che una errata configurazione non comprometta l’intero routing.

Strategia di migrazione e rollback: pianificare per dormire sonni tranquilli

Una strategia di rollback chiara non è un documento a parte, ma parte del progetto. Per la connettività ibrida si sono dimostrati validi i seguenti principi:

Esercizio parallelo invece del Big Bang

Se possibile, implementate VPN e collegamento dedicato in parallelo. Usate priorità di routing (es. BGP-Pref, metriche) per effettuare la transizione in modo incrementale. Vantaggio: potete misurare sotto carico reale (latenza, drop, tassi di errore) e, in caso di problemi, riportare rapidamente indietro.

Passaggi di cutover espliciti con punti di misurazione

Definite per il cutover una checklist: raggiungibilità dei servizi centrali (DNS, identity, monitoring), workflow business critici, finestre di backup, accessi amministrativi. Importante è un criterio di stop: a quale sintomo interrompete e tornate indietro?

Rollback non solo „possibile“, ma provato

Il rollback spesso fallisce perché, sotto stress, qualcuno cambia „velocemente“ rotte e policy e alla fine nessuno sa quale fosse l’ultimo stato stabile. Praticamente aiuta:

• Versionare le configurazioni (anche per dispositivi di rete/oggetti di routing cloud).
• Eseguire modifiche in unità piccole e reversibili.
• Registrare misurazioni prima/dopo (latenza, perdita di pacchetti, conteggi di flow, tassi di errore).

Runbook: standard operativo per la connettività ibrida sicura

Un buon runbook evita che ogni incidente inizi da zero. I seguenti contenuti si sono dimostrati efficaci per i team di amministrazione:

1) Health-Check standardizzati

• Stato dei tunnel (IKE/ESP), eventi di rekey, stato DPD
• BGP Neighbor up/down, numero di rotte ricevute/annunciate
• CPU/throughput del gateway, scarti/errore
• Flow Logs/Firewall Drops per flussi di test definiti

2) Flussi di test definiti (sintetici)

Scegliete per ogni zona uno o due endpoint e porte da verificare regolarmente (es. HTTPS su monitoring-endpoint, DNS verso il resolver, SSH verso la bastion). In questo modo individuate precocemente errori di routing o di policy, prima che arrivino i ticket degli utenti.

3) Punti di escalation chiari

Chi è il responsabile per: IP-Plan, Cloud-Routing, On-Prem-Firewall, collegamento del provider, DNS? Senza questa assegnazione ogni guasto diventa una questione organizzativa.

Conclusione: quale opzione è adatta quando?

La VPN è la scelta corretta nella pratica quotidiana quando bisogna partire rapidamente, l’ambito è contenuto e si hanno sotto controllo le insidie tipiche (routing, MTU, rekey, ridondanza). Direct Connect/ExpressRoute conviene quando l’obiettivo è stabilità e scalabilità, quando si devono collegare molti network/sedi o quando i carichi di lavoro sono sensibili alle oscillazioni di Internet. In entrambi i casi a decidere non è l’etichetta del prodotto, ma la vostra architettura: segmentazione, disciplina del routing, monitoraggio e un piano di fallback collaudato.

Se state pianificando la vostra connessione ibrida o dovete stabilizzare un setup esistente, il passo successivo di solito non è „più banda“, ma una matrice di comunicazione pulita, un disegno chiaro di transit/hub e un runbook con controlli misurabili.