La VPN non lascia passare il traffico? Analizziamo routing, metriche e conflitti nel dettaglio

Ti è mai capitato di connetterti a una VPN e sembri che internet sia andato in vacanza senza avvertirti? Oppure una parte delle risorse interne funziona, mentre un’altra rimane muta, come se fossi invisibile. Ci siamo passati anche noi. Conosciamo bene questa frustrazione. Il routing via VPN è una materia sottile. Un’impostazione sbagliata nella metrica o nel gateway predefinito e il traffico prende la strada sbagliata. A volte manca la rotta di ritorno. A volte il DNS guarda nella direzione sbagliata. E a volte l’MTU decide di fare uno scherzo, tagliando i pacchetti come uno chef pasticcione. Ma niente panico. Con calma, metodo e checklist alla mano, analizziamo tutto passo dopo passo.

Nel 2026 una VPN non è più solo “apri il tunnel e dimenticalo”. Siamo nell’era Zero Trust, SASE, ZTNA e di tanti scenari ibridi: cloud, sedi remote, smart working, reti mobili, tutto insieme. Sul tavolo ci sono WireGuard, IKEv2/IPsec, SSL-VPN sopra QUIC e persino tunnel su proxy e HTTP/3. E sì, molto spesso hai DoH, DNS aziendali con split-horizon, segmenti IPv6-only con NAT64/DNS64 e qualche politica in più che compete per il controllo del tuo traffico. Peccato? Forse, ma decisamente interessante.

Questo articolo è una guida pratica. Niente teoria fine a sé stessa. Vedremo casi concreti di conflitti tra rotte, capiremo come funzionano metriche e priorità su Windows, Linux e macOS, scopriremo dove saltano i gateway e perché il traffico diventa “monodirezionale”, configureremo lo split tunneling senza rompersi la testa e impareremo a fare diagnosi solide. Ci saranno casi reali, comandi utili, checklist e suggerimenti per l’automazione. E infine un FAQ da salvare tra i preferiti. Pronti?

Come funziona il routing in VPN e dove si incrina di più la logica

Tabella di routing: il regista principale del tuo traffico

Quando ci connettiamo alla VPN, nella macchina entrano nuove rotte. Ogni rotta ha una rete di destinazione, una maschera (o prefisso), un salto successivo (gateway), un’interfaccia e una metrica. La regola di priorità è semplice: prima si sceglie la corrispondenza col prefisso più lungo, poi si confrontano le metriche. Rotta più corta e metrica più bassa significa rotta preferita. E sì, a volte il client VPN aggiunge rotte “larghissime” (per esempio 0.0.0.0/0) che di fatto catturano tutto il traffico. E se non ci sono eccezioni configurate, internet sparisce come per magia. Sembra scontato, ma è da qui che conviene iniziare l’analisi.

Un altro dettaglio è l’ordine delle interfacce e le metriche automatiche. Su Windows e macOS il sistema spesso “decide per noi”, assegnando metrica automatica basata sulla velocità dell’interfaccia. Ti connetti a VPN sopra Wi-Fi e hai anche Ethernet vicino? Potresti trovare sorprese. Su Linux la storia è diversa: con routing basato su policy (PBR) e più tabelle di routing puoi vedere una rotta nella tabella principale e un’altra completamente diversa nella politica che intercetta il traffico. Il risultato: pacchetti diversi seguono strade diverse, anche se sembra tutto a posto.

Conflitti tipici: sovrapposizione sottoreti, duplicati e buchi neri

Il classico sono le reti RFC1918 sovrapposte: in azienda c’è 10.0.0.0/8, ma a casa di un dipendente il router ha assegnato 10.0.0.0/24. Oppure la VPN usa diverse sottoreti che si sovrappongono per effetto di aggregazioni BGP. Così la rotta verso la sottorete richiesta può essere coperta da un annuncio più generale, e si sceglie la rotta sbagliata. Vedi 10.20.0.0/16 e 10.20.5.0/24, la metrica del /16 è inferiore? Allora il traffico andrà fuori strada e partirà la caccia ai “buchi neri”.

Altro problema frequente sono i duplicati di rotte da parte del client VPN: per esempio, OpenVPN può aggiungere sia 0.0.0.0/1 che 128.0.0.0/1 (così si realizza il full tunnel) mentre qualcun altro ha già un default impostato. Il sistema sceglie una delle due, ma può perdere controllo sul traffico di ritorno. Terzo scenario: rotte interne aggiunte, ma assenza della rotta di ritorno sul server. Il pacchetto arriva a destinazione, ma la risposta prende una via tortuosa verso l’ISP e viene scartata. Risultato: asimmetria, il ping dal client funziona, ma dal server silenzio.

Client e server VPN: chi comanda le rotte e quando

I client si comportano in modo diverso. WireGuard usa AllowedIPs: filtro e router insieme. Metti 0.0.0.0/0 ed hai il full tunnel, lasci solo prefissi stretti ed è split. OpenVPN usa spesso redirect-gateway def1, route-nopull e push di rotte dal server per inserire i percorsi necessari. IKEv2/IPsec sfrutta selettori del traffico e politiche, e integrandosi con BGP puoi annunciare prefissi dinamicamente. Il server può imporre rotte al client oppure lasciar decidere la macchina locale.

Nelle grandi infrastrutture i server VPN lavorano con SD-WAN, PBR e firewall. Le rotte arrivano via BGP o statiche, e vengono assegnate solo le parti necessarie ai client. Importante capire chi fa il “capo” in quella topologia: client che decide dove mandare il traffico o server/controller che detta le regole? Da qui si capisce dove cercare il problema. A volte è più facile modificare il comportamento del client (per esempio disattivare auto-metric e impostare parametri espliciti) che forzare la politica server.

Diagnosi base: cosa controllare prima di tutto

Test di rete: ping, traceroute, MTR e verifica DNS

Parti dal semplice. Ping su IP di una risorsa interna: se risponde, c’è connettività. Ping su nome verifica il DNS. Se IP funziona ma nome no, il problema è nel resolver, split-horizon o nell’ordine dei DNS. Traceroute (o tracepath su Linux) mostra quale interfaccia e percorso prende il traffico. MTR serve per tracce lunghe e percorsi instabili, vedendo latenza e perdite in tempo reale.

Controlla dove va il traffico internet. Prova traceroute verso 8.8.8.8 o altro IP pubblico. Se dopo la connessione VPN la rotta cambia e il primo hop è interno al tunnel, è full tunnel. Se non hai full tunnel ma internet non funziona, potrebbe essere problema di DNS o MTU. Prova a caricare una pagina leggera e poi una pesante. Se si blocca sulle risorse “heavy”, segnati che potrebbe essere MTU o blocco PMTUD.

Tabelle di routing: Windows, Linux, macOS — cerca discrepanze

Su Windows usa route print e Get-NetRoute, e se serve Get-NetIPInterface per vedere le metriche delle interfacce. Controlla chi possiede 0.0.0.0/0, rotte più specifiche e metriche di interfaccia VPN e locale. Spesso basta disattivare la metrica automatica e impostare manualmente priorità per far andare il traffico nel modo giusto. Controlla anche le tabelle IPv6: route print -6 e Get-NetRoute -AddressFamily IPv6.

Su Linux guarda ip route show, ip -6 route e se sospetti PBR, ip rule list e le tabelle multiple (ip route show table 100 ecc.). Occhio a priorità e fwmark. A volte un’app assegna un fwmark e il traffico va su rotte differenti. Su macOS usa netstat -rn, route -n get , networksetup -listallnetworkservices e scutil --dns per capire ordine dei resolver e priorità interfacce. Spesso il problema è che l’interfaccia VPN è presente ma il “service order” non è aggiornato e il sistema preferisce il Wi-Fi.

Captura di pacchetti: Wireshark, tcpdump e strumenti di sistema

Quando la tabella di routing non spiega niente, attiva uno sniffer. Su Linux: tcpdump -i wg0 host indirizzo oppure tcpdump -i any port 53 per DNS. Vedi dove va realmente il traffico, se ci sono risposte e come cambia il TTL. Su Windows nel 2026 si usa molto pktmon e il classico Event Viewer, ma Wireshark resta il re: filtra per interfaccia VPN e indirizzo di destinazione. Se vedi SYN senza SYN-ACK, controlla rotta di ritorno e firewall.

Un altro consiglio è verificare PMTUD: attiva il df-bit e prova pacchetti grandi. Se si bloccano a metà percorso, forse vengono bloccati ICMP Fragmentation Needed. La diagnostica del DNS è a parte: scutil --dns su macOS mostra domini e resolver associati, su Linux resolvectl status chiarisce quale server effettivamente risponde. A volte basta modificare l’ordine dei resolver o aggiungere forwarding condizionale per i domini interni e la magia accade.

Metriche e priorità: come funzionano su Windows, Linux e macOS

Windows: auto-metric, InterfaceMetric e RouteMetric

Su Windows l’autopriorità è generosa ma non sempre intelligente. L’interfaccia più veloce può avere metrica minore e il sistema la preferisce. L’interfaccia VPN ha velocità virtuale e metrica strana. Perciò si disattiva spesso l’auto-metric per VPN e si imposta manualmente InterfaceMetric (ad esempio 5 o 15, a seconda del design). Poi si controlla RouteMetric per rotte specifiche: più basso è il numero, più alta la probabilità di scelta.

Controlla con Get-NetIPInterface e modifica con Set-NetIPInterface -InterfaceMetric. Per le rotte usa New-NetRoute o Set-NetRoute con RouteMetric. Se il client VPN impone un default ma serve split, gestisci le politiche client: per esempio route-nopull in OpenVPN e aggiungi rotte specifiche. Con Always On VPN e client aziendali moderni puoi configurare regole di inclusione/esclusione per non rompere internet e inviare solo rotte necessarie nel tunnel.

Linux: priorità, policy-based routing e tabelle multiple

Su Linux la metrica in ip route è solo parte della storia. Con ip rule ci sono più tabelle di routing e la priorità delle regole decide quale tabella gestirà il pacchetto. Questo sistema è potente ma rischioso: puoi creare regole basate su sorgente, fwmark, TOS, ma col rischio di isolare app. Se il client VPN aggiunge una tabella e regola con priorità alta, tutto il traffico può andare nel tunnel anche quando il default principale punta a internet.

Ricetta pratica: ip rule list, ip route show table main e altre tabelle usate. Controlla che le regole non si scontrino e la tabella VPN abbia rotte di ritorno. Idem per IPv6 con ip -6 rule. Per WireGuard ricorda che AllowedIPs non sono solo filtri ma aggiungono rotte. Scomponi AllowedIPs in prefissi precisi per split. Su iptables/nftables usa fwmark e tabelle ma documenta l’ordine, altrimenti tra un mese nessuno capirà perché browser e curl prendono strade diverse.

macOS: ordine dei servizi, ifscope e priorità del resolver

Su macOS la rotta dipende dal service order: i servizi più in alto vincono. Lo configuri via interfaccia o networksetup. Le rotte possono essere legate a ifscope, col sistema che sceglie l’interfaccia per destinazioni specifiche. Per diagnosi route -n get mostra interfaccia e gateway scelti. Se la VPN deve fare da “primario” su certe sottoreti, mettila più in alto e definisci le rotte precise.

Il DNS su macOS merita attenzione: scutil --dns mostra split-scenario, dove domini interni vengono risolti dal DNS aziendale e il resto da server pubblici. Se l’ordine è sbagliato, avrai errori strani: IP funziona, nome no. Sistemi con domini di ricerca, riordino dei resolver e assegnazione netta degli ambiti. Nel 2026 molti client VPN macOS impostano automaticamente regole per dominio, ma controllare a mano è sempre utile.

Gateway, NAT e routing asimmetrico

Gateway predefinito: cattura default e kill switch

Quando la VPN cattura 0.0.0.0/0 è normale per full tunnel. Ma ci sono implementazioni “creative”: invece di un default unico il client aggiunge 0.0.0.0/1 e 128.0.0.0/1, dividendo il mondo in due e mandando tutto nel tunnel. Furbo e compatibile. Il rischio arriva se il default locale non viene disabilitato e il sistema alterna le rotte in base alla metrica. Il risultato? Internet confuso e caotico. Meglio impostare priorità esplicite o attivare un kill switch che blocca traffico esterno al tunnel. Ma ricordati: se il tunnel cade, il kill switch può sembrare una sparizione di internet.

Gateway doppi e multi-WAN complicano: con due provider uno VPN, la risposta può tornare dalla “porta sbagliata”. Sul router si risolve con policy routing e marcatori, sull’host con una configurazione pulita di metriche e simmetria. Importante che i pacchetti in entrata escano dallo stesso lato, altrimenti il firewall interrompe le risposte “straniere”. Nei log vedrai messaggi strani e ti chiederai “perché il ping funziona ma l’app no?”

NAT-T, hairpin e simmetria del ritorno

IPsec sopra NAT (NAT-T) è ormai standard. Ma se il client è dietro un carrier-grade NAT e il server ha firewall rigido, serve “supporto continuo” da entrambe le parti: keepalive, gestione porte in uscita e timeout più morbidi. Hairpin NAT (quando accedi a un servizio interno dal suo IP esterno) spesso si rompe con VPN: il client va nel tunnel, il server risponde all’esterno e il percorso di ritorno si perde. La ricetta è DNS locali per domini interni e no hairpin dove non serve.

ECMP e bilanciamento su più link portano asimmetria: pacchetti di uno stesso flusso prendono strade diverse. I firewall interni a volte non amano questo “equilibrio instabile” e chiudono le connessioni. Se il traffico VPN passa da più provider, abilita stickiness per sorgente o 5-tuple, e verifica i percorsi di ritorno. La simmetria è fondamentale per la stabilità TCP, soprattutto se c’è ispezione in linea.

Traffico monodirezionale: rp_filter, rotte di ritorno e firewall

Su Linux rp_filter può scartare pacchetti se la presunta rotta di ritorno non corrisponde a quella reale. Con PBR complessi fa male: richiesta va via tabella 100 nel tunnel, risposta si aspetta su main verso internet — il kernel scarta. Soluzione: rp_filter loose mode o simmetria perfetta. Su Windows e macOS ci sono protezioni anti-spoofing e firewall che scartano flussi sospetti con rotte incoerenti.

Controlla firewall e ispezioni: SSL-VPN, proxy su 443, DPI possono tutte interferire sul traffico e tagliare pacchetti non standard. A volte basta disabilitare temporaneamente l’ispezione “smart” per vedere se il problema sparisce. Se sì, serve definire eccezioni dedicate al traffico VPN e riattivare l’ispezione con regole più accurate.

Split tunneling vs Full tunnel: come scegliere e configurare senza stress

Quando lo split tunneling è il tuo alleato migliore

Lo split tunneling risparmia banda, riduce latenza verso servizi pubblici e alleggerisce i concentratori VPN. Nel 2026 è fondamentale: videochiamate, CDN, SaaS vogliono un breakout locale. Esempio semplice: nel tunnel vanno solo 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 e domini interni, il resto di internet passa diretto. Utenti contenti, admin rilassati purché rotte e DNS siano a posto. Rischio? Minor controllo sul traffico esterno, serve gestire DLP e filtrare alla fonte.

Uno split corretto significa prefissi precisi e DNS ben configurato. Configura forwarding condizionato dei domini per non far uscire nomi interni fuori dai resolver pubblici. Su WireGuard scrivi bene AllowedIPs. Su OpenVPN disabilita redirect-gateway e pusha rotte specifiche. Su IKEv2 definisci selettori e liste accurate. Pensa a escludere o includere siti critici come banche o servizi governativi secondo policy: dentro o fuori tunnel di volta in volta.

Quando il full tunnel è giusto e sicuro

Il full tunnel serve dove compliance e sicurezza prevalgono sulla velocità: dati sensibili, regolamentazioni rigide, confini sicuri. Convogli tutto il traffico nella VPN, attiva filtri e ispezioni al perimetro, hai controllo centralizzato. È un percorso senza sorprese se la capacità regge e l’MTU è configurato bene. Zero perdite DNS e conflitti con policy locali. Nel 2026 molti SSL-VPN viaggiano sopra QUIC e mantengono velocità decenti anche col full tunnel.

Contro? Carico sui concentratori e possibili latenze maggiori. Approccio ibrido? Full tunnel con local breakout su gateway per categorie come video e CDN. Oppure architetture SASE: client si collegano al PoP più vicino, che applica policy e rilascia traffico in internet. Pianifica capacità e tieni d’occhio metriche: tunnel saturo si fa sentire subito dagli utenti.

Pattern di design: liste include/exclude, DNS split e PAC

Definisci chiaramente liste di inclusione ed esclusione. Le include sono comode per lo split: sai già quali reti vanno via VPN. Le exclude per full, per ritagliare le categorie “rumorose”. Usa split-horizon DNS: domini interni risolti da DNS aziendali, resto da pubblici, preferibilmente con DoH/DoQ se permesso. Un trucco extra sono i file PAC per proxy, per indirizzare app web nel modo giusto anche in scenari misti.

Documenta queste soluzioni in playbook: “se aggiungere nuovo SaaS, metti questa regola; se arriva un nuovo VPC, aggiungi prefisso e verifica la rotta di ritorno”. Così risparmi ore in futuro. E aggiungi test: un set leggero di curl, dig e traceroute eseguito automaticamente dopo ogni modifica ti protegge in caso di guasti.

Casi pratici: router domestici, cloud e smart working

Conflitti RFC1918: quando tutti usano 10.0.0.0/8 e nessuno è colpevole

Un dipendente si connette da casa con rete 10.0.0.0/24. In azienda c’è 10.0.0.0/8. Nella tabella rotte trovi 10.10.20.0/24 tramite VPN e 10.0.0.0/8 tramite gateway locale. Se la metrica del percorso generale è più bassa, vince lui e il traffico bypassa il tunnel. Diagnosi: route print o ip route, poi ping a IP interni. Soluzioni: alzare metrica del percorso locale, aggiungere prefissi più specifici in VPN o in extremis fare NAT per evitare sovrapposizioni.

Nel lungo termine meglio abbandonare 10.0.0.0/8 “artigianale” per un indirizzamento preciso e segmentato. Nel 2026 si migra verso blocchi distinti e registro comune. Se la migrazione è lenta, usa policy routing e SNAT sul gateway: traffico verso sottoreti problematiche via VPN, il resto locale. E non dimenticare la rotta inversa: i server devono saper rispondere a client con indirizzi fuori standard.

Cloud: AWS, Azure, GCP — P2S, BGP e rotte tra VPC

Problema classico: indirizzamenti diversi tra cloud multipli. Tra VPC e VNets ci sono peering, hub transit, firewall, e tu aggiungi P2S VPN per dipendenti. Se le rotte non sono annunciate correttamente alcune sottoreti risultano invisibili ai client. Soluzione: controllo centralizzato rotte, usa BGP dove possibile o esport statici con filtri chiari da cloud ai concentratori VPN. Controlla priorità lato client: se ha default via VPN, assicurati che il percorso di ritorno cloud torni dallo stesso gateway.

Altro caso sono CIDR sovrapposti tra cloud. O migrazione con reindirizzamenti o NAT temporanei. In casi critici traccia ogni salto: dal client al VPC e ritorno. MTR verso IP interno nel cloud, tcpdump sull’interfaccia tunnel e firewall cloud per trovare perdite. Con una visione completa, la soluzione arriva: modifica annunci, aggiustamento metriche o rotta di ritorno.

Reti mobili e IPv6-only: NAT64, DNS64 e CGNAT

I provider mobili spesso offrono solo IPv6 e usano NAT64/DNS64 per uscire su IPv4. La VPN sopra questa pila funziona ma con caveat. Se VPN ignora IPv6, traffico v6 esce fuori dal tunnel e certi servizi si comportano male. Soluzione: supporto IPv6 completo nella VPN, aggiungi prefissi, verifica rotte e attiva filtri. Configura DNS per risolvere correttamente risorse IPv4 interne anche con DNS64.

CGNAT dietro il client rompe certi tunnel con timeout aggressivi e senza keepalive. In WireGuard usa PersistentKeepalive, in IKEv2 guarda DPDP/DPD e lifetimes. Se la VPN usa QUIC su 443, prova quello: passa spesso meglio. Se app funziona per nome ma non per IP, verifica split DNS: il resolver pubblico potrebbe rispondere male, mentre quello aziendale va bene. Dettaglio frequente.

Strumenti 2026: observability, telemetria e novità

eBPF e telemetria in streaming: vediamo il traffico completo

Nel 2026 eBPF è mainstream non solo in cluster ma anche su workstation. Permette di sapere quale processo ha creato il socket, quale rotta ha scelto e dove si è perso il pacchetto. Strumenti come Cilium Hubble per server e agent leggeri sugli host aiutano a scovare casi complessi di PBR e asimmetria. Per noi significa vedere browser che manda traffico in VPN e tool di aggiornamento che va diretto su internet perché fwmark e tabella 200 lo hanno intercettato.

Su Windows si evolve pktmon e integrazione con log di rete. Su macOS ci sono profili app-specifici più comodi, su Linux bpftrace supporta evidenziare “chi va dove”. Aggiungi dashboard centralizzati: latenza tunnel, errori MTU, frazione traffico split/full, top domini. Quando vedi tutto, da “non funziona” si passa a “ieri alle 11:42 il 30% dei client ha perso PMTUD sul link Estremo Oriente”.

Test sintetici e health check: non aspettiamo che scatti l’allarme

Imposta test sintetici: ping verso subnet critiche, HTTPS su portali interni, richieste DNS alle zone necessarie, da più punti e con policy diverse. Fai girare i test ogni minuto e allarma al primo segno. Sul client un agente leggero con lista host e destinazioni. Lato concentratori health check API mostra status tunnel, tempi di reset, errori auth. Alert tarati bene risparmiano stress e tempo.

Metti rotte “canarino”: pochi client testano la configurazione prima degli altri. Se qualcosa si rompe, non cade l’intero sistema. È pratica standard DevOps che vale anche in rete. Aggiungi changelog, annota chi e quando ha modificato liste prefissi e rollback con un click. Trasparenza non è lusso, è scudo contro errori umani.

Assistenza intelligente e suggerimenti: da LLM a advisor nei client VPN

Non tutti amano “IA ovunque” ma aiuta davvero. Un assistente console che, da ip route e traceroute, ti dice dove metriche confliggono è una salvezza a notte fonda. Funziona localmente, senza chiamate esterne. Per esempio segnala: hai 10.20.0.0/16 e 10.20.5.0/24, la metrica più bassa è per /16, alza quella o aggiungi rotta più specifica. Oppure: DNS per internal.corp punta al pubblico, meglio un forwarding specifico all’azienda.

Molti client VPN 2026 integrano controlli automatici: diagnosi MTU, test leakage DNS, validazione liste split prima di applicare. Se il client segnala errore, ascoltalo. Spesso intercettano problemi che si vedrebbero solo in produzione dopo segnalazioni. E attiva sempre logging dettagliato. Quando il log tace, si indovina. Quando parla, abbiamo dati concreti.

Sicurezza, prestazioni e configurazioni raffinate

MTU, MSS clamping e buchi neri PMTUD

MTU troppo grande nel tunnel porta a strani freeze. La pagina si apre a metà e poi stop. Soluzione è scegliere MTU giusto e abilitare MSS clamping per TCP. Su Linux è una regola in nftables/iptables: riduci MSS a valore sicuro (1360-1380 per la maggior parte degli UDP tunnel). Controlla PMTUD: se ICMP vengono bloccati lungo il percorso, il meccanismo smart non funziona. A volte serve fissare MSS rigido, altre volte abilitare ICMP sul firewall. Fai A/B test: prima e dopo, la differenza si vede.

In reti con QUIC e HTTP/3 su 443 la sensibilità MTU è diversa, ma il problema resta. Quando il tunnel è UDP, perdita di frammenti e blocco di datagram grandi degrada la connessione. Regola base: parti con MTU conservativo e aumenta solo se serve, mai il contrario. E annota le impostazioni nel playbook, così domani non dimentichi cosa ha funzionato.

DNS: split-horizon, DoH/DoQ e ordine resolver

Il DNS può fare o disfare la giornata. Se domini interni finiscono su resolver pubblici, ottieni NXDOMAIN o peggio risposte sbagliate. Usa split-horizon: zone aziendali via resolver corporate, resto via pubblici, possibilmente con DoH/DoQ se permesso. Su Windows controlla ordine DNS interfaccia, su macOS usa scutil --dns, su Linux resolvectl. Se il client VPN può assegnare domini ai resolver corretti, attiva l’opzione.

Combattere leakage DNS nel 2026 è prassi. Molti client verificano dove vanno le richieste davvero. Fai test periodici: richieste a zone interne devono passare dal tunnel, le pubbliche come da policy. E non dimenticare i cache: a volte nascondono problemi. Pulire cache e rifare richiesta è una mossa semplice e utile.

IPv6-first, ULA e "Happy Eyeballs"

IPv6 non è più “ospite alla festa”, è il padrone di casa. Se la VPN ignora v6, avrai bypass di policy e comportamenti imprevedibili. Aggiungi rotte per prefissi ULA e globali IPv6, assicurati che filtri permettano porte e protocolli necessari. Controlla Happy Eyeballs: app scelgono v4 o v6 in base a latenza. Se v6 esce fuori tunnel e v4 no, c’è sbilanciamento. Soluzione unica: entrambi gli stack in VPN o split preciso con controllo DNS e rotte.

In IPv6 non c’è NAT come lo conosciamo, quindi i problemi di asimmetria si vedono di più. Configura le rotte di ritorno con cura. Ricorda che MTU grandi in v6 sono un vantaggio, ma solo se PMTUD funziona. Altrimenti torni ai sintomi di “pagina che si blocca”. Non farlo succedere, tieni checklist aggiornata.

Checklist, playbook e automazione

Checklist “niente panico”: passi rapidi in 10 minuti

Primo: verifica connettività IP e nome. Secondo: traceroute a indirizzo interno ed esterno. Terzo: controlla tabelle rotte e metriche interfaccia. Quarto: guarda resolver DNS e split DNS. Quinto: controlla MTU e prova a ridurre MSS. Sesto: cattura pacchetti su interfaccia VPN e locale. Settimo: verifica rotta di ritorno dal server. Ottavo: spegni temporaneamente ispezione smart e osserva. Nono: confronta configurazione client e server VPN. Decimo: documenta e annota tutto.

Questo checklist sembra semplice ma ti fa risparmiare ore. Seguilo come una guida, non saltare passaggi. A volte la soluzione è al punto due, altre al punto nove. L’importante è non perdere il filo e scrivere risultati. Tra un mese ringrazierai te stesso per averlo fatto.

Playbook per Windows, Linux e macOS

Windows: disattiva auto-metric su VPN, imposta InterfaceMetric a mano, controlla RouteMetric per sottoreti critiche. Diagnosi con route print e PowerShell. DNS: priorità interfaccia e resolver giusto per domini interni. Linux: controlla ip rule e tabelle, sistema priorità, configura fwmark se serve. WireGuard: attenzione a AllowedIPs. Configura MSS clamping e verifica PMTUD. macOS: ordina servizi con networksetup, scutil --dns per resolver, route -n get per selezione interfaccia. Ovunque: log client VPN e sniffer.

Non dimenticare modelli di modifica: file YAML con liste di subnet, metriche, domini DNS e regole. Conserva in Git, fai review, testa su canarini. Se c’è problema rollback con un commit. È standard di fatto che funziona bene in rete. L’automazione non sostituisce il cervello ma libera tempo per cose più importanti.

GitOps per rotte: verifica e applica in sicurezza

L’infrastruttura come codice arriva anche al routing. Lista prefissi e eccezioni va in repository. Apri pull request: si lanciano test sintetici in ambiente test, poi su gruppo canarino. Se tutto ok, rollout su client o server VPN. Se no, rollback e analisi. Niente “Petya ha dimenticato di aggiornare e Masha funziona”. Trasparenza e ripetibilità.

Aggiungi check statici: validatore CIDR, divieto sovrapposizioni senza flag esplicito, verifica che nuove rotte non taglino internet agli utenti. E registri “chi ha approvato”. Così trasformi il caos in processo controllato. E gli utenti smettono di fare beta tester in produzione.

FAQ: risposte rapide alle domande comuni

Perché dopo connettersi alla VPN sparisce internet?

Spesso il client VPN ha preso la rotta default (full tunnel) ma la rotta di ritorno internet manca o è bloccata dal kill switch. Controlla tabella rotte: ci sono 0.0.0.0/0, 0.0.0.0/1 e 128.0.0.0/1? Che metrica hanno? Fai traceroute a IP pubblico: se primo hop è interno al tunnel, internet dovrebbe andare via VPN. Se no, guarda DNS (resolver punti a server interni irraggiungibili dall’esterno) o MTU (pacchetti grandi bloccati). Test veloce: riduci MSS, usa DNS pubblico temporaneamente, verifica kill switch e riporta simmetria rotte.

Come risolvere conflitto di sottoreti identiche tra client e azienda?

Tre opzioni: 1) rimappatura in azienda (affidabile ma lenta), 2) NAT temporaneo per subnet in conflitto al confine VPN (veloce ma complesso), 3) policy-based routing con rotte precise a prefissi giusti e metrica più alta per rotta “generica” sul client. Parti da diagnosi: route print o ip route, verifica rotta che vince. Aggiungi prefissi più specifici nella config VPN per sovrastare la generica. Controlla rotta inversa su server e firewall. Registra conflitto nel registro indirizzi per risolverlo definitivamente, non solo tamponarlo ogni mese.

Split tunneling o full tunnel? Cosa scegliere?

Se priorità è sicurezza e controllo, scegli full tunnel. Se serve performance e risparmio banda, soprattutto per servizi pubblici, opta per split. Compromesso: full con local breakout sul gateway o approccio SASE, dove il nodo più vicino applica policy e scarica traffico in internet. Non dimenticare DNS e MTU: con split sbagliati possono sparire servizi interni o generarsi leakage. Idealmente fai pilota su canarini, misura metriche, poi rollout. Sceglierlo a caso quasi sempre si paga caro.

Perché il ping va mentre i siti non si aprono?

Ping usa ICMP, siti TCP/UDP su HTTP(S). Se ICMP va ma TCP si blocca, controlla MTU e MSS: probabilmente frammenti grandi tagliati in mezzo e PMTUD non funziona per blocco ICMP Fragmentation Needed. Altro motivo: DNS, se accedi per IP ma non per nome verifica quale resolver risponde e se la richiesta esce dal tunnel. Terza ipotesi: firewall o ispezione SSL bloccano traffico non previsto (es. QUIC). Attiva sniffer: se vedi SYN senza SYN-ACK verifica rotta di ritorno e regole server.

Come impostare priorità interfacce di rete e rotte?

Su Windows disabilita metrica automatica e imposta InterfaceMetric per VPN, poi RouteMetric per rotte chiave. Controlla con Get-NetRoute e route print. Su Linux guarda anche ip rule: priorità regole può mandare traffico su tabella differente. Su macOS configura service order con networksetup, verifica route -n get per singolo indirizzo. Regola valida ovunque: metrica minore e prefisso più lungo vincono. Documenta tutto così eviti effetti magici e sai chi ha cosa.

Come diagnosticare problemi solo su IPv6?

Prima assicurati VPN supporta IPv6 e ha rotte corrette (ULA e prefissi globali). Lancia ping6/tracepath6 verso indirizzo v6 interno, controlla ip -6 route o route print -6. Controlla DNS: record AAAA per domini interni devono risolversi via resolver aziendale. Verifica MTU: in IPv6 PMTUD è cruciale, blocco ICMPv6 rompe connessioni. Se app v6 scappa fuori tunnel per Happy Eyeballs, configura politica affinché entrambi gli stack siano allineati: entrambi tunnel o IPv6 escluso per certi percorsi. Log client VPN e sniffer ti daranno risposta definitiva.