Site-to-Site VPN per filiali: IPSec vs WireGuard vs IKEv2 per le realtà russe

Introduzione: perché è un tema attuale e cosa imparerai

Nel 2026, la Site-to-Site VPN per filiali è diventata il tessuto di base della rete aziendale. Uffici, data center, cloud e sedi remote richiedono un canale sicuro sopra un internet imprevedibile e reti L3 degli operatori. Perché è particolarmente importante in Russia oggi? Instabilità nel routing, filtraggi periodici e DPI, eterogeneità dei provider, necessità di sostituzione delle importazioni e crescenti requisiti per la protezione dei dati personali e dei segreti aziendali. Questa guida confronta tre approcci pratici per S2S aziendale: IPSec, WireGuard e IKEv2 (inteso come stack IKEv2+IPSec), focalizzandosi su architetture, profili crittografici, affidabilità, prestazioni, gestione, errori tipici e casi reali.

Cosa otterrai: criteri chiari per scegliere il protocollo adatto alla tua topologia e ai requisiti normativi, istruzioni dettagliate per la configurazione, checklist per audit di readiness, consigli su MTU, NAT-T, superamento DPI, BGP sopra VPN e un framework per TCO e valutazioni dei rischi. Evitiamo volutamente la teoria accademica, concentrandoci su ciò che funziona nelle condizioni russe oggi.

Basi: concetti fondamentali (per principianti)

Cos’è una Site-to-Site VPN

Site-to-Site VPN collega due o più reti a livello IP, permettendo agli host della filiale A di accedere alle risorse della filiale B come se fossero nella stessa LAN o attraverso un core instradato. Il tunnel incapsula e cifra i pacchetti sopra internet pubblico o rete L3.

Elementi chiave

• Trasporto: UDP o TCP sopra IP. IPSec utilizza ESP e spesso UDP 500/4500 (NAT-T). WireGuard usa UDP (default 51820, configurabile).
• Crittografia: suite di cifratura, autenticazione, PFS, KDF. Focus su AEAD (AES-GCM, ChaCha20-Poly1305) per prestazioni e semplicità.
• Gestione chiavi: IKEv2 per IPSec, WireGuard usa chiavi statiche o gestori, con rotazione periodica integrata nel protocollo.
• Routing: rotte statiche o protocolli dinamici (BGP, OSPF) dentro il tunnel.
• Affidabilità: DPD, keepalive, monitoraggio SLA, canali di backup, cluster HA.

Cos’è IPSec, WireGuard, IKEv2

• IPSec: stack protocollo di rete (ESP/AH), con cifratura e autenticazione. Flessibile, maturo, supportato dalla maggior parte dei router e firewall. Tipicamente gestito da IKEv2.
• WireGuard: protocollo VPN moderno basato su Noise (NoiseIK), funziona solo su UDP, minimale, veloce e semplice da configurare.
• IKEv2: protocollo per instaurare chiavi e parametri di sicurezza per IPSec. Nel contesto aziendale spesso significa «IPSec con IKEv2».

Realtà russe

• DPI e routing instabili: il traffico UDP può degradare; è critico avere backup e parametri NAT-T flessibili e canali di fallback.
• Regolamentazione: per protezione dati personali e infrastrutture critiche – misure organizzative e tecniche; a volte serve certificazione o crittografia GOST.
• Sostituzione delle importazioni: sempre più scelto stack open-source (StrongSwan, VyOS, FRR) e vendor russi, mantenendo compatibilità tramite protocolli standard.

Approfondimento: aspetti avanzati

Sicurezza: profili crittografici e rotazione chiavi

• IPSec/IKEv2: suite raccomandate per il 2026 – AES-GCM-128/256, PFS (DH Group 14 o 19+), autenticazione con certificati (RSA-3072 o ECDSA P-256/P-384). Durata: IKE SA 8–24h, Child SA 1–4h; rekey anticipato.
• WireGuard: ChaCha20-Poly1305, Curve25519, HKDF; rotazione chiavi tramite timer protocollo e procedure operative; conservazione chiavi private in HSM o con accesso protetto.

Prestazioni e latenza

• Ritardi: IPSec ESP su hardware con AES-NI mostra latenza prevedibile, WireGuard spesso è più veloce con pacchetti piccoli e molti flussi per struttura compatta e stack semplificato.
• Overhead: IPSec ESP aggiunge 50–80 byte per pacchetto a seconda configurazione, WireGuard circa 32–60 byte. Influisce su MTU e necessità di MSS clamp.
• Throughput: su CPU x86 con AES-NI un core può gestire 1–3 Gbps IPSec AES-GCM con configurazione ottimale; WireGuard sullo stesso CPU raggiunge spesso 2–4 Gbps. Dipende da NIC offload, IRQ pinning e NUMA.

Affidabilità e resilienza

• DPD/Keepalive: per IPSec – DPD ogni 10–15s, retry 3–5 volte; per WireGuard – persistent keepalive 15–25s dietro NAT.
• Ridondanza: due provider indipendenti per sito, più tunnel (active-active con ECMP o active-standby), VRRP/Keepalived su nodi di frontiera, BGP nei tunnel.
• DPI e blocchi: preferibile UDP, ma in caso di blocchi mantenere profili paralleli per SSTP o offuscamento TCP per accesso d’emergenza a servizi critici.

Design di rete

• Full-tunnel vs split-tunnel: per filiali più comune split-tunnel: solo prefissi aziendali nel VPN, traffico internet locale per risparmiare banda.
• Spazio indirizzi: evitare overlap di RFC1918 tra filiali; pianificare blocchi /24 o /23 per sito, riservare IP per servizi gestionali.
• Routing dinamico: BGP con MED/LocalPref per scelta percorso ottimale; OSPF in perimetri chiusi; evitare redistribute complesse tra VRF.

Pratica 1: architetture Site-to-Site per vari scenari

Architettura A: Hub-and-Spoke

Hub centrale (data center o cloud) collega decine di filiali. Vantaggi: controllo semplificato, punto unico di sicurezza, analytics centralizzate. Svantaggi: rischio SPOF, carico sul core, scalabilità complessa senza ECMP e cluster.

• IPSec/IKEv2: schema maturo con StrongSwan/VyOS o gateway hardware. Consigliato BGP su ogni spoke, annuncio dei prefissi filiali all’hub tramite due tunnel indipendenti.
• WireGuard: configurazioni più facili da automatizzare su decine di spoke grazie a semplicità dei file e template. Necessario aggiungere controllo chiavi e inventario CMDB.

Architettura B: Mesh parziale

Filiali critiche collegate direttamente oltre all’hub. Vantaggi: percorsi più brevi, minor latenza. Svantaggi: tunnel aumentano quadraticamente, servono orchestratori automatizzati.

Architettura C: Dual-hub Active-Active

Due hub in sedi diverse, ECMP o BGP multipath, bilanciamento sessioni. Dettaglio: routing simmetrico o session stickiness. Per IPSec – SA dedicate per ogni percorso; per WireGuard – più peer con priorità diverse.

Scelta del protocollo in base al contesto

• Massima compatibilità hardware: IPSec/IKEv2.
• Semplicità e velocità: WireGuard.
• Requisiti di certificazione: IPSec con stack consolidati o soluzioni GOST-VPN specializzate.

Checklist architettura

• Due provider indipendenti per hub e filiali critiche.
• Piano MTU: 1400–1420 per interfaccia VPN, MSS clamp 1360–1380.
• BGP dentro VPN, filtraggio prefissi, blocco 0/0 dalle filiali.
• Backup gestione: OOB o modem LTE con tunnel d’emergenza.

Pratica 2: IPSec/IKEv2 — teoria, configurazione passo a passo, ottimizzazione

Profilo crittografico

• Fase 1 (IKEv2): AES-GCM-256, PRF SHA-256, DH Group 19 (ECDH P-256), durata 8h, ri-autenticazione abilitata.
• Fase 2 (Child SA): AES-GCM-256, PFS Group 19, durata 1–2 h, replay window 64–128.
• Autenticazione: certificati X.509, CRL/OCSP o certificati con durata breve (90–180 giorni) e rotazione automatica.

Istruzioni passo passo (logica universale)

1. Preparazione indirizzi: definire reti locali e remote, evitare overlap. Impostare regole NAT esclusive.
2. PKI: avviare CA interno, emettere certificati per ogni gateway, configurare Key Usage e SAN con FQDN/IP.
3. Parametri IKE: scegliere cifrature, durata lifetimes, DPD 10s. Se il provider filiale usa CG-NAT, abilitare assolutamente NAT-T.
4. Parametri IPSec: ESP in modalità transport o tunnel (di solito tunnel), PFS attivo, rekey anticipato (ad es. al 10% prima della scadenza).
5. Routing: rotte statiche iniziali, poi introdurre BGP con peer via indirizzi tunnel.
6. MTU/MSS: impostare MTU 1400, abilitare MSS clamp 1360 per TCP su interfaccia LAN.
7. Monitoraggio: esportare metriche in Prometheus/Influx, alert su caduta SA e aumento retransmit.

Ottimizzazione per reti russe

• NAT-T aggressivo: in presenza di NAT instabili e perdita keepalive – aumentare frequenza DPD, ridurre intervalli rekey.
• Duplicazione porte: porte UDP alternative in caso di pattern DPI; alcuni dispositivi accettano porte non standard.
• Failover: due tunnel paralleli a IP diversi dell’hub, ECMP o priorità SLA.

Framework di implementazione IPSec

• Pilota 1–3 filiali, traffico fino a 200 Mbps, raccolta metriche.
• Audit MTU/MSS/Fragmentazione e aggiustamenti.
• Transizione a BGP, eliminazione statiche dove possibile.
• Abilitazione logging eventi di sicurezza, test incidenti (disconnessione, compromissione chiave, rotazione CA).

Pratica 3: WireGuard — avvio rapido, gestione, sicurezza

Perché WireGuard

Funziona stabile su UDP, codice minimale, alta velocità, configurazioni semplici. Ideale per implementazioni di massa in filiali Linux/RouterOS/VyOS e su gateway x86.

Istruzioni passo passo

1. Chiavi: genera coppie chiavi per ogni nodo. Conserva chiavi private centralmente con controllo accessi.
2. Interfaccia: crea interfaccia wg0 con indirizzi in subnet dedicata al tunnel (es. 10.10.0.0/24).
3. Peer: sull’hub aggiungi peer di tutte le filiali, sulle filiali il peer dell’hub. Definisci AllowedIPs con le subnet necessarie.
4. Keepalive: attiva persistent-keepalive 20–25s, specialmente dietro NAT.
5. Rotte: configura rotte statiche o BGP tramite FRR sopra l’interfaccia wg.
6. MTU/MSS: MTU 1420, MSS clamp 1380 come punto di partenza.

Sicurezza WireGuard

• Controllo chiavi: inventario CMDB delle chiavi; regole di rotazione (ogni 90–180 giorni) e revoca incidente.
• Accesso minimo: restringi AllowedIPs a subnet reali, senza 0.0.0.0/0 se non serve full-tunnel.
• Filtraggio: firewall di sistema blocca UDP in ingresso a porta WG, whitelist sorgenti se possibile.

Ottimizzazione prestazioni

• CPU pinning per IRQ NIC e thread wg su core NUMA locali.
• Configurazioni GRO/LRO, RPS/RFS su Linux; monitoraggio drops con ethtool -S.
• Tunnel paralleli per alte velocità, ECMP lato routing.

Checklist WireGuard

• UDP accessibile su porta prescelta da entrambe le parti.
• Persistent keepalive configurato per nodi dietro NAT.
• MTU 1420 e MSS clamp 1380 verificati con traceroute e test.
• Log e metriche raccolti (wg show, esportazione Prometheus).

Pratica 4: IKEv2 in enterprise — certificati, MDM, scenari ibridi

Perché IKEv2

Standardizzato, ben supportato da gateway hardware e software, adatto per ambienti misti (Windows, iOS, Android, Linux). S2S di solito è IPSec gestito da IKEv2, ma aziende ibride possono usare la stessa PKI per S2S e accesso utente.

Approccio passo passo

1. PKI e policy: crea template certificati per gateway, abilita Extended Key Usage per IPsec IKE.
2. Profili IKE: definisci cifrature e gruppi DH; attiva MOBIKE per scenari mobili.
3. Separazione ruoli: certificati S2S separati da quelli VPN utente; rotazione rigorosa e audit.
4. Integrazione MDM: distribuisci profili IKEv2 sui client per scenari ibridi con accesso remoto.

Consigli pratici

• CRL/OCSP: se OCSP non disponibile, usa certificati short-lived; conserva CRL localmente.
• Scalabilità: evita un CA unico per tutti gli ambienti; suddividi in Intermediate CA per perimetri.

Pratica 5: NAT, MTU, DPI — come evitare perdita pacchetti

Diagnosi MTU

1. Esegui PMTUD con flag DF e aumento progressivo pacchetto, assicurando passaggio stabile.
2. Imposta MTU tunnel 20–80 byte sotto massima dimensione.
3. Configura MSS clamp TCP su interfacce di frontiera.

CG-NAT e UDP instabile

• Aumenta frequenza keepalive; duplica tunnel su porte diverse.
• In caso di degrado cronico, profilo di backup TCP (es. SSTP o OpenVPN TCP) per servizi critici, ma non come principale S2S.

DPI

• Rispetta profili legittimi di traffico, usa porte standard se possibile.
• Separa canali gestione e dati per mantenere controllo stabile.

Pratica 6: Routing e HA — BGP sopra VPN

Perché BGP

Il routing statico scala male. BGP offre controllo percorsi, recovery veloce e comportamento prevedibile in multi-hub. Si integra naturalmente sopra il trasporto S2S.

Passi

1. Indirizzi loopback: attiva loopback su ogni gateway, usali per peering BGP via tunnel.
2. Filtri: annuncia solo i tuoi prefissi; filtra esterni sull’hub.
3. Policy: MED/LocalPref per priorità hub; prepend per percorsi di emergenza.
4. Failover: timers rapidi (hello 3s, hold 9s) in rete stabile o BFD se supportato.

HA sui gateway

• VRRP/Keepalived su coppie gateway in filiale.
• Sincronizzazione configurazioni; CA di backup accessibile.
• Considera asimmetria routing e peculiarità firewall stateful.

Pratica 7: Osservabilità, gestione, SLO

Metriche

• Disponibilità tunnel: uptimes SA o peer wg, RTO, jitter.
• Throughput: p95/p99, errori e drops su interfacce.
• Sicurezza: autenticazioni fallite, frequenza rekey, dinamiche sospette routing.

Alerting

• SLO: 99.9% disponibilità traffico tra filiali; alert su soglie scese in rolling window.
• Tempi ripristino: MTTR fino a 5 minuti per filiale con canale backup.

Procedure operative

• Rotazione chiavi/certificati ogni trimestre.
• Test di disaster recovery: caduta provider, compromissione chiave, guasto gateway.
• Inventario aggiornato: registro filiali, prefissi, chiavi, contatti provider.

Errori tipici: cosa evitare

• Stessi RFC1918 in filiali diverse: causa asimmetria e hairpin. Pianifica spazio indirizzi in anticipo.
• Assenza MSS clamp: frammentazione e timeout imprevedibili TCP.
• Profili di cifratura deboli: cifrature obsolete (3DES, CBC senza AEAD), assenza PFS.
• Unico CA per tutti i perimetri: rischio effetto domino in caso di incidente.
• Monitoraggio postumo: implementa metriche e alert prima di scalare.
• Failover non testato: tunnel backup ma timers, BGP e NAT esclusioni non verificati.
• Single uplink: un solo provider su nodo critico – rischio downtime.

Strumenti e risorse: cosa usare

Stack software

• IPSec/IKEv2: StrongSwan, Libreswan, VyOS, pfSense; sistemi di rete con hardware AES-NI.
• WireGuard: integrato nel kernel Linux; supportato su Windows, BSD, RouterOS 7, VyOS.
• Routing dinamico: FRR (BGP/OSPF), BFD se disponibile, keepalived/VRRP per HA.

Monitoraggio e testing

• Prometheus, VictoriaMetrics, Grafana per dashboard.
• iperf3 per throughput e jitter, hping per test MTU/DF.
• Packet capture ai bordi (tcpdump) con filtri su porte ESP/UDP.

Gestione configurazioni

• GitOps: conserva template tunnel e politiche BGP in repo.
• Ansible per rollout massivi; segreti in Vault.

Avvio rapido per piloti

Per proof of concept e deploy agile in Russia, vpn.how si conferma come soluzione per ottenere velocemente un server VPN personale con IP dedicato (non shared), supporto WireGuard, OpenVPN, IKEv2, L2TP e SSTP – puoi scegliere il protocollo ideale per la tua rete. La copertura server include Mosca, San Pietroburgo, Amsterdam, Francoforte, Londra, New York, San Jose, Chicago, Singapore, Sydney, Madrid, Helsinki, Stoccolma, Varsavia, Copenaghen, Stavanger. Accetta carte russe (Tinkoff, Ozon), SBP e USDT/BTC. Tariffe a partire da 490 ₽ al giorno e 2490 ₽ al mese con sconti per periodi lunghi; avvio automatico in 5 minuti dopo pagamento e assenza di log permettono test rapidi senza lunghe gare d’appalto. Per produzione in grandi contesti meglio valutare infrastrutture proprie o soluzioni certificate GOST.

Casi e risultati: esempi reali di applicazione

Caso 1: rete retail, 120 filiali

Contesto: due vetrine dati, ERP e sistemi di cassa. Soluzione: Hub-and-Spoke su IPSec/IKEv2, due hub (Mosca, SPb), BGP sopra tunnel. Parametri: AES-GCM-256, DH19, Child SA 90 minuti, DPD 10s. Risultato: disponibilità 99.94% trimestrale, p95 throughput 250 Mbps per filiale, MTTR 4 minuti su guasto grazie a BFD+BGP failover. Insight: MSS clamp 1360 ha risolto l’80% degli incidenti di frammentazione nelle prime due settimane.

Caso 2: logistica, flussi backbone fino a 3 Gbps

Contesto: scambio telemetria e video tra hub e 8 siti. Soluzione: WireGuard con ECMP, due provider per lato, FRR BGP. Risultato: fino a 6 Gbps con due tunnel paralleli, latenza 10-15% inferiore a pilota IPSec, gestione semplice. Insight: IRQ pinning e disabilitazione offload inutili su NIC hanno aumentato throughput del 20%.

Caso 3: Fintech, politiche severe

Contesto: requisiti di segmentazione e audit, multi-cloud. Soluzione: IPSec/IKEv2 con PKI robusta, certificati brevi, CA separati per ambienti PROD/NON-PROD, procedure escrow. Risultato: audit superato con successo, rotazione automatica ogni 90 giorni, zero incidenti di compromissione in un anno. Insight: registro centralizzato tunnel e chiavi con change-review obbligatorio ha ridotto errori operativi del 60%.

Caso 4: produzione, provider instabili in regioni

Contesto: alcuni siti dietro CG-NAT, degradazione UDP periodica. Soluzione: WireGuard come principale, backup con IKEv2/ISAKMP su provider alternativo; per i casi più critici profilo SSTP solo per gestione. Risultato: downtime ridotto allo 0.3% mensile, RTO ripristino 2–3 minuti. Insight: keepalive aggressivi e separazione canali dati/gestione hanno eliminato falsi positivi di monitoraggio.

FAQ: 7–10 domande approfondite

1. Cosa scegliere per reti da 10–20 filiali con team IT limitato?

WireGuard offre semplicità e rapidità d’implementazione, soprattutto con hardware x86/VyOS/RouterOS. Se serve compatibilità con firewall eterogenei e compliance, opta per IPSec/IKEv2.

2. Quale MTU impostare di default?

Valori base: IPSec 1400, WireGuard 1420, MSS clamp 1360–1380. Poi calibra empiricamente con PMTUD e analisi frammentazione.

3. Si possono usare insieme WireGuard e IPSec/IKEv2?

Sì. Spesso WireGuard serve per traffico bulk, IPSec/IKEv2 per compatibilità o backup. La chiave è routing armonizzato e priorità BGP.

4. Quanto è sicuro WireGuard senza IKE?

WireGuard è sicuro secondo standard moderni, usa primitive robuste. Il rischio è nella disciplina operativa: gestione chiavi, minimizzazione AllowedIPs, rotazione puntuale.

5. Che succede con DPI e blocchi UDP in Russia?

Ci sono casi isolati. Mantieni profili di backup: porte alternative, tunnel parallelo con provider differente, profilo TCP d’emergenza per gestione.

6. Quando serve BGP e quando bastano statiche?

Fino a 5–7 filiali senza esigenze HA statiche bastano. Oltre, BGP riduce rischi operativi e accelera recovery.

7. Come pianificare le prestazioni?

Valuta traffico peak e p95, considera margini CPU e uplink 30–50%, tieni conto offload e NUMA. Per IPSec verifica AES-NI, per WireGuard pianifica tunnel paralleli ad alta banda.

8. Quali requisiti per dati personali e infrastrutture critiche?

VPN è solo una parte: servono misure organizzative, segmentazione, logging, gestione accessi. Per certificazioni valuta soluzioni certificate o crittografia GOST.

9. Quanto spesso ruotare chiavi e certificati?

Buona pratica: ogni 90–180 giorni, automatizzato. All’incidente revoca e sostituzione immediata.

10. Si può fare multicast/VoIP sopra VPN?

Sì, ma considera MTU, jitter, QoS. Spesso meglio SRTP su profilo dedicato e priorità WAN.

Conclusione: riepilogo e prossimi passi

Nelle realtà russe due pilastri tecnologici per Site-to-Site funzionano: IPSec/IKEv2 come standard universale e WireGuard come strumento leggero e performante. La scelta non è binaria: reti mature adottano soluzioni ibride adattando profilo a sito e traffico. Chiave per il successo è disciplina di rete: spazio indirizzi ben pianificato, BGP sopra tunnel, MTU/MSS corretti, resilienza a livello di canali e gateway, osservabilità e sicurezza regolamentata. Parti da un pilota: 2–3 siti, metriche, carico, test di emergenza. Affina profili, poi scala con GitOps e CMDB. Per POC veloci e test, un server personale da provider come descritto va bene; per produzione grandi cluster propri o soluzioni certificate. Fondamentale: non rimandare monitoraggio e test DR, e mantieni profili crittografici e chiavi sotto rigorosa disciplina. Così la VPN smette di essere una "scatola nera" e diventa una dorsale prevedibile del tuo business.