VPN basata su policy vs basata su routing: cosa scegliere nel 2026 e come evitare errori

Introduzione: perché la scelta del routing in VPN determina metà del successo

Di cosa si discute: policy-based contro route-based

Diciamolo chiaro: quando costruisci una VPN aziendale, la decisione più importante non è solo la scelta degli algoritmi di cifratura o del vendor. La chiave è un'altra. Come gestiamo il traffico? Con le policy oppure tramite rotte. Policy-based e route-based sono due approcci, due filosofie. Il primo si basa su regole che specificano quale traffico crittografare e dove indirizzarlo. Il secondo crea interfacce virtuali e si affida al router. Sembra semplice? Sulla carta sì, ma in produzione? Dipende.

Nel 2026 la posta in gioco è alta: cloud ibridi, SASE e SD-WAN, segmenti IPv6-only e esigenze crescenti di osservabilità. Il traffico salta tra filiali, cloud, partner e dipendenti remoti. Serve una scelta che regga la crescita, la compliance e aggiornamenti notturni senza perdere lo SLA. E sì, senza manovre da far montare l'aereo in volo ai tecnici.

In questo articolo analizzeremo onestamente e con esempi i tipi di routing in VPN, spiegheremo la differenza tra policy-based e route-based, mostreremo dove funziona meglio ciascuno e dove invece può causare problemi. Condivideremo ricette pratiche per la configurazione sulle piattaforme più diffuse e forniremo checklist per farvi partire col piede giusto.

Perché è importante adesso

La tendenza del 2026 è verso l'unificazione della rete. Le aziende uniformano WAN, VPC/VNet cloud e campus a una politica unica di routing, osservabilità e automazione. In questo contesto la policy-based IPsec non sempre tiene il passo con la dinamicità: telemetria E2E, ECMP, BFD, ispezione del traffico, multicloud con BGP over IPsec sono più facili in architetture route-based. Ma! Nei tunnel per singola app, dove la sicurezza prevale sulla flessibilità, la policy-based resta sovrana. Non siamo fan di una sola soluzione, ma pragmatici e amiamo i mix.

Dall’altra parte, la crescita di WireGuard e tunnel QUIC spinge i vendor verso modelli orientati alle interfacce. Anche i veterani del mondo IPsec classico ormai cedono: VTI, route-based, SD-WAN fabric sono la nuova norma. Quindi un buon ingegnere deve padroneggiare entrambi e saperli combinare efficacemente.

Tre errori comuni che fanno venire il mal di testa

Primo, voler far quadrare l'inquadrabile: applicare la policy-based dove serve chiaramente routing dinamico. Secondo, il "triangolo di tunnel": costruire decine di connessioni statiche dove BGP risolverebbe metà dei problemi in una serata. Terzo, sottovalutare MTU e MSS. La VPN vive di carico finale: un’impostazione sbagliata di DF e le call video del CEO diventano slideshow. Sì, i dettagli fanno la differenza. Sempre.

Teoria base: come IPsec si integra con il routing

IKE, SA e selettori di traffico

IPsec si compone di due blocchi principali: IKE (fase di scambio chiavi) e SA (Security Associations) che proteggono il traffico. Con IKEv2 negoziamo cifratura, autenticazione, lifetime. Poi formiamo le SA per ogni lato. Nei setup policy-based la selezione SA è la triade "sorgente, destinazione, protocollo/porta". Qui sta il dettaglio: più coppie e applicazioni uniche, più SA, più complessità.

Nel route-based i selettori sono spesso «any-to-any» dentro il tunnel, e il traffico si filtra e instrada tramite policy firewall sulle interfacce. Questo è più flessibile, specialmente con routing dinamico e multipath. I selettori smettono di essere un problema e non servono decine di ACL per ogni servizio.

SPD, SAD e policy di cifratura

Per decidere cosa entra in VPN e cosa no, il dispositivo consulta la SPD (Security Policy Database). Contiene regole per associare traffico ad azioni: cifrare o lasciar passare. La SAD (Security Association Database) conserva le SA attive con SPI, chiavi e durate. Nella policy-based la SPD è il collante, nel route-based è più semplice: tutto il traffico sull’interfaccia tunnel è cifrato di default.

Sembra una vittoria per route-based? Quasi. Se vuoi isolamento rigido e solo subnet precise nel tunnel, la policy-based lo realizza più esplicitamente. Nel route-based si ottiene lo stesso con filtri, ACL e VRF se serve.

VTI, GRE over IPsec e il dominio delle interfacce

Nel 2026 la maggior parte dei vendor supporta VTI - interfacce tunnel virtuali che offrono un collegamento logico point-to-point. Imposti IP, avvii OSPF o BGP, e vai. GRE over IPsec aggiunge incapsulamento GRE dentro la cifratura per multiprotocollo e casi particolari (es multicast), ma aumenta overhead e problemi MTU. Di solito, senza necessità specifiche, VTI basta e avanza. Stack più semplice, monitoraggio trasparente e automazione lineare.

Policy-based VPN: essenza, punti di forza e limiti

Come si costruisce una policy: ACL, crypto map e selettori

La policy-based si basa sul principio “se il traffico corrisponde alla regola, cifriamo”. In pratica: ACL (o simili) definiscono subnet origine, destinazione, a volte porte e protocolli. Queste regole si abbinano a profili crittografici tramite crypto map o simili. Ogni regola può generare un set distinto di SA.

Il vantaggio: isolamento chiaro e trasparente. Non serve creare interfacce dedicate, niente IP tunnel, meno complessità superficiale. Lo svantaggio: scalabilità. Quando vuoi cifrare decine di app in zone diverse con routing asimmetrico in cloud, iniziano i problemi. Le regole si moltiplicano, ogni modifica diventa “non c’è margine d’errore”.

Dove la policy-based brilla

Ci sono casi in cui questo tipo di routing è semplicemente comodo. Per esempio lo scambio dati puntuale con un partner: una o due subnet, confini rigidi, poca dinamicità. Oppure se hai un firewall perimetrale dedicato all’ispezione app e il tunnel è di supporto. Un altro caso: zone ad alta sicurezza dove si applica il principio di minimizzazione della superficie — niente interfacce extra, tutto sotto controllo di selettori precisi.

In alcuni gateway cloud datati la policy-based è ancora preferibile, specialmente se il provider supporta solo scenari selector-based. Non tutti, ma alcuni provider MPLS/VPN la usano perché funziona meglio nella loro infrastruttura.

Insidie e limitazioni

Il limite principale è la flessibilità. Quando serve routing dinamico, ECMP, BFD o traffico veloce tra cloud secondo SLA, la policy-based mostra resistenza. Qualche vendor prova a imitare la dinamicità con trucchi, ma sono compromessi, non strade facili.

Un altro problema è NAT e asimmetria. Se applichi NAT davanti a IPsec, rischi disallineamenti selettori. MTU diverse su percorsi differenziati generano "freezing" applicativi strani. La telemetria è più complessa: monitorare il tunnel come interfaccia è più semplice che raccogliere metriche indirette su SA e ACL. Nei grandi network si sente molto.

Route-based VPN: interfacce, dinamismo e scalabilità

Interfacce tunnel virtuali e il loro potere

La route-based si fonda su interfacce tunnel: assegni IP ai lati, poi routing normale. Vuoi OSPF? Certo. BGP? Facilissimo. Più percorsi e bilanciamento? ECMP, policy routing, PBR su interfaccia. Facile: il traffico che arriva sull’interfaccia tunnel viene cifrato. I selettori lasciano il palco.

Vantaggio enorme: strumenti di diagnosi standard. Ping, traceroute, SNMP, telemetria in streaming, SLA realistico. Non curi alla cieca: se l’interfaccia ha problemi, cerchi la causa, alert vanno a NOC e SIEM.

Routing: statico, OSPF, BGP

Le rotte statiche vanno ancora bene per reti piccole. Ma nel 2026, se hai più di cinque-dieci filiali e cloud, BGP over IPsec è uno standard de facto. Perché non OSPF? Va bene in semplici hub-and-spoke, ma BGP è più flessibile ai confini, gestisce meglio le policy, è più stabile con frequenti cambi. E nei cloud pubblici? Tutti i grandi provider amano BGP sui gateway VPN.

La dinamicità non è moda: garantisce rapida convergenza dopo guasti, aggiunta fluida di subnet senza magie manuali, politica evidente per preferenze percorsi. Non è lusso, ma base per SLO/SLA business.

Prestazioni e futuro

Router e NGFW nel 2026 accelerano hardware AES-GCM, molti hanno ChaCha20-Poly1305 per piattaforme senza AES-NI, ottimo. Nel route-based si inserisce facilmente un tunnel extra per migrazioni, QoS su interfaccia, SLA per singolo tunnel. SD-WAN usa quasi sempre approach route-based: controllo centralizzato, segmentazione, steering business. La policy-based può sostituire ma costa fatica e tempo, soprattutto in ambienti misti.

Confronto policy-based e route-based: criteri di scelta

Complessità e scalabilità

Se hai due uffici e tre server, probabilmente la policy-based è più semplice da configurare e gestire. Ma con la crescita vince route-based. Non devi tenere in testa centinaia di selettori, ma gestisci interfacce, rotte e policy. Riduci errori umani. Automatizzi meglio. Meno emergenze notturne.

Regola pratica: se hai cloud, più provider, esigenze di telemetria e convergenza rapida — route-based. Per scambi puntuali e limitazioni rigide — policy-based.

Sicurezza e trasparenza

La policy-based è chiusa per design. Cifra solo ciò che si definisce. Piace agli auditor e facilita alcuni standard. Il route-based è ugualmente sicuro, con meccanismi diversi: filtri su interfacce, zone, VRF, ACL. Se il team gestisce bene firewall e segmentazione, route-based offre controllo pari con bonus di scalabilità.

Compatibilità e intervendor

In reti miste con dispositivi diversi il route-based è spesso più prevedibile. I selettori variano e le estensioni IKE pure. L’approccio a interfaccia smussa differenze, utile in IPv6-only e BGP over IPsec. Però esistono legacy e limiti provider dove solo policy-based funziona. Serve buon senso e test pilota.

Scenari d’uso e architetture 2026

Filiale-filiale: da semplice a maturo

Livello base — policy-based tra due punti con una o due subnet. Economico, efficace, chiaro. Intermedio — hub-and-spoke con tunnel filiali-centro. Qui vince route-based: aggiungi filiale, attivi dinamica, policy sul hub organizzate. Avanzato — due hub in regioni diverse, ECMP, BFD, SLA tunnel, ispezione traffico, QoS. È quasi SD-WAN, e route-based è imbattibile.

Cloud ibrido: AWS, Azure, GCP

I cloud pubblici preferiscono route-based. AWS VGW, Accelerated GW, Azure VPN Gateway, GCP Cloud VPN parlano BGP. Imposti VTI, configuri ASN, pubblichi prefissi, fatto. Ci sono modalità policy-based in SKU base o limitazioni tra piattaforme, ma per flessibilità, DR e multicloud meglio route-based. Nel 2026 molti scelgono IPv6 in VPC/VNet e BGP è la salvezza per annuncio prefissi gestito.

SD-WAN, SASE e ZTNA

Controller SD-WAN usano overlay su tunnel route-based, proprietari o IPsec sotto. Anche SASE integrato al perimetro si basa su VTI: per metriche, bilanciamento traffico, policy business è tutto più semplice. ZTNA è diversa, ma in scenari ibridi serve backhaul verso reti interne; qui interfacce sono più comode. La ricetta? Mixare: policy-based per traffico delicato, route-based per massa e gestione.

Intervendor e fusioni

In merger spesso devi collegare reti diverse in fretta. Se vendor e policy variano, route-based accelera matching. Basta creare VTI, attivare BGP, filtrare e ampliare. Se serve sicurezza tagliente, usa policy-based per collegamenti critici e poi migra a interface-based quando la situazione si stabilizza.

Pratica: configurazioni su piattaforme popolari

Cisco: ASA/FTD e IOS-XE

ASA/FTD storicamente usa policy-based con crypto map e ACL. Ma recenti versioni supportano VTI e route-based, sebbene ASA abbia limiti in diagnostica e gestione. Per molti branch e BGP meglio IOS-XE (ISR/ASR/Catalyst) con VTI, profili IPsec, DMVPN o FlexVPN. Suggerimento: ASA policy-based per casi ristretti partner, rete principale su IOS-XE con VTI e dinamica.

Passi generali: definire politiche IKEv2 e cifrature, configurare IPsec transform-set/profili, aggiungere VTI con IP, attivare IGP o BGP, applicare ACL/firewall zone-based sull’interfaccia tunnel. Non dimenticare MSS clamp e PMTUD.

Juniper SRX e Fortinet FortiGate

SRX è forte in route-based con interfacce st0, ottima integrazione OSPF/BGP, toolkit policy ricco. FortiGate eccelle in VTI e BGP over IPsec, con GUI semplici per sopravvivere a serate impegnative. Entrambi supportano policy-based, ma consigliamo usarlo dove ha senso — selettori limitati, scambi partner, progetti piccoli. Per reti enterprise chiara vittoria di interfacce e dinamica.

Consigli pratici: su FortiGate impostare phase2 selectors 0.0.0.0/0 nel route-based per togliere limiti e filtrare con policy. Su SRX controllare security zones e policy verso/da st0 per evitare buche. Abilitare DPD.

MikroTik, pfSense/OPNsense, StrongSwan

MikroTik RouterOS v7 ha potenziato IPsec e BGP: route-based funziona bene, anche se permangono dettagli su interfacce e monitoraggio. pfSense/OPNsense con StrongSwan supportano entrambi: policy-based con Phase 2 subnet specifiche, route-based con VTI. Consiglio: se mirate al cloud o crescita, puntate su VTI; altrimenti migrare poi sarà una sfida.

In StrongSwan Linux route-based è quasi default: crei interfaccia tunnel (xfrm o vti), imposti rotte statiche o BGP (FRRouting), filtri iptables/nftables. Per protezione per-app e riduzione superficie usa configurazioni separate e selettori policy-based, ma è uno strumento mirato.

Cloud: AWS, Azure, GCP

— AWS: per dinamica usa AWS Site-to-Site VPN con BGP. Per prestazioni elevate Accelerated VPN o Transit Gateway con route-based e BGP. Policy-based è possibile ma più che altro per casi legacy. — Azure: VPN Gateway (route-based) con IKEv2, BGP, modalità active-active. SKU policy-based è di nicchia e limitato. — GCP: HA VPN con BGP è lo standard, Classic VPN è legacy. Sempre: verifica MTU end-to-end, filtra annunci prefissi, mantieni uptime con tunnel doppi e ECMP se disponibile.

Prestazioni, MTU e QoS

MTU, MSS e PMTUD: dettagli vitali

IPsec aggiunge overhead. VTI e GRE over IPsec ancora di più. Praticamente la MTU reale si riduce. Errori su DF e blocco ICMP Frag Needed uccidono pacchetti grandi. Soluzione: attiva PMTUD, consenti ICMP specifici, configura MSS clamping tra 1360 e 1380 per TCP con overhead tunnel, misura MTU sicura. E verifica su entrambi i lati, altrimenti c'è asimmetria.

Buona abitudine documentare valori MTU/MSS accanto alla configurazione tunnel per evitare errori ricorrenti. Tieni template di test per pacchetti grandi in caso di policy cambi.

Crittografia e accelerazione

Nel 2026 AES-GCM è quasi sempre accelerato in hardware. ChaCha20-Poly1305 è ottima alternativa per dispositivi senza AES-NI. La scelta della cifratura impatta latenza e throughput. Dai un’occhiata ai grafici reali: passare da AES-CBC+SHA1 a AES-GCM spesso migliora del 20–40%. Meno CPU, meno jitter, voce e video più felici.

Ricorda PFS (Perfect Forward Secrecy): non è una formalità ma protezione vera. IKEv2 è preferito su IKEv1 senza dubbio. Imposta lifetime SA ragionevoli: più brevi sono più sicuri, ma evita paranoie per non sovraccaricare CPU con rigenerazioni continue.

QoS e prioritarizzazione

Route-based permette QoS diretto su interfaccia tunnel, preserva/modifica DSCP, shaping per classi. Policy-based è più complesso e dipende dal vendor. Se trasporti voce/video via VPN, QoS è must-have. Non esitare a impostare policy per tunnel con SLA: se perdite pacchetti superano soglia, switch link. È buona ingegneria, non paranoia.

Affidabilità e monitoraggio

DPD, SLA e BFD: occhi e mani veloci

Dead Peer Detection ti informa se il peer è attivo. Per velocità reale su route-based aggiungi BFD sopra il tunnel e integralo in IGP/BGP. Avrai convergenze in centinaia di millisecondi, non decine di secondi. SLA IP o test equivalenti misurano qualità reale: latenza, jitter, perdite. Il routing è guidato da metriche reali, non da supposizioni.

Consiglio: crea profili timing e soglie standard per tipi di canali. Automattizza risposte. L’umano serve per analisi, non per corse a metà notte.

Active-active, ECMP e multi-path

Se il provider lo consente, alza due tunnel verso ingressi diversi. ECMP basato su SLA è prassi comune. Per servizi critici elimina single point of failure. Policy-based può farlo ma spesso poco elegante. Route-based naturale: interfacce multiple, pesi, probe, bilanciamento carico.

Osservabilità: log, flussi, telemetria

Nel 2026 viviamo in un mondo di networking osservabile. Log IKE/IPsec vanno in SIEM, NetFlow/IPFIX tunnel in analytics, metriche interfaccia in monitoraggio. Non è opzionale. Alert per degradi SLA e flapping tunnel sono d’obbligo. E sì, costruisci dashboard che spiegano ai manager dove si rompe tutto: la verità visiva fa miracoli.

Sicurezza e compliance

Crittografia moderna e agilità

Scegli IKEv2, PFS, cifrature AES-GCM o ChaCha20-Poly1305. Elimina algoritmi obsoleti. Aggiorna profili seguendo le raccomandazioni vendor. L’agilità criptografica — la capacità di migrare rapidamente a nuovi set — è ormai richiesta da compliance. Documenta, testa prima, pianifica il failover.

Certificati al posto di pre-shared key sono quasi obbligatori in reti medie e grandi. PKI può essere semplificata con ACME o integrazione con CA aziendale. Porta disciplina a processi e team.

Segmentazione, VRF e microisolamento

In route-based VRF è magia: separi tunnel, applichi policy diverse, limiti rotte. Un attacco in un segmento resta isolato. Nel policy-based effetto simile si ottiene con regole mirate, ma VRF è più semplice da sostenere e spiegare. Con microsegmentazione NGFW ottieni un modello solido di accesso minimo necessario.

Audit e retrospettive

Esegui revisioni periodiche: quali selettori servono ancora, rotte ridondanti, policy troppo ampie. Unisci log di IKE, IPsec, firewall e BGP per una visione unica. Incidenti amano il silenzio: non darlo. Dopo ogni grande change retrospettiva e aggiornamenti playbook.

Testing, diagnostica e errori tipici

Check-point per costruzione tunnel

Check facile: IKE SA esiste? Bene. IPsec SA? Selettori e SPD corretti? Ping su interfaccia tunnel? Traceroute e routing visibili? Se policy-based ACL precise e NAT non rompe selettori. Se route-based, verifica ACL in ingresso/uscita su interfaccia e vicinanza IGP/BGP.

Poi test app: sorpresa a livello L7 può arrivare - MTU, timeout, reconnect. Prepara test script con ping, curl, iperf, pacchetti vari. Meno improvvisazione, meno chance di problemi sottili.

MTU, frammentazione e bit DF

Errore classico: ICMP bloccato o DF ignorato, pacchetti grandi cadono silenziosi. Soluzione: PMTUD attivo, ICMP type 3 code 4 permessi, MSS clamp. Verifica entrambi i lati. E attenzione all’asimmetria: un lato MTU 1476, ritorno 1454 e comportamento app diverso. È fisica, non magia.

NAT-T e routing asimmetrico

NAT-T aiuta se un peer è dietro NAT. Ma crea complessità: porte duplicate, drifting session, bug firmware rari. Mantieni firmware aggiornati e diagnosi IKE/IPsec dettagliata. Routing asimmetrico è dolore: metà traffico su un tunnel e metà ritorno su un altro fa saltare firewall stateful. Progetta simmetria, usa policy per tunnel o session synchronization nei cluster.

Automazione e IaC per VPN

Terraform, Ansible e GitOps

Terraform per cloud e alcuni vendor, Ansible per config di rete, Git come fonte unica di verità. Route-based automatizza più naturalmente: parametri interfacce tunnel, ASN, liste annunci, SLA. Policy-based è possibile ma serve cura per gestire molti selettori e ACL.

Approccio GitOps: cambi via PR, controllo con linters, test automatici in staging, deploy programmato in orari di basso carico. Non è "troppo complicato", è più economico della prima grossa crisi.

Testing e verifica

Pattern "validate-before-merge": prima di prod test. Tunnel temporaneo in staging, controllo sessioni BGP, ping, MTU, tag QoS. Per policy-based verifica selettori design-compliant, assenza conflitti, NAT gestito. Per route-based correttezza rotte, assenza leak in VRF, policy coerenti.

Segreti e sicurezza automazione

Conserva PSK e certificati in vault sicuri (Vault, KMS, segreti Kubernetes se usi CNI). Non mettere chiavi in chiaro nei repo. Logga chi e quando cambia critto-policy. E soprattutto pianifica rotazioni chiavi regolari, non "poi quando capita".

Economia e scelta

Licenze, prestazioni e hardware

Calcola onestamente: alcuni vendor licenziano tunnel VPN, throughput, accelerazione critto. Route-based spesso usa più interfacce ma non sempre costa di più — dipende da piattaforma. Accelerazione hardware AES-GCM risparmia CPU e soldi: meno hardware per stessi SLA. In policy-based con molti SA piattaforme economiche soffrono prima in prestazioni.

Costi operativi

Il vero costo è la gestione. Route-based è più economica in ambienti con topologia variabile, reti in crescita e cloud. Monitoraggio, automazione, template uniformi sono alleati. Policy-based è vincente in scenari piccoli e statici. La scelta non è religione, ma bilancio di rischi e bisogni.

Il prezzo dell’errore di scelta

Scenario tipico: azienda triplicata con 100 tunnel policy-based e ACL per ciascuno. Ogni change è un campo minato. Switch a route-based avviene sotto pressione e di notte. Si sarebbero risparmiati mesi se avessero previsto VTI e dinamica da subito. Ci sono anche casi contrari: adottato interface-based ovunque e poi partner impone subnet rigide, costringendo a complicare ACL localmente. Regola d’oro: pianifica un approccio ibrido.

Checklist e best practices

Scelta architettura

• C’è cloud e prevista crescita? Scegli route-based, VTI, BGP.
• Scambio partner puntuale? Policy-based con selettori precisi.
• Serve SLA sul tunnel? Route-based con IP SLA/BFD.
• Richieste rigorose di segmentazione? VRF + firewall su interfaccia o selettori mirati.

Implementazione

• Definisci critto-policy: IKEv2, PFS, AES-GCM/ChaCha20.
• Verifica MTU end-to-end, attiva PMTUD e MSS clamp.
• Per route-based pianifica ASN, filtraggio prefissi, attributi BGP.
• Per policy-based minimizza selettori, evita regole porta-specifiche inutili.

Operatività

• Log IKE/IPsec in SIEM, metriche interfacce in monitor, alert per degradi.
• Rotazione regolare di chiavi e certificati, aggiornamenti firmware.
• Test automatici dopo cambi, retrospettive incidenti, aggiornamento playbook.
• Audit trimestrali di rotte e policy accesso.

Casi reali e template di soluzioni

Caso 1: da 20 a 60 filiali in un anno

Azienda parte con policy-based: due provider, tre partner, tutto semplice. Un anno dopo 40 nuovi siti e due regioni cloud. Migrano a route-based. Due VTI per sito, BGP con communities, ECMP, priorità VoIP. Risultato: convergenza sotto un secondo, aggiunta subnet flessibile, -30% incidenti NOC.

Caso 2: partner con vincoli regolatori

Partner accetta solo policy-based con selettori rigidi e parametri IKE. Soluzione: mantieni policy-based per quel link specifico, route-based per traffico interno. Perimetrale con traduzione DSCP e doppia ispezione NGFW. SLA condiviso, test carico svolti. Tutti contenti, nessuno riscrive standard.

Caso 3: migrazione da IPv4-only a ibrido IPv6

Cloud e filiali abilitano IPv6. Su route-based VTI lanciano BGP con due famiglie indirizzi, annunciano prefissi con cura, mantengono QoS e telemetria. Per servizi legacy con pacchetti piccoli, aggiustano MSS. Transizione senza downtime perché interfacce gestiscono coesistenza epoche diverse.

Trappole frequenti e come evitarle

Troppi selettori

Se in policy-based lista regole cresce più rapido del tuo playbook, sei a rischio. Soluzione: raggruppa subnet, usa tunnel interfaccia, sposta filtraggio su policy firewall. Migrazione graduale: prima canale route-based parallelo, poi switch rotte.

Zona cieca di monitoraggio

Policy-based senza interfaccia non ha metriche evidenti. Non ignorare. Dedica telemetria SA, usa log IKE/IPsec, NetFlow pre/post. O passa a route-based, dove interfaccia è miglior amico nell’osservabilità.

"Funzionava e improvvisamente si è rotto"

Spesso reset chiavi su un lato, bug firmware sull’altro, o NAT-T stanco. Aggiorna firmware, attiva diagnostica avanzata, confronta profili critto e lifetime. Mantieni matrice compatibilità vendor/versioni. Noioso ma salva notti insonni.

Piano di migrazione: da policy-based a route-based senza traumi

Migrazione per fasi

Crea VTI paralleli, imposta rotte statiche con metrica amministrativa più alta. Testa, attiva telemetria. Poi sposta parte dei prefissi sotto BGP a basso rischio. Verifica ACL interfacce conformi a sicurezza. Disattiva selettori policy-based gradualmente, non di colpo.

Controllo qualità

Accordi SLO: latenza, perdite, jitter. Definisci monitoring per rilevare degradazioni. Abilita BFD se possibile. Fai failover pilotato: spegni link, verifica convergenza, alert, comportamento app. Questo crash-test ripaga in ore risparmiate.

Comunicazione e documentazione

Documenta diagrammi, prefissi, ASN, critto-policy, MTU/MSS, comandi di controllo. Condividi checklist col team supporto. Pianifica finestre di modifica e piano di rollback — spesso è ciò che distingue migrazione controllata dal caos.

FAQ

Risposte rapide, parte 1

• Domanda: Cosa scegliere per un piccolo ufficio senza cloud? Risposta: Policy-based, se poche subnet e cambi minimi. Più semplice e economico da configurare.
• Domanda: Cosa scegliere per cloud ibrido in crescita? Risposta: Route-based con VTI e BGP. Offre flessibilità, telemetria e automazione semplificata.
• Domanda: Si possono mescolare gli approcci? Risposta: Sì, è normale. Partner e integrazioni puntuali policy-based, perimetro principale route-based.

Risposte rapide, parte 2

• Domanda: Come funziona QoS dentro IPsec? Risposta: Conservare DSCP e policy su interfaccia funziona meglio in route-based. Policy-based dipende dal vendor, più complesso.
• Domanda: Come risolvere "blocco" pacchetti grandi? Risposta: Attiva PMTUD, consenti ICMP Frag Needed, configura MSS clamp. Controlla MTU su entrambi i lati.
• Domanda: Serve IKEv2? Risposta: Sì, è più stabile, flessibile e sicuro di IKEv1. Meglio supportato nel cloud.

Risposte rapide, parte 3

• Domanda: Routing dinamico o statico? Risposta: Per 5 siti statico va bene. Per decine e cloud serve BGP. Prassi comune ormai.
• Domanda: Quanti tunnel configurare? Risposta: Minimo due per sito, verso peer/regione diversi. Serve per alta disponibilità e manutenzione senza downtime.
• Domanda: Come convincere auditor? Risposta: Documenta critto-policy, segmentazione, log, rotazione chiavi. Mostra controllo accessi interfacce se usi route-based.