VPN non funziona? Analizziamo passo dopo passo: algoritmo sistematico di diagnosi 2026

Questa situazione la conosciamo fin troppo bene: premiamo “Connetti”, aspettiamo qualche secondo, la rotellina gira e... niente. Oppure la connessione parte, ma i siti non si aprono, RDP non si collega, il ping salta e Zoom va a scatti. Nervi tesi, scadenze da rispettare, utenti che chiamano. Niente panico. Scomporremo ogni problema VPN in modo sistematico, rapido e senza magie, seguendo un algoritmo chiaro.

Perché serve un approccio sistematico alla diagnosi VPN

Perché la ricerca casuale fa saltare le scadenze

La VPN è una pila con molti strati: rete del provider, NAT, DNS, crittografia, autenticazione, instradamento, firewall locale, policy di accesso. Se tocchi impostazioni a casaccio, o forse risolvi senza capire cosa, o peggiori la situazione. La strategia è semplice: dal semplice al complesso, dal livello più basso a quello più alto. Una sequenza chiara ti fa risparmiare ore e nervi.

I sintomi contano più delle supposizioni

Prima di tutto annotiamo i sintomi: non si connette proprio, si connette ma non c’è accesso alle risorse, velocità bassa, disconnessioni, funzionano solo alcuni servizi, strani problemi con DNS o IPv6. Ogni gruppo di sintomi indica un diverso punto da diagnosticare. Non curiamo tutto insieme, interveniamo miratamente.

Test minimo riproducibile

Dimentica un sacco di controlli paralleli. Costruiamo un test minimo: un server, un client, avvio manuale, comandi semplici. Il concetto è chiaro: meno variabili ci sono, più in fretta troviamo la causa. Poi allarghiamo il controllo, passo dopo passo.

Criteri chiari di successo

Definiamo metriche: la connessione si stabilisce in meno di 5 secondi, il ping alla risorsa interna è stabile sotto 50 ms, non ci sono perdite, MTU non frammenta i pacchetti, il DNS risponde entro 100 ms, la capacità non è inferiore al 30% della base. Quando i criteri sono chiari, capiamo cosa migliorare.

Passo 1. Controlli base sul dispositivo

Checklist rapida in 60 secondi

Una lista semplice salva un sacco di tempo. 1) Internet funziona senza VPN? 2) Ora di sistema e fuso orario sono corretti? Errori di orario bloccano TLS e IKE. 3) Altri client VPN sono chiusi? Conflitti di driver sono frequenti. 4) Antivirus e firewall non bloccano? Disattiva temporaneamente i filtri di rete. 5) Riavvio di adattatore e client. A volte è banale, ma risolve nel 20% dei casi.

Specificità OS: Windows, macOS, Linux, mobile

Windows: verifica i servizi «IKE and AuthIP IPsec Keying Modules», «IPsec Policy Agent». Riavvia Windows Filtering Platform per risolvere conflitti. macOS: disattiva Private Relay e riavvia i servizi di rete. Linux: controlla systemd-resolved e tabelle rotte con ip route. Android e iOS: rimuovi risparmi energetici sull’app VPN, disattiva modalità a basso consumo, spegni DNS privato se interferisce con la risoluzione.

Driver e aggiornamenti

Aggiorna i driver degli adattatori di rete, specialmente TAP/TUN per OpenVPN o tunnel WireGuard. Dopo grandi aggiornamenti del sistema operativo, alcuni driver possono rompersi o entrare in conflitto. Controlla che non ci siano residui di vecchi client VPN. Rimuovili completamente, riavvia, reinstalla la versione attuale del client.

Log all’avvio

Non ignorare log e codici errore. OpenVPN spesso indica chiaramente: AUTH_FAILED, TLS Error, Inactivity timeout. WireGuard è sintetico ma registra «Handshake did not complete». IKEv2/IPsec mostra il motivo durante la negoziazione SA. Prendi i log subito su avvio “pulito” — sono la tua torcia nella stanza buia.

Passo 2. Internet e DNS: fondamenta di stabilità

Controlliamo internet senza VPN

La base. Ping a 1.1.1.1 o 8.8.8.8, test traceroute. Se la rete base non funziona, la VPN non salverà. Le reti mobili 5G a volte sono IPv6-only con CLAT. Questo è importante: alcune VPN impostate su IPv4 restano bloccate. Problemi di rete? Prima contatta il provider o cambia linea.

DNS prima e dopo VPN

Prima della VPN i domini si risolvono correttamente e velocemente? Dopo la VPN, quali resolver usi — aziendali o pubblici? Con split-tunnel e DNS aziendale accessibile solo nel tunnel, il resolver esterno non trova il dominio interno — normale. Configura DNS basato su policy: tunnel interno per domini aziendali, resolver pubblico per tutto il resto. Nel 2026 molti client supportano DNS intelligente tramite liste di domini.

DoH, DoQ e resolver delle app

Browser e app usano DoH e DoQ propri. Firefox, Chrome, Edge possono ignorare il DNS di sistema. Risultato: l’app risolve fuori bypassando il resolver aziendale e la risorsa “sparisce”. Disattiva DoH nelle app o abilita policy Enterprise. Su mobile verifica DNS privato. Funziona davvero.

Captive portal e proxy

I Wi-Fi pubblici spesso hanno captive portal. Connetti senza VPN, apri qualsiasi sito http e fai login. Se usi proxy con autenticazione, assicurati che il client VPN ne sia a conoscenza o li escluda. Spesso basta disattivare temporaneamente la VPN, passare il portal, riattivare.

Passo 3. Autenticazione e handshake: protocolli sotto la lente

WireGuard: minimalismo e precisione

WireGuard è semplice e veloce, ma attento ai dettagli: chiavi, endpoint, porte, AllowedIPs. Problemi frequenti: chiave pubblica errata, IP scaduti o non ammessi in AllowedIPs, blocco porta UDP (solitamente 51820), MTU non coerente. Verifica se vedi handshake—sul server appaiono handshake nuovi per il peer? Se no, porta chiusa o NAT&DPI bloccano. Passa a porta 443/UDP o 443/TCP via offuscamento se possibile. Nel 2026 molti client supportano offuscamento e mascheramento QUIC.

OpenVPN: flessibilità e dettagli

Errori di autenticazione: controlla certificato, scadenza, orario client. Errori TLS spesso causati da cifrature incompatibili o DPI che tagliano TLS. Prova TCP 443, abilita tls-crypt o tls-crypt-v2, configura verify-x509-name. Per canali instabili usa keepalive 10 60 e reneg-sec 0 in ambienti stabili. Non dimenticare mssfix e fragment se MTU frantuma traffico. E no, non usare L2TP senza IPsec — è una porta senza serratura.

IKEv2/IPsec: affidabilità e precisione

Il re è avere policy corrette e porte UDP 500 e 4500 aperte. Con NAT, verifica NAT-T. Problemi frequenti per cifrature errate, specialmente su client datati. Nel 2026 consigliamo AES-GCM, ChaCha20-Poly1305, PFS con Curve25519. Certificati: controlla catena, accesso CRL/OCSP esterno, altrimenti la verifica cade se il traffico in uscita è bloccato. Abilita log strongSwan/charon a livello medio, cerca frasi come NO_PROPOSAL_CHOSEN o AUTHENTICATION_FAILED — indicano chiaramente il problema.

Transizione verso settaggi ibridi post-quantum

Si vedono sempre più test di schemi ibridi: Kyber + X25519 in TLS 1.3 e estensioni IKEv2. Se abilitati sul server e il client è vecchio, handshake fallisce. Verifica supporto da entrambe le parti. Per ora è opzionale, ma è una tendenza forte, e i client aziendali già usano KEM ibridi.

Passo 4. Tunnel attivo ma accesso non funziona

Rotte e split-tunnel

Classico. Tunnel c’è, ma risorse non raggiungibili — controlla tabella rotte. Quale percorso per la subnet target? Priorità tra rete locale e VPN? Con split-tunnel assicurati che le subnet necessarie siano incluse. Con full-tunnel verifica che non ci siano sovrapposizioni di default gateway. Su Windows usa metriche, su Linux priorità e policy routing.

Sovrapposizione subnet e conflitti

Se router casalingo assegna 192.168.1.0/24 e ufficio usa la stessa subnet, l’instradamento si rompe. Soluzione: cambia subnet casalinga, usa rotte più specifiche, proxy per servizi singoli o modifica indirizzi in ufficio. Nel 2026 molti client supportano VPN per app singole: a volte conviene far passare solo un’app tramite tunnel invece di lottare con conflitti.

IPv6: colpevole nascosto

Risorsa disponibile solo in IPv6? Il tuo VPN trasporta solo IPv4? Allora metà del traffico va fuori tunnel. Attiva IPv6 nel tunnel o disattiva IPv6 sul client se la policy lo permette. Considera 464XLAT sul mobile: alcuni provider danno solo IPv6 e serve CLAT corretto sul client.

Firewall e policy di accesso

Firewall locale e aziendale possono bloccare ICMP, SMB, RDP, ICMPv6 o perfino DNS. Controlla policy su server VPN e NAC. A volte il kill switch blocca tutto fuori tunnel, l’app non raggiunge API esterne — sembra VPN non funzioni, ma è protezione severa. Configura eccezioni con attenzione.

Passo 5. VPN lenta, disconnessioni, salti — cosa fare

MTU e MSS: piccola regolazione, grande effetto

Se i siti “girano” ma non si caricano, sospetta MTU. Un collo di bottiglia spezza pacchetti grandi. Soluzione: misura Path MTU, limita MSS. Per OpenVPN tipici mssfix 1360–1400, per WireGuard MTU 1280–1420. PPPoE riduce MTU a 1492 o meno. La configurazione corretta risolve metà dei blocchi misteriosi.

Perdite e jitter

Usa mtr o ping con intervallo ampio per vedere stabilità. Se perdite ultime miglia, TCP 443 potrebbe essere più stabile di UDP. Se DPI blocca UDP, passa a TCP 443 con offuscamento. Per realtime (Zoom, Teams) invece meglio UDP pulito, altrimenti ritardi e robot invece di voci.

Carico CPU e crittografia

La crittografia richiede CPU. Su portatili datati senza AES-NI la banda cala molto. Controlla uso CPU. Su chip ARM mobile attiva ChaCha20-Poly1305 — vola. Nei server usa offload CPU, bilanciamento e verifica librerie crittografiche aggiornate. Nel 2026 quasi tutti client sfruttano multithreading, ma un controllo manuale non guasta.

Server e bilanciamento

Controlla risorse server: CPU, RAM, code di rete. I log mostrano picchi. Attiva health-check, monitoraggio connessioni, latenza, fallimenti handshake. Distribuire punti presenza geograficamente riduce RTT. A volte basta uno split regionale con session sticky da bilanciatore.

Passo 6. Porte, DPI e offuscamento

Matrice porte e protocolli

Spesso bloccano UDP 1194, 1701, 500, 4500. 51820 a volte passa, a volte no. TCP 443 quasi sempre libero. QUIC 443/UDP in alcune reti filtra selettivamente. Strategia: se porta standard non va, maschera il traffico web: TLS 1.3, TCP 443, SNI sembrano normali siti senza metadati.

Offuscamento e mimica QUIC

Nel 2026 molti client mascherano come HTTP/3 o HTTPS normale, con ECH (Encrypted Client Hello) per nascondere SNI. Aumenta molto le chance contro DPI. Per OpenVPN usa tls-crypt-v2, XOR patch o plugin di offuscamento; per WireGuard wrapper UDP su TCP o trasporti tipo QUIC. Importante: non violare policy aziendali o leggi locali.

Proxy sopra VPN e VPN sopra proxy

A volte è più semplice far passare VPN tramite proxy HTTP aziendale. Supporto CONNECT aiuta il passaggio. Inversamente, app attraverso SOCKS sopra VPN se rete aziendale filtra i protocolli avanzati. Ma attenzione: doppie incapsulazioni aumentano latenza e rompono MTU.

Analisi blocchi

Se handshake non arriva, verifica alla frontiera: tcpdump o Wireshark su server e porta. Vedi SYN e risposta? Se client invia e server non vede, c’è blocco. Controlla dispositivi intermedi, NAT, security group, WAF, regole aziendali.

Passo 7. Specificità 2026: IPv6-only, NAT e Zero Trust

IPv6-only e 464XLAT

Sempre più operatori mobili offrono solo IPv6. Se VPN non supporta NAT64/DNS64, alcune risorse diventano “invisibili”. Soluzione: attiva IPv6 nel tunnel o configura CLAT correttamente. WireGuard funziona già molto bene su IPv6; OpenVPN e IPsec pure, basta controllare rotte e policy.

CGNAT e connessioni in ingresso

Dietro CGNAT non apri porte. Se ti serve accesso al client interno (es. server locale), usa tunnel inversi, servizi relay o reti overlay con peer-relay. Alternativa: gateway ZTNA aziendali che aprono sessione in uscita dal client e pubblicano la risorsa in modo sicuro.

Ibridi post-quantum in produzione

Grandi aziende testano già ibridi PQC in produzione. Mix Kyber con X25519 in TLS 1.3 è norma per nodi critici. Se client è vecchio, fallisce silenziosamente. Regola d’oro: inventario versioni, aggiornamenti a gruppi, canali test, retrocompatibilità. Solo dopo rollout massivo.

Zero Trust, SASE e verifica device

La VPN ora non è più sola: ZTNA verifica dispositivo, patch, stato EDR, conformità policy e solo poi concede accesso. Se connesso ma zero accessi, forse postura check è fallito. Assicurati che agent MDM/EDR funzioni, antivirus attivo, disco cifrato, schermo bloccato da timer — a volte sono le condizioni per l’accesso.

Kit di strumenti: cosa installare subito

Utility di rete essenziali

- ping, traceroute, mtr — controlli base di perdita e latenza. - iperf3 — misura reale della banda con e senza VPN. - nslookup, dig — analisi DNS prima e dopo tunnel. - curl -v e curl --http3 — test TLS, HTTP/3 e proxy. - openssl s_client — dettagli handshake TLS. - tcpdump, Wireshark — artiglieria pesante per vedere i pacchetti.

Comandi client

WireGuard: wg show, controlla ultimo handshake e statistiche. OpenVPN: file status e log con verb 4–6, openvpn --status. IPsec/strongSwan: ipsec statusall, journalctl -u strongswan, charon.log. Windows: Get-VpnConnection, Test-NetConnection, log rasdial. Linux: ip a, ip r, resolvectl status. macOS: scutil --dns, networksetup.

Log che non fanno vergognare

Prima di inviare log in chat condivise oscura IP pubblici e segreti. Non eliminare errori critici. Anonimizzazione chiara e ordinata è segno di professionalità del team. Tieni un modello “cosa raccogliere” — ti farà risparmiare ore.

Automazione e checklist

Crea uno script di diagnostica: controlla tempo, DNS, MTU, porte aperte, versione client. Su Windows modulo PowerShell, su macOS/Linux bash. Rapporto automatico con stato semplice aiuta anche utenti meno esperti a fornire dati subito utili.

Algoritmo di diagnosi: scenario passo dopo passo

Fase A: raccogliamo il quadro

Cosa non funziona esattamente? Sempre o solo tra 18:00 e 20:00? Solo in ufficio, a casa o solo su 5G? Quale OS, versione client, protocollo? Questo riduce le ipotesi del 70%. Chiedi all’utente di ripetere il problema segnando orario esatto — così confrontiamo con i log.

Fase B: linea base

Verifica internet, DNS, ora, altri VPN, antivirus. Se qui trovi problemi, sistemali prima. Niente esoterismo. In 3 casi su 10 basta questo.

Fase C: handshake

Guarda log e connessione su server. Richiesta visibile? Risposta presente? Errori TLS o IKE indicano con precisione il conflitto. Se porta è bloccata, cambia trasporto, porta, attiva offuscamento. Procedi con ordine, registra risultati passo passo.

Fase D: traffico e rotte

Tunnel c’è — controlla rotte, DNS nel tunnel, accesso a subnet specifiche. Verifica MTU e MSS, elimina fuga IPv6. Con split-tunnel valida liste domini e subnet. Con full-tunnel la rotta default deve passare per VPN, i resolver essere interni.

Cause comuni e soluzioni rapide

Ora sbagliata

Tempo sfasato di qualche minuto è già un problema. OCSP e TLS dicono “no”. Soluzione: sincronizza con NTP e impedisci a app di modificare orario. Sembra banale, ma i casi reali sono tanti.

MTU in conflitto con la realtà

Blocchi durante login o risposte grandi? Controlla MTU. Metti valori ragionevoli e MSS corretto. “Click” e il sito prende vita subito — effetto quasi magico.

Porte bloccate selettivamente

UDP passa poco, TCP 443 è veloce e stabile. Non esitare a cambiare. Combo TCP 443 con tls-crypt-v2 e ECH funziona anche su reti difficili.

DNS fa di testa sua

Browser usa DoH e non vede dominio interno. Politiche OS o MDM risolvono. Aggiorna istruzioni per utenti, non sono maghi.

Mini-casi pratici

Caso 1: “Si connette ma 1C è irraggiungibile”

Sintomo: RDP funziona, siti interni aperti, 1C no. Diagnosi: split-tunnel, rotta per subnet 1C assente. Aggiunta /24 in lista, riavvio client — funziona. Risolto in 12 minuti.

Caso 2: “Zoom va a scatti, ping stabile”

Sintomo: perdite basse ma jitter alto. Diagnosi: tunnel su TCP, congestione code. Soluzione: escludere Zoom da tunnel split o passare tunnel a UDP con MTU adeguato. Immediato miglioramento.

Caso 3: “WireGuard non vede server, OpenVPN sì”

Sintomo: WG non funziona, OpenVPN TCP 443 sì. Diagnosi: blocco UDP 51820 e filtro QUIC selettivo. Soluzione: WireGuard su TCP 443 mimando HTTPS. Handshake stabile, performance medie ma accettabili.

Caso 4: “Dopo update macOS accesso intranet perso”

Sintomo: tunnel attivo, siti esterni accessibili, portale interno 404 o blocco. Diagnosi: DoH nel browser bypassa resolver aziendale. Soluzione: policy MDM per disattivare DoH e forzare resolver tunnel. Riattivato in 5 minuti.

Prevenzione e supporto: come tenere tutto operativo

Standard di configurazione

Template per tutte le occasioni: OpenVPN con tls-crypt-v2, MTU e mssfix; WireGuard con AllowedIPs chiari e trasporto fallback; IKEv2 con cifrature moderne e NAT-T. Tieni versioni, changelog, istruzioni. Noioso, ma salva.

Monitoraggio e alert

Raccogli metriche: connessioni, tempo handshake, RTT, errori autenticazione, carico, drop pacchetti. Alert arriva prima della chiamata utenti — reputazione del team cresce. Nel 2026 per cluster VPN il monitoraggio è d’obbligo, non lusso.

Formazione utenti

Fornisci checklist breve: internet, ora, captive portal, riavvio client, screenshot errore. 2 minuti e capisci subito la direzione. Meno caos, ticket più precisi.

Zero Trust e segmentazione

Non far passare tutto da un solo tunnel. Dagli accesso solo per compiti. ZTNA, segmentazione, posture device sono non parole di moda ma modo reale per ridurre rischi e semplificare diagnosi. Regole chiare rendono gli incidenti rari e comprensibili.

Checklist sul frigo: breve e chiaro

Sequenza “dal basso verso l’alto”

1) Internet e orario. 2) DNS. 3) Porte e handshake. 4) Rotte e subnet. 5) MTU e performance. 6) Policy accesso e ZTNA. 7) Specificità 2026: IPv6-only, ECH, offuscamento.

Regola di un’ipotesi alla volta

Cambia un parametro per volta e registra il risultato. Correzioni casuali danno risultati casuali. Testa lucida è metà del lavoro.

I log non sono “per forma”

Dettaglio medio e timestamp bastano. Non inventare, guarda i fatti. L’errore indica dove scavare, non ignorarlo.

Non temere soluzioni temporanee

Serve una chiamata ora? Passa tunnel su TCP 443, disattiva offuscamento, semplifica rotte — poi torni all’ideale. La vita non è laboratorio, a volte serve effetto rapido.

FAQ: domande frequenti e risposte sincere

Perché VPN si connette ma siti non si aprono?

Spesso è questione di rotte, DNS o MTU. Controlla resolver usato, percorso verso subnet risorsa e riduci MSS. In 6 casi su 10 basta questo.

Come capire se la rete blocca il protocollo?

Cambia porta a 443, protocollo a TCP, attiva offuscamento. Se si connette subito, la rete ha DPI o ACL rigido. Decidi cosa conta di più: stabilità o velocità.

Conviene abilitare IPv6 nel profilo VPN?

Sì, se la tua infrastruttura è pronta. Nel 2026 IPv6-only è sempre più diffuso tra i provider. IPv6 nel tunnel riduce molti guasti strani.

Perché WireGuard è più veloce ma a volte non si connette?

Per UDP e blocchi di rete. Soluzione: trasporto alternativo TCP 443, mimica QUIC, offuscamento. Se non basta, passa temporaneamente a OpenVPN TCP 443.

Si può risolvere tutto con una configurazione “veloce”?

Purtroppo no. Reti diverse, policy diverse, minacce diverse. Ma un buon template con trasporti fallback, profilo MTU e cifrature aggiornate copre l’80% dei casi.

Come capire se non è la VPN ma l’app che causa problemi?

Se ping e accesso subnet sono stabili, DNS risolve, ma solo un’app si rompe, è lei il problema. Controlla proxy, DoH, requisiti porte e protocolli dell’app.

Serve già oggi un ibrido post-quantum?

Per sistemi critici sì, con cautela. Verifica compatibilità client, fai pilota e poi rollout. Per usi quotidiani ancora esagerato, ma è una tendenza chiara.