Perché la connessione VPN si interrompe: 25 cause comprovate e come risolverle nel 2026

Perché la VPN si scollega nel momento meno opportuno: mappa delle cause 2026

Fisica del canale e capricci dell'etere

La VPN non vive in isolamento. Viaggia sopra Internet reale, che a volte si comporta come un ingorgo nelle ore di punta. Interferenze radio, celle 4G e 5G congestionate, calo del segnale, router domestico surriscaldato o semplice sovraccarico del canale in orario di punta: tutto questo mette a rischio la stabilità del tunnel crittografato. Quando la connessione di base "balla", i protocolli peggiorano la situazione: ritrasmissioni dei pacchetti, RTT instabile, jitter variabile. Ne segue una reazione a catena: i timer VPN credono che il peer sia perso e interrompono la sessione per evitare problemi, anche se voi avete solo attraversato un ascensore e preso un'ombra radio breve.

Perché è importante? Perché molti cercano impostazioni rare e complicate, dimenticando la cosa semplice: se la connessione di base oscilla più di quanto il protocollo consenta, nessun "flag magico" nel config potrà salvare la situazione. Prima stabilizziamo fili e onde, poi giochiamo con keepalive, MTU e NAT. La logica è chiara: fondamenta solide rendono un tunnel robusto.

Logica dei protocolli e timer

I protocolli VPN — WireGuard, OpenVPN, IKEv2/IPsec — mantengono la sessione grazie a un battito: ping, scambio chiavi, DPD, rekey, rotazione chiavi TLS. Non sono maghi, si basano su timer. Se la risposta non arriva in tempo, la logica è semplice: peer non raggiungibile, scolleghiamo e tentiamo di nuovo. Funziona bene quando i timer sono allineati al comportamento della rete reale. Male quando il NAT del provider chiude "il varco" dopo 25 secondi e voi fate solo un ping al minuto. O quando le chiavi si rinnovano ogni 30 minuti, proprio quando il canale fa un lieve break e la rete mobile decide di cambiare cella. Coincidenza? La sessione cade, anche senza un vero "guasto".

Nel 2026 vediamo una nuova scena: QUIC e DoQ diffusi cambiano come DPI e shape funzionano, i core mobili dormono più aggressivamente per risparmiare batteria e i provider stringono i timeout UDP. Risultato: le vecchie impostazioni standard di keepalive spesso non funzionano. Servono valori consapevoli, adattati al canale e scenario specifico. Non esiste la bacchetta magica, ma un profilo ben fatto.

Dispositivi del provider e NAT multilivello

CGNAT è diventato la norma. Un solo IP pubblico con centinaia di utenti dietro. Questo significa stato rigoroso e timeout aggressivi. Inoltre, cloud provider dove il server è anch'esso dietro NAT, più il router domestico. Si crea un doppio o triplo NAT. Un sandwich così non perdona silenzi: se non si mantengono vivi i pacchetti keepalive, "il varco" si chiude e vi trovate in una situazione in cui il client pensa di essere connesso, il server è sicuro che tutto va bene e il NAT silenziosamente cancella la mappatura UDP. Bello? No, un mal di testa.

Se aggiungi offuscamento e porte non standard, il DPI del provider inizia a riconoscere il tipo di traffico, attivando shaping mirato. Nel 2026 abbiamo casi di provider che tagliano flussi UDP sospetti dopo lunghi silenzi, mantenendo vivo il tunnel solo con un chiaro "battito" ogni 20-30 secondi. Non è teoria, è pratica comune.

Connessione instabile: reti mobili, Wi‑Fi e roaming

4G/5G mobili: CGNAT, QoS e "cambio cella"

Le reti mobili sono oggi veloci, ma a impulsi. Un secondo hai 200 Mbps, dopo tre scendono a 3 Mbps con jitter di 150 ms. Nel 5G NSA/SA la sessione si mantiene meglio, ma i timeout UDP di alcuni operatori sono rigidi: 20-40 secondi senza pacchetti e la tabella stati ti cancella. CGNAT peggiora: il provider segue milioni di flussi e non può "ricordare" un tunnel muto a lungo. Risultato: senza keepalive corretto, la VPN va in standby e si disconnette improvvisamente al primo carico.

Un caso a parte è il handover, quando il telefono cambia cella o banda. Guardi un video via VPN, arriva una chiamata e il modem cambia modalità, in 300-800 ms il tunnel fa un blink. Un protocollo ben configurato lo sopporta, uno male configurato pensa sia caduto il mondo. Ricetta? Ridurre le finestre di rilevamento, ma senza isterismi; mantenere un battito leggero; abbassare MTU per minimizzare frammentazione; evitare TCP-over-TCP in canali mobili.

Wi‑Fi: roaming, band steering e "rigorosa economia"

Il Wi‑Fi è diventato più smart: roaming tra access point, band steering 2.4/5 GHz, modalità power save. Ma l'intelligenza senza configurazioni attente genera interruzioni. Il client salta tra gli AP, perde temporaneamente la connessione, e in quel momento la VPN rinnova le chiavi. I router domestici abbondano di "acceleratori" e "modalità risparmio" che in pratica spengono la radio per frazioni di secondo, abbastanza per disturbare il tunnel. Aggiungi vicini, microonde e cemento e hai la tempesta perfetta per i protocolli sensibili.

Cosa aiuta? Una moderata riduzione della potenza degli AP, soglie nette per il roaming, disattivare opzioni power save aggressive, canale fisso senza rumore automatico in bande occupate. E ricorda, i pacchetti VPN competono con il traffico locale: se il controller taglia UDP per sovraccarico, spostare il protocollo su 443/UDP a volte fa miracoli. Ma con misura: prima misuri, poi agisci.

Internet cablato: shaping e picchi di carico

Con cavo è più semplice, ma non perfetto. Picchi serali di carico sono la norma. Se il DPI fa shaping “intelligente” per applicazione, una VPN UDP non standard finisce a rischio. Un dettaglio: certi router consumer hanno tabelle stati minuscole e CPU debole. Il tunnel regge fino a zero carichi. Al picco il processore va al 100% e il sistema scarica sessioni vecchie. Risultato: falso disconnesso, risolvibile con router decente, NAT a norma e offload hardware.

Consigli facili: prova con cavo "pulito", verifica QoS provider, disattiva acceleratori, modalità DPI e antivirus su router. E ovviamente scegli con cura porta e protocollo, se il provider è diffidente verso UDP. A volte passare a 443/UDP o 443/TCP con keepalive corretto porta stabilità magica.

NAT e timeout: perché il router "dimentica" il tunnel

Come funziona il NAT e perché spariscono le sessioni

Il NAT è un contabile. Gestisce una tabella di corrispondenza tra indirizzi interni e porte esterne. Ogni flusso è una voce. La voce esiste finché c’è traffico. Se manca traffico, il timer scade e la voce viene rimossa. Per UDP è ancora più severo: protocollo senza connessione e senza chiusura esplicita, quindi il NAT applica la regola "se taciti, sei andato". In pratica secondi o decine di secondi. La VPN tace perché stai leggendo una pagina senza scaricare nulla, e il NAT rimuove la voce. Il pacchetto successivo del tunnel va nel vuoto, il server non lo riconosce e scatta la riconnessione.

Con TCP è più morbido: SYN, ACK, FIN permettono al NAT di seguire lo stato e tenere aperto il flusso più a lungo. Ma TCP su TCP è un terreno scivoloso, perché doppia ritrasmissione e buffering causano "blocco" in caso di perdita. Perciò oggi si preferisce 443/UDP con keepalive e TCP come piano B in reti ostili o dove il DPI taglia UDP.

Timeout tipici su SOHO e CGNAT

Nel 2026 i dati sul campo dicono: router SOHO hanno timeout UDP 30-90 sec, TCP 5-15 min in stato established. Operator mobile con CGNAT, UDP 20-40 sec, a volte 60. Cloud load balancer UDP tiene 30-120 sec senza traffico, poi rimuove. Non sono standard, ma tendenze. Ci sono eccezioni, ma non puntarci. Se il tuo keepalive è più lungo del timeout più corto sulla strada, il tunnel ha poche chance.

Un fattore in più: la tabella NAT ha memoria limitata. Sotto carico i dispositivi abbassano dinamicamente i timeout. Ciò che di giorno dura 60 sec, la sera al picco può scendere a 20-30. Ecco perché in una stessa rete al mattino va tutto bene e di sera cade. Nessuna magia, solo gestione risorse.

Intervalli keepalive pratici

Andiamo al punto. WireGuard: se il peer è dietro NAT, PersistentKeepalive 25 sec è un buon punto di partenza universale. Su certi operatori meglio 20. Su mobili si può scendere a 15-20 se la batteria lo consente. OpenVPN: classico keepalive 10 60 (ping 10, ping-restart 60). Nel caso di NAT severi ping 5, ping-restart 30, ma attenzione a CPU e traffico. Per TLS-reneogotiate meglio allungare reneg-sec a 8-24 h per evitare picchi di turbolenza di rete. IPsec/IKEv2: DPD 30s con action=restart, NAT-T keepalive 20s (molti stack lo mandano automaticamente), rinnovo chiavi Child SA ogni 1-4h, IKE SA 8-24h. Attiva MOBIKE per gestire i cambi IP senza drama.

È importante bilanciare: keepalive frequenti rendono il tunnel più stabile su reti problematiche, ma consumano più batteria e traffico. La buona notizia è che i pulsanti moderni sono minuscoli, poche decine di byte, non megabyte. Per il mobile 20-30 secondi è un compromesso ragionevole per la tranquillità.

Keepalive, DPD e rekey: come evitare il silenzio fatale

WireGuard: PersistentKeepalive e roaming fluido

WireGuard è minimalista e veloce. Non mantiene "sessione" classica ma scambia chiavi brevi basate su Noise. Ecco perché un piccolo battito ogni 20-25s con peer NAT è fondamentale: mantiene viva la porta nella tabella. Nel 2026 client iOS e Android sanno svegliarsi intelligentemente anche in risparmio energetico, ma se il sistema spegne con forza la radio alza la priorità dell’attività in background per l’app VPN. Su server controlla che MTU e rotte siano allineate, altrimenti il tunnel "vivo" si blocca su frammentazione e perde pacchetti sotto carico.

WireGuard ha il vantaggio nel roaming: trasferisce il cambio IP esterno senza rompere tutto, se i timer sono impostati bene. Significa che al handover 5G la sessione resta quando OpenVPN su TCP si bloccherebbe. Ma senza keepalive e MTU corretti non succede niente di magico. Serve disciplina nei parametri.

OpenVPN: ping, ping-restart, keepalive e reneg-sec

OpenVPN è estremamente flessibile. La formula keepalive 10 60 è stabile per la maggior parte delle reti. Se vedi disconnessioni dopo 30-40 secondi di silenzio, prova a ridurre a keepalive 5 30. Evita ping-exit eccessivi sul client: chiude app e non sempre va bene per auto-reconnect. Meglio ping-restart, che fa rialzare il tunnel automaticamente. Su reneg-sec: intervalli corti (es. 3600s) vanno bene in reti prevedibili, ma su mobile una rotazione ogni 8-24h riduce i blackout casuali. Scegli in base al tuo uso.

Importante anche il trasporto. UDP con keepalive e mssfix è quasi sempre più stabile su canali ballerini. TCP salva dove DPI taglia UDP, ma costa ritardi, "blocco" su perdita e strani effetti buffering. Porta 443/TCP è ultima risorsa, non partire da lì se la rete consente UDP.

IKEv2/IPsec: DPD, durate SA e MOBIKE

IKEv2 parla la sua lingua. DPD 30s è il minimo consigliato, in reti difficili si può scendere a 15-20s. MOBIKE è essenziale su mobile: gestisce cambio IP senza ricreare IKE SA, importante al handover 5G. Child SA durano 1-4h, IKE SA 8-24h. Evita rinnovi chiavi troppo frequenti, altrimenti si interrompono le sessioni proprio nei momenti di rotazione, specie se la rete "respira" contemporaneamente. NAT-T keepalive in genere arriva automaticamente ogni 20s, ma controlla la tua configurazione.

Se il filtro blocca ESP, usa UDP encapsulation sulla porta 4500. Se il provider taglia "non standard", sposta traffico via 443/UDP a livello gateway. Non è ideale, ma tunnel vivo vale più di ESP puro inesistente in rete.

MTU, MSS e PMTU: il killer invisibile della stabilità

Quanti byte "mangiano" i tunnel

Ogni VPN aggiunge header extra. Quanto? In media: WireGuard circa 60 byte sopra IPv4 e un po’ di più su IPv6, OpenVPN su UDP con TLS tra 60-100 byte secondo cifratura e opzioni, IPsec ESP in tunnel con NAT-T spesso 60-80 byte. Non numeri precisi, ma ordine di grandezza chiaro. Cosa significa? Se la rete base ha MTU 1500, il tuo MTU utile nel tunnel è inferiore. Quando il sistema manda pacchetti grandi, o si frammentano o si perdono se lungo la strada bloccano ICMP "Fragmentation Needed".

Il blocco ICMP genera una magia nera: piccoli siti si aprono, grandi si bloccano, videochiamate vanno e vengono. I pacchetti si incagliano su MTU minore, non ricevono segnali per ridurre la dimensione e spariscono. L’utente accusa la VPN, ma è il "black hole" ICMP di rete.

PMTU, blackhole e perché i siti "congelano"

Il Path MTU Discovery aiuta a scegliere la dimensione sicura del pacchetto, dipende da messaggi ICMP. Molti amministratori e provider, per "non esporsi", disabilitano ICMP. Così PMTU si rompe e sessioni TCP usano MSS non sempre corretto. VPN aggiunge header extra, e hai problemi: alcuni contenuti si caricano, altri restano in sospeso, siti con molte tabelle/font mostrano risorse parziali o infinite rotazioni. I servizi video partono a qualità bassa, poi bitrate va giù e parte il buffering. A volte sembra una disconnessione perché l’app la chiude dopo timeout ripetuti.

Come risolvere: MSS clamping, MTU corretto e verifica

Pratica semplice: abbassare MTU sul tunnel. WireGuard inizia da 1420, se PPPoE o CGNAT severo scendi a 1380-1400, in mobilità a volte anche 1280-1360. OpenVPN aggiunge mssfix 1360-1400 secondo canale, e controlla che fragment sia spento se non conosci conseguenze. In IPsec al router di perimetro attiva TCP MSS clamping 1360-1380. Sono valori medi, ma funzionano nel 2026 dove ICMP è filtrato.

Come testare? Classico: ping con flag "non frammentare" a nodi noti, aumenti la dimensione finché scatta il rifiuto, poi togli overhead tunnel. Molti router hanno test MTU semplificato, usalo. E soprattutto testa non una, ma più destinazioni reali: CDN, servizi aziendali, videochiamate. Usano rotte diverse con MTU diverse.

Porta, offuscamento e scelta del trasporto

UDP vs TCP e la trappola TCP-over-TCP

UDP è la scelta naturale per VPN in tempo reale. Perdite compensate a livello applicazione, latenze minime, tunnel senza "doppia" affidabilità. TCP come trasporto VPN aggiunge un altro strato di ritrasmissioni che con perdite e jitter causano "blocco": un segmento perso blocca tutto e l’app pensa "tutto è perso". Non significa che TCP sia vietato: a volte DPI lascia solo 443/TCP. Ma se puoi usare 443/UDP o la porta predefinita WireGuard (51820/UDP) hai quasi sempre un’esperienza più stabile.

Nel 2026 molti operatori sono più "attenti" all’UDP. Un keepalive leggero e scelta attenta della porta cambiano il gioco. In reti aziendali dove UDP è osteggiato, mascherarsi da QUIC su 443/UDP spesso è meglio di porte esotiche. In casi estremi TCP su TLS 443 è piano B. Piano C sono encapsulazioni multilivello, ma complicano e aumentano latenza.

Scelta delle porte: 443/UDP, 443/TCP, 53/UDP, 8443 e 51820

51820/UDP è casa WireGuard, semplice e chiaro. Ma se il provider lo "vede" e declassa, passare a 443/UDP spesso aiuta: traffico sembra QUIC e attira meno sospetti. 443/TCP è chiave universale per firewall aziendali, ma occhio a TCP-over-TCP, specie su mobile. Porta 53/UDP a volte salva in reti con solo DNS abilitato, ma è una lama a doppio taglio: DPI analizza sempre più e può bloccare "DNS" strani. 8443 è un compromesso che a volte passa inosservato. Consiglio generale: cambia porta solo quando serve veramente, non per gusto.

Qualche parola su simulare traffico "normale": se la tua VPN ha TLS wrapping con fingerprint client coerenti coi browser popolari, sembra "web" e ha meno chance di shaping. Non è la panacea. In reti ostili verso la crittografia serve solo TCP su 443 e pazienza.

Offuscamento e strategie miste

L’offuscamento è un mantello invisibile visibile alla luce giusta. Il DPI 2026 riconosce molti vecchi trucchi. Funzionano pattern freschi e mimetismo sotto protocolli moderni. Strategie miste — traffico su 443/UDP e fallback a 443/TCP quando serve — danno stabilità migliore. Roaming tra profili client, porte diverse su uplink — pratica reale non teoria.

Ricordati: ogni offuscamento consuma CPU e aggiunge latenza. Se vuoi stabilità e non camuffamento, parti da buon trasporto e timer. Offusca solo se serve davvero superare un filtro, non per "moda".

Client e sistema operativo: energia, background e sicurezza

Android e iOS: limiti in background e batteria

I sistemi mobili risparmiano batteria con forza. Nel 2026 è ancora più evidente: politiche limitano attività in background, congelano reti con schermo spento, "chiudono" task. Se il processo VPN non ha eccezioni, timer keepalive sono ritardati, pacchetti spostati, finestra NAT si chiude. Risultato: disconnessioni periodiche senza motivo apparente. Rimedi: escludere app VPN dall’ottimizzazione batteria, autorizzarla in background, permettere dati in risparmio energetico, attivare "mantieni Wi-Fi attivo in standby" se serve.

Un altro dettaglio sono i "traffic shaper" e firewall integrati. Alcune rom OEM impongono regole esotiche che limitano UDP in background. Se vedi stabilità a schermo acceso e cadute in tasca, controlla queste politiche. A volte basta aggiornare il sistema: lo stack di rete e API VPN evolvono ogni anno.

Windows e macOS: driver, firewall e "rete intelligente"

Su PC c’è un mondo a parte. Driver vecchi di adattatori virtuali, conflitti con antivirus, firewall troppo rigidi sono un trio che fa saltare la stabilità proprio in meeting. Aggiorna driver TUN/TAP o Kernel-adapter, assicurati che DLP e agenti rete si fidino della VPN. I check NCSI di Windows possono cambiare politica rete se sospettano "nessuna connessione". Se DNS tramite tunnel è mal configurato, il sistema pensa di essere offline e cambia priorità, causando disconnessioni per "troppe cure" del sistema.

Su macOS verifica Network Extensions e profili: alcune politiche intercettano traffico e chiudono tunnel in sleep. Su portatili è utile disattivare "put hard disks to sleep" aggressivo e tenere rete in "Power Nap" per VPN attiva con coperchio chiuso. Nessuna magia, solo spunte giuste.

Politiche client: riconnessione, kill switch e split tunneling

Come si comporta il client determina cosa conta come disconnessione. Riconnessione automatica con backoff esponenziale è preziosa. Kill switch severo protegge ma a volte danneggia stabilità, chiudendo rete locale al minimo blink tunnel. Serve modalità intelligente: mantenere rete locale aperta per domini selezionati (NTP, captive portal) così il sistema non si spaventa e non "guarisce" da "nessuna connessione".

Lo split tunneling scarica il carico e riduce rischi di blocchi MTU se i grandi flussi video passano fuori tunnel. Ma con routing sbagliato crea asimmetria: richieste via VPN, risposte fuori. Risultato: timeout e disconnessioni. Configura bene le liste, verifica con servizi reali, non solo ping gateway.

Server e infrastruttura: strozzature invisibili

Prestazioni: accelerazione crittografica, IRQ e CPU

Server "soffocato" fa cadere VPN come una rete incerta. Criptografia consuma, ma nel 2026 quasi ovunque c’è accelerazione hardware: AES-NI su x86, estensioni ARMv8 Crypto, persino offload su alcune NIC. Attivali. Distribuisci IRQ per core, abilita RPS/RFS su Linux, monitora irqbalance per evitare overloading di un core. Imposta CPU su performance per processi VPN, altrimenti il scheduler abbassa frequenza e a picchi hai "strozzature" e disconnessioni timer.

Su scenari multiutente non far girare cifratura, routing e DPI su uno stesso core. Dividi i ruoli. Imposta limiti di sistema per file e socket aperti. Mantieni riserva risorse: 30-40% headroom è una finestra confortevole per picchi.

Virtualizzazione e cloud: noisy neighbor e SR‑IOV

Il cloud è un computer altrui. Un noisy neighbor in hypervisor può caricare disco e rete, e la tua VPN lampeggia senza motivo. Se il provider ha SR‑IOV o NIC virtuali accelerati (ENA, Virtio ultima generazione), attivali. Routing via NAT e load balancer cloud aggiunge timeout e limiti a volte più stretti che on-premise. Testa la connessione client non solo nel data center ma anche fuori.

In alcune zone i cloud provider filtrano più severamente UDP "strani". Scegli porte 443/UDP o varianti, metti keepalive leggero al gateway e monitora drop ingress/egress. A volte basta cambiare AZ o famiglia istanze per eliminare guasti inspiegabili.

Tempo e crittografia: NTP, certificati e OCSP

Sincronizzare tempo è noioso finché non crolla. Orologi sballati rompono certificati, OCSP, CRL e a volte politiche rekey. Il sistema pensa che il certificato "non sia valido", interrompe sessione e non riconnette. Due nodi con fusi orari diversi interpretano timer diversamente e compare "magia" di disconnessioni a orari fissi. Soluzione: due pool NTP indipendenti, monitoraggio drift, evitare dipendenze rigide da OCSP esterni in reti chiuse aziendali.

La rotazione chiavi è anch’essa cruciale. Pianificala in finestre "silenziose" senza utenti in videochiamata. Allungare il ciclo vitale riduce la probabilità di coincidere con microproblemi di rete. Assicurati che i client ricevano in anticipo nuove radici di fiducia, altrimenti "disconnessioni istantanee" durano finché l’utente aggiorna il profilo.

Monitoraggio: metriche, log e SLO

Non si controlla ciò che non si misura. Metriche utili: frequenza riconnessioni per protocollo, RTT medio e 95-esimo percentile nel tunnel, % drop interfaccia, numero DPD-timeout orari, rotazioni chiavi e correlazione con disconnessioni. SLO stabilità: max 1 reconnect ogni 8h su mobile, max 1 al giorno su fisso.

Nei log cerca non solo "Connection reset" ma anche "Inactivity timeout", "NAT-Keepalive sent", "DPD failure", "MOBIKE rehomed". Nel 2026 molti client scrivono motivazioni leggibili. Unisci in dashboard e scopri pattern: disconnessioni simultanee in orari fissi indicano spesso provider o rotazione chiavi pianificata.

Diagnosi passo passo e profili pronti

Test rapido in 5 minuti

Passo 1: cambia trasporto. Se usi TCP, prova UDP su 443 o 51820. Passo 2: riduci MTU tunnel di 20-40 byte, verifica siti pesanti e videochiamate. Passo 3: attiva keepalive aggressivo a 20-25 secondi (WireGuard PersistentKeepalive 25, OpenVPN keepalive 10 60, IKEv2 DPD 30). Passo 4: escludi app VPN da risparmio e abilita background. Questi quattro passaggi risolvono 60-70% dei problemi senza "magia".

Perché funziona? Perché rispettiamo tre realtà: NAT ama il battito, reti odiano pacchetti grandi senza PMTU, sistemi mobili risparmiano batteria. Il resto è tuning fine. Se la disconnessione resta ma scema, sei sulla buona strada. Poi si approfondisce.

Test avanzato in 30 minuti

Raccogli traccia: misura RTT e jitter con e senza VPN, controlla perdite UDP sotto carico (es. download grosso parallelo). Confronta porte diverse (443/UDP, 443/TCP, 51820/UDP). Verifica roaming: cammina in casa, cambia piano, gira telefono in 4G/5G. Segna micro-pauses e allinea ai log client: DPD timeout, reneg, reauth, reconnect. Hai la causa precisa, non "sembra la rete".

Poi controlla server: carico CPU, drop interfaccia, qdisc, offload, irqbalance. Confronta con macchina di controllo o altra AZ in cloud. Se in altro segmento il problema sparisce è server/infrastruttura, non client. Testa DNS: DNS mal instradato rompe NCSI e scatena "auto-cura" OS che distrugge stabilità.

Profili pronti per scenari

Profilo "Mobile aggressivo": WireGuard PersistentKeepalive 20-25, MTU 1380-1400, porta 443/UDP, MOBIKE-esque attivo, ottimizzazione batteria VPN disabilitata, OpenVPN keepalive 5 30, reneg-sec 28800, mssfix 1360-1380. Perfetto per 4G/5G con roaming tra celle e Wi-Fi smart.

Profilo "Ufficio stabile": trasporto UDP su 51820 o 1194, keepalive moderato (WireGuard 25, OpenVPN 10 60), MTU 1420-1450 in canale normale, MSS clamp 1360-1400 al gateway, rotazione chiavi 8-24h in orario notturno, monitoraggio DPD-fail, SLO massimo 1 reconnect al giorno. Adatto per postazioni fisse e videochiamate.

Casi reali: come abbiamo risolto disconnessioni

Operatore mobile e UDP "cadente"

Situazione: utenti lamentano disconnessioni ogni 25-40 secondi in 5G. Verifica: CGNAT con timeout UDP 30s nelle ore di punta. Soluzione: spostato WireGuard su 443/UDP, PersistentKeepalive 20s, MTU 1380, DNS caching in tunnel. Risultato: numero riconnessioni ridotto 9 volte, bug report cessati. Controindicazione: traffico background aumentato 0,6-1,2 MB/h, accettabile.

Perché ha funzionato: siamo entrati nel timeout e non abbiamo lasciato al NAT il tempo di "dimenticarci", più mimetizzazione su trasporto popolare ha ridotto shaping. Riduzione MTU ha eliminato blocchi di pagine grosse che gli utenti scambiavano per "cadute".

Router domestico e "ottimizzatore gentile"

Situazione: Wi-Fi si interrompe passando tra stanze, OpenVPN UDP. Log puliti. Scoperto "modalità risparmio intelligente" su access point che metteva radio in breve sonno ogni 30s a riposo e riorganizzava canale a carico. VPN perdeva pacchetti consecutivi e cadeva per inactivity. Soluzione: disattivato power-save aggressivo, fissato canale, ridotta potenza per evitare "nomadismo" client. Aggiunti keepalive 10 60 e mssfix 1360. Esito: nessuna interruzione.

Morale: a volte il problema non è il protocollo ma una funzione "intelligente" con nome accattivante. Controlla tutte le spunte nella GUI router. Bel nome non sempre significa utile per il tunnel.

Rete aziendale e "divieto ESP"

Situazione: IKEv2/IPsec dura 10-15 minuti e cade. Diagnosi mostrava filtro ESP sul firewall in certi pattern carico. Spostato traffico su UDP wrapping 4500, attivato DPD 30s, MOBIKE, allungate durate SA e spostato rekey notte. Aggiornato TCP MSS clamping 1360 al perimetro. Risultato: nessun errore per turni, stabilità aumentata, chiamate vocali non si interrompono più.

Lezione chiave: non litigare con le politiche hardware, adattarsi. ESP puro è bello sulla carta, ma se la rete lo odia, usa trasporto compatibile e timer corretti.

Checklist configurazione: veloce e dettagliata

Checklist base per stabilità

• Trasporto: usa UDP, se bloccato 443/TCP come piano B.
• Porta: 51820/UDP per WireGuard o 443/UDP se DPI sospetto.
• Keepalive: WireGuard 20-25s, OpenVPN 10 60, IKEv2 DPD 30s.
• MTU/MSS: inizia con MTU 1420 per WG, mssfix 1360-1400 per OpenVPN, MSS clamping 1360-1380 su IPsec gateway.
• Risparmio energetico: escludi client VPN da ottimizzazioni, abilita background.
• DNS: usa resolver stabile in tunnel, abilita cache.
• Monitoraggio: segui DPD-timeout, reconnect e RTT in dashboard.

Checklist avanzata per admin

• Server: attiva cifratura hardware, configura IRQ e offload.
• Cloud: verifica SR‑IOV/ENA, evita noisy neighbor.
• Tempo: due NTP indipendenti, monitor drift, controlla OCSP/CRL.
• Profili: separa configurazioni mobile e fisse per keepalive e MTU.
• Rinnovo chiavi: rekey in orari silenziosi, con lifetimes non troppo brevi.
• Log: parsing automatico cause disconnessione, correlazione con provider.

Economia del keepalive e compromesso ragionevole

Quanto "costa" la stabilità

Domanda frequente: il keepalive consumerà tutto traffico e batteria? No. Un battito tipico è pochi byte. A intervallo 20 secondi consumi pochi megabyte al giorno. La batteria perde frazioni di percentuale all’ora se il sistema non soffoca il background. Il prezzo per niente disconnessioni in chiamate video e RDP è più che ragionevole. Ma bilancia: battito troppo frequente con migliaia di client pesa sul server. Scegli in base a timeout rete e dimensione infrastruttura.

Su scala operatori aiuta il battito adattivo: client cablati 30-60 s, mobili 15-25 s, con DPI sospetti 20 s e fallback da monitoraggio. È l’approccio maturo 2026, con client che si adattano al contesto.

Dove non forzare fino al limite

Non portare MTU al minimo "per sicurezza". MTU troppo basso aumenta overhead e penalizza performance. Non abbassare reneg-sec a 48h pensando "meno è meglio": la politica crittografica conta, e rotazione troppo rara è rischio. Non usare TCP-over-TCP senza reale necessità: serve solo in reti davvero chiuse, e anche lì con settaggi finestra e buffer. Non attivare tutto l’offuscamento insieme: aumenta latenza e la causa può essere un singolo flag power-save mal configurato.

FAQ

Risposte rapide

Qui raccogliamo risposte che spesso salvano tempo. Se vuoi riparare disconnessioni velocemente, parti da queste e poi approfondisci. La maggior parte dei problemi VPN non è unica: NAT, MTU e politiche di sistema spiegano l’80% dei casi.

Perché la VPN è stabile nel browser ma si interrompe durante la chiamata?

Voce e video richiedono RTT stabile e minimo packet loss. Quando la rete "respira", TCP recupera dati per la pagina, ma la videochiamata soffre: pacchetti persi penalizzano qualità e timer. Se il tunnel è su TCP, sperimenta il blocco TCP-over-TCP. Soluzione: usa UDP, abbassa MTU, aumenta keepalive a 20-25 s e, se possibile, usa porta 443/UDP che gli operatori soffocano meno. Controlla roaming Wi-Fi e disattiva power-save aggressivi.

Che valore usare per PersistentKeepalive in WireGuard su telefono?

Parti da 25 secondi. Su reti con CGNAT di operatori mobili spesso sono meglio 20 secondi, su reti “molto aggressive” 15. Consuma un po’ più batteria, ma entro frazioni di percentuale all’ora. Se la rete è stabile e senza interruzioni puoi rilassare a 30-40. Monitora log: se DPD o handshake si attiva troppo spesso, riduci l’intervallo.

Tuning fine

Qui domande tipiche dopo una configurazione base fatta. Parliamo di dettagli: rotazione chiavi, MTU per PPPoE, firewall aziendali capricciosi. Le risposte aiutano a spremere stabilità “anche sotto pioggia e vento”.

Quale MTU scegliere per OpenVPN su PPPoE?

Funziona spesso bene: tun-mtu 1500 di default, ma con mssfix 1360-1380 per stare sicuri nel percorso reale. Se noti blocchi di siti grandi o rotelle su piattaforme video, prova mssfix 1360 e se serve abbassa MTU tunnel a 1400-1420. Verifica che ICMP non sia filtrato a monte, altrimenti PMTU fallisce.

Conviene disabilitare reneg-sec in OpenVPN per stabilità?

Disabilitarlo del tutto è l’ultimo rimedio diagnostico. In produzione meglio allungare intervallo fino a 8-24 ore e pianificare rotazione in orari poco usati. Problemi in rotazione sono più spesso legati a rete e MTU che al reneg in sé. Se con intervallo allungato e mssfix giusto scompaiono disconnessioni hai trovato compromesso tra sicurezza e stabilità.

Sicurezza e privacy

Ogni configurazione per stabilità deve andare di pari passo con sicurezza. Non serve un tunnel "mai cadente" se è vulnerabile o bypassa regole rigide. Qui si parla di equilibrio e buon senso.

Il kill switch disconnette internet ad ogni "blink" del tunnel. È normale?

Per sicurezza rigida sì, ma è scomodo. Scegli una modalità "intelligente": lascia traffico NTP e captive portal, mantieni rete locale attiva e abilita auto-reconnect senza intervento utente. Così un breve "blink" non rompe tutta la sessione. E ricorda di controllare che DNS non fugga fuori tunnel se non serve.

L’offuscamento migliora sempre la stabilità?

No. L’offuscamento serve a superare censura o DPI, non per stabilità. Aggiunge latenza e carico. Se la rete non blocca il tuo protocollo, non complicare. Parti da trasporto e timer, poi MTU, infine offuscamento per "sbloccare" reti ostili. E tieni a mente: metodi nuovi funzionano meglio di vecchi, ma prima o poi vengono scoperti.

Scenari mobili

Su telefono tutto cambia veloce: handover, risparmio batterie, cambio Wi-Fi a LTE al volo. Perciò le impostazioni mobile sono più "nerve": battito breve, MTU ridotto, trasporto UDP e fiducia che l’app lavori in background.

Perché la VPN si interrompe passando da Wi-Fi a 5G e viceversa?

Cambiare interfaccia significa nuovo IP e potenzialmente uplink con timeout e MTU diversi. Se il protocollo non supporta roaming fluido o i timer sono troppo rilassati, il client perde connessione, il server non riesce a "riagganciarsi" e il tunnel cade. Soluzione: attiva MOBIKE per IKEv2, mantieni keepalive 20-25 s per WireGuard, usa 443/UDP, riduci MTU a 1380-1400 e consenti background senza limitazioni al client VPN. Così un corto blackout non diventa disconnessione vera e propria.