VPN sotto la lente: come viaggiano davvero i pacchetti nel tunnel e dove si perdono i byte

Cosa fa davvero il VPN con i pacchetti

Percorso di un pacchetto IP senza VPN

Iniziamo dal semplice. Immagina un normale pacchetto IP dal tuo laptop al server. Ottiene l'indirizzo MAC locale del gateway, passa al router del provider, fa qualche salto e arriva tranquillamente a destinazione. Zero magie, solo routing puro. Niente sovrapposizioni inutili, solo l'intestazione originale IPv4 o IPv6, più l'intestazione di trasporto TCP o UDP e il payload. Elegante e semplice.

Ora guardalo dal punto di vista di uno switch: il frame entra, la tabella L2 indica la porta, il frame esce. A livello L3, il router consulta la tabella di routing, aggiorna il TTL, eventualmente frammenta se l'MTU è troppo basso. Fine. Così funziona la tua connessione finché non ti serve un canale protetto o l'accesso a una rete remota. In quel momento entra in gioco il VPN e comincia a rielaborare quel pacchetto IP come una matrioska.

Percorso di un pacchetto IP attraverso il tunnel

Con il VPN la cosa si fa più interessante. Il tuo pacchetto IP originale non va più direttamente su Internet. Il client lo incapsula in un nuovo pacchetto: aggiunge un'intestazione IP esterna (verso il server VPN), sopra di essa UDP o ESP e talvolta una intestazione di protocollo tunnel aggiuntiva. Il pacchetto interno diventa il "payload" cifrato e nascosto, come una lettera in una busta infilata in un'altra busta più opaca.

All'uscita, il server VPN rimuove lo strato esterno, verifica l'autenticazione, decifra e rilascia dal tunnel il pacchetto IP interno originale. Questo ha una seconda chance per viaggiare su Internet in modo convenzionale, ma questa volta a nome del nodo lato server o tramite routing verso la rete aziendale. È costoso? Sì. Ma è sicuro e gestibile, se calcoli bene l'overhead e l'MTU.

Trasporto vs tunnel: qual è il confine

Ricorda questa semplice regola: il trasporto è il modo in cui consegniamo i pacchetti (UDP, TCP, QUIC), mentre il tunnel è come li incapsuliamo e dove li apriremo. Alcuni VPN usano UDP come trasporto (WireGuard, OpenVPN-UDP), altri un protocollo IP di livello proprio (ESP in IPsec). Ma fondamentalmente fanno la stessa cosa: incapsulano il tuo pacchetto IP originale in uno esterno.

Il nostro focus è proprio questo confine tecnico: tra payload interno e trasporto esterno. Qui nasce l'overhead. Qui si rompe il PMTUD. Qui si genera latenza a causa della crittografia. Analizzeremo proprio questo confine, strato dopo strato, per capire perché i pacchetti si frammentano all'improvviso e le connessioni TCP rallentano, anche con 1 Gbps di abbonamento.

Dove si nasconde la crittografia

La crittografia si trova tra il pacchetto interno e il trasporto esterno. In IPsec ESP, c'è un ciphertext sopra al pacchetto interno più i campi ESP e ICV. In WireGuard, si cifra la parte utile del Data Message, mentre intestazioni UDP e IP esterne restano visibili. In OpenVPN, si cifra il contenuto del protocollo proprio sopra UDP o TCP, spesso con HMAC e un TLS opzionale sul canale di controllo.

Un dettaglio importante: la crittografia impone un allineamento, aggiunge tag di autenticità (di solito 16 byte) e può richiedere IV o nonce. Questi byte non spariscono da nessuna parte. Aumentano la dimensione di ogni pacchetto. Quindi, bisogna ridurre l'MTU sull'interfaccia tunnel o limitare l'MSS delle connessioni TCP interne, per evitare che i pacchetti si frammentino e vadano persi nel continuo gioco della frammentazione.

Incapsulamento a strati: le matrioske annidate

IP esterno e interno

Lo scenario minimo è questo: il pacchetto IP interno viene generato dall'applicazione, poi il client VPN lo mette dentro un contenitore esterno. Questo contenitore esterno è una nuova intestazione IP indirizzata al server del tunnel. Ora abbiamo quindi due IP: quello interno indica la destinazione nella logica protetta, quello esterno come raggiungere il concentratore VPN. In Wireshark si vedono due livelli IP, ma l'interno di solito è nascosto finché non decifri il traffico sul nodo finale.

Questo doppio IP è alla base dei termini "tunnel mode" e "transport mode" in IPsec. In tunnel mode abbiamo una nuova intestazione IP completa e un interno completamente nascosto. In transport mode si cifra solo il payload, mentre l'IP esterno è quello originale. Per routing aziendale e accesso remoto, si usa più spesso il tunnel mode.

UDP o TCP come busta del tunnel

Spesso il tunnel usa UDP come trasporto. Perché? È più semplice e stabile per superare il NAT, ha meno overhead per il controllo del carico e ritardi minori in caso di perdita. WireGuard segue questa strada: UDP sopra IP esterno, con pacchetto cifrato all'interno. OpenVPN in modalità UDP è simile. OpenVPN-TCP costruisce invece un "VPN su TCP", utile in proxy rigidi, ma soggetto al fenomeno TCP-over-TCP meltdown — doppie logiche di controllo congestionale che si scontrano e causano ritardi.

Quando si usa ESP (protocollo 50 a livello IP), UDP esterno potrebbe anche mancare. Ma nella pratica troviamo NAT-T: ESP confinato in UDP sulla porta 4500 per ingannare il NAT. Questo aggiunge 12 byte (8 UDP più 4 per il Non-ESP Marker), ma passa stabile su router domestici e dispositivi provider.

Identificazione del protocollo: ESP, GRE, L2TP

A livello esterno il tunnel si riconosce dai protocolli usati. ESP è protocollo 50, AH 51, GRE 47, L2TP porta UDP 1701, WireGuard di solito UDP 51820 (ma spesso si cambia per mascheramento), OpenVPN porta UDP 1194 di default, TCP 443 per i più conservativi. Questi numeri sono essenziali per filtri tcpdump, Wireshark e policy firewall.

La marcatura aiuta a capire cosa si vede: esp significa IPsec, gre che sopra c’è un altro IP o protocollo L3, udp.port==51820 indica probabile WireGuard. Curiosità: alcuni provider nel 2026 intensificano il DPI su UDP con pattern anomali, perciò VPN basate su QUIC guadagnano terreno, e alcune soluzioni incapsulano il tunnel nel traffico HTTP/3. Ma questo è già a livello di trasporto.

Frammentazione e ricomposizione

L'incapsulamento aumenta la dimensione del pacchetto. Se supera l'MTU del link, il router frammenta o manda un ICMP «Fragmentation Needed» se il flag DF è attivo. Nel VPN spesso vediamo frammentazioni invisibili all'occhio e una perdita pesante di prestazioni. Ogni frammento è lavoro extra, rischio di timeout e ritrasmissioni TCP.

La strategia giusta è stimare la dimensione finale e ridurre l'MTU sul tunnel. Oppure usare il MSS clamping per TCP (riducendo la dimensione del segmento affinché rientri nell’MTU con tutte le intestazioni). Nel 2026 la maggior parte delle reti provider usa ancora MTU 1500, quindi calcolare un MSS 1360–1380 per IPsec NAT-T non è snobismo, ma una necessità pratica.

Intestazioni e loro struttura: dai bit al senso

IPv4 e IPv6: campi critici per VPN

In IPv4 ci interessano: Total Length, Identification, Flags (DF, MF), Fragment Offset, TTL, Protocol, Header Checksum. DF significa «non frammentare» e ICMP Type 3 Code 4 indica che l’MTU è inferiore. IPv6 ha meccanismi diversi: niente checksum nell’intestazione, frammentazione spostata al mittente, routers non frammentano mai. Perciò PMTUD è indispensabile in IPv6, altrimenti il tunnel "si blocca" con pacchetti grandi.

Un altro dettaglio sono Traffic Class e Flow Label, che influiscono su QoS e su reti con priorità. Nel tunnel VPN l’IP esterno può trasportare un QoS, l’interno un altro: da qui l’importanza di copiare DSCP. Molti amministratori nel 2026 ormai copiano esplicitamente DSCP dall’IP interno a quello esterno in IPsec per mantenere priorità su voce e video.

UDP e TCP: numeri di servizio ed effetti nascosti

L’intestazione UDP è semplice: Source Port, Destination Port, Length, Checksum — 8 byte. Minimo overhead, ideale per tunnel. TCP è più complesso: 20 byte base più opzioni (MSS, SACK, Timestamps). Il TCP interno con MSS 1460 funziona bene su Ethernet puro, ma nel tunnel è stretto. Ecco perché usiamo MSS Clamping — riduciamo l’MSS nei pacchetti SYN.

Il TCP su TCP è un problema noto: il TCP esterno (ad esempio OpenVPN su TCP) e quello interno reagiscono simultaneamente a perdite e ritardi. Risultato: ritrasmissioni doppie, controllo congestionale duplicato, latenza e instabilità. Non è una leggenda. Meglio evitare TCP sopra TCP salvo casi stretti di necessità.

ESP: SPI, Sequence, IV, Padding, ICV

Un pacchetto ESP include l’intestazione ESP (SPI 4 byte, Sequence Number 4 byte), dati cifrati (IP interno e trasporto), trailer ESP (Padding, Pad Length, Next Header) e dati autenticativi ESP (ICV, di solito 16 byte per GCM). Con AES-GCM si vede spesso IV esplicito di 8 byte e tag autenticativo di 16 byte. Inoltre NAT-T aggiunge UDP 8 byte e Non-ESP Marker 4 byte, aumentando visibilmente la dimensione.

In modalità tunnel IPsec aggiunge un’altra intestazione IP esterna (20 byte per IPv4, 40 per IPv6). Il padding dipende dall’allineamento del cifrario blocco e può consumare qualche byte per pacchetto. Conclusione: ESP ha costanti stabili e parte variabile. Nel calcolo pratico consideriamo circa 50–70 byte overhead IPv4 con NAT-T, e 70–90 byte su IPv6 per non sbagliare.

OpenVPN e WireGuard: differenze a livello di pacchetto

OpenVPN su UDP aggiunge una piccola intestazione, HMAC e a seconda della configurazione IV/nonce. L’overhead totale sta intorno a 36–60 byte più IP esterno e UDP. In modalità TCP aggiunge intestazione TCP e TLS sul canale controllo, migliorando stabilità in reti complesse ma peggiorando latenza e throughput in caso di perdita.

WireGuard è minimalista. Data Message contiene intestazione di servizio (destinatario, contatore) e payload cifrato con tag Poly1305 di 16 byte. In pratica si calcolano circa 32 byte di intestazione WG sopra 8 byte UDP e 20/40 byte IP. Quindi 60–80 byte per pacchetto è la stima tipica. Non perfetto, ma prevedibile e veloce, soprattutto con hardware che accelera ChaCha20-Poly1305.

Overhead spiegato semplice: quanto pesa un tunnel

Formula base ed esempi

L’overhead è la somma di tutte le intestazioni esterne e byte di servizio crittografici aggiunti al pacchetto interno. Formula per stimare: Overhead = IP esterno + trasporto esterno (UDP/TCP) + intestazione tunnel (ESP, WG, OpenVPN, GRE...) + tag crittografico + padding/IV/nonce + allineamento. Sembra complicato, ma è semplice aritmetica.

Esempio: segmento TCP interno con payload 1400 byte. Tunnel IPsec NAT-T con AES-GCM: IPv4 esterno 20 byte, UDP 8, Non-ESP Marker 4, intestazione ESP 8, IV 8, ICV 16, più padding 2–6 byte. In totale ~66–70 byte. Quindi pacchetto finale circa 1470 byte. Su link MTU 1500 ci entra, ma col minimo margine. Qualsiasi opzione TCP o IPv6 potrebbe far scattare la frammentazione.

IPsec ESP: modalità trasporto e tunnel, NAT-T e calcolo

Modalità trasporto IPsec non aggiunge IP esterno, risparmiando 20/40 byte. Ma per accesso remoto serve spesso modalità tunnel. Qui aggiunge IP esterno, e l’overhead si fa sentire: IPv4 ESP senza NAT-T di solito 42–60 byte, con NAT-T 54–74 byte, a seconda campi e padding. Su IPv6 si aggiungono altri 20 byte per intestazione più lunga.

Regola pratica: se usi IPsec con NAT-T, imposta MTU tunnel 1400–1420 e MSS clamp 1360–1380. Questi valori non sono casuali, riflettono intestazioni tipiche e lasciano margine per evitare frammentazioni. Testa sempre con ping -M do usando pacchetti grandi, per verificare che PMTUD funzioni anche con firewall complicati.

WireGuard, OpenVPN UDP e TCP: riferimenti in byte

WireGuard su IPv4 ha circa 60 byte di overhead, su IPv6 80 byte. Raccomandazione standard: MTU 1420 su interfaccia wg0 — il giusto equilibrio. Per OpenVPN-UDP dipende da cifratura e HMAC: 50–80 byte sopra IP/UDP sono comuni. Così MTU 1400–1450 e MSS clamp 1360–1420 risolvono il 90% dei problemi.

OpenVPN-TCP è un’altra storia. Oltre a 20 byte TCP (senza opzioni) per trasporto esterno, si sommano le logiche di controllo. In canali stretti e rumorosi, TCP su TCP soffre molto. Si può alleviare con TCP Fast Open o settaggi precisi di buffer, ma in generale meglio restare su UDP e superare proxy con altri strumenti come QUIC.

GRE, L2TP, VXLAN: confronto rapido

GRE aggiunge almeno 4 byte di intestazione base, spesso anche Key e Checksum, totale 8–12 byte più IP esterno. Con IP interno incapsulato arriviamo facilmente a 24–28 byte sopra l’IP esterno. L2TPv2 gira su UDP (8 byte) e aggiunge 6–12 byte intestazione L2TP più PPP, per un totale di 14–24 byte prima della cifratura o sopra IPsec.

VXLAN è pensato per incapsulamento L2 nei data center: UDP 8 + VXLAN 8 + IP esterno e MAC livello link. Nel contesto VPN è meno comune, ma il principio resta lo stesso: ogni byte di intestazione riduce spazio payload. Più gusci annidati, più importante è settare bene MTU e vietare frammentazioni indesiderate.

MTU, MSS e velocità reale

Come calcolare l’MTU per il tuo tunnel

L’algoritmo è semplice. 1) Calcola l’overhead totale della tua pila (ad esempio 68 byte per IPsec NAT-T IPv4). 2) Sottrai da 1500 se l’underlay è Ethernet senza jumbo frame. 3) Aggiungi un margine di 10–20 byte per variazioni (opzioni TCP, campi imprevisti). 4) Imposta l’MTU calcolato sull’interfaccia tunnel e verifica con ping con DF aumentando gradualmente la dimensione.

Esempio: WireGuard su router domestico. Stimiamo overhead 60–64 byte per IPv4. 1500−64=1436. Arrotondiamo per sicurezza a 1420 (consiglio comune) per garantire margine. Poi settiamo MSS clamp 1360–1380 e verifichiamo download e VoIP. Se spariscono "blocchi" e pacchetti frammentati, siamo a posto.

MSS Clamping: modo rapido per domare TCP

MSS (Maximum Segment Size) è la quantità massima di dati TCP in un segmento. Se il tunnel riduce MTU, bisogna limare MSS per evitare frammentazioni. Si fa modificando MSS nei pacchetti SYN delle connessioni TCP al confine. Oggi quasi tutti i gateway moderni e anche router SOHO nel 2026 lo fanno con pochi click.

In pratica: per MTU 1420 usiamo MSS 1360. Anche per MTU 1400 MSS 1360 va bene, considerando opzioni TCP imprevedibili. Controlla con tcpdump che il SYN abbia MSS corretto. Se vedi ritrasmissioni strane e picchi di RTT, abbassa MSS di altri 10–20 byte e ritesta.

Jumbo frame, PMTUD e flag DF

I jumbo frame (MTU > 1500) semplificano molto, ma non sono sempre disponibili. Nei data center sì, su Internet raramente. PMTUD teoricamente funziona perfettamente: il mittente si adatta al link più stretto. In pratica ICMP viene spesso bloccato e il mittente non capisce che il pacchetto è troppo grande. Da qui connessioni "appese" e rallentamenti misteriosi.

Se controlli entrambi gli endpoint, attiva PMTUD e lascia passare ICMP Type 3 Code 4. Se no, prendi il controllo: MTU conservativo, MSS clamp e test ping con DF chiaro. È noioso, certo, ma funziona e fa risparmiare ore di debug.

Preset pratici per il 2026

Il mercato si è consolidato in poche configurazioni: WireGuard IPv4 — MTU 1420, MSS 1360; IPsec NAT-T IPv4 — MTU 1400–1420, MSS 1360–1380; OpenVPN-UDP — MTU 1400–1450, MSS 1360–1420; IPv6 sulla stessa pila sottrae altri 20 byte. E non dimenticare il jitter: un jitter basso e stabile è spesso più importante di un aumento MTU di 20–30 byte.

Nel 2026 molti provider applicano QoS Per-Hop Behavior su dorsali e VPN aziendali copiano DSCP dall’IP interno all’esterno. Se la tua voce è migliorata dopo questa copia, non sorprenderti: i pacchetti hanno finalmente la priorità meritata.

Pratica: catture traffico e analisi con Wireshark

Filtri per tcpdump e Wireshark

Serve un filtro rapido? Per IPsec: esp o udp port 4500 (NAT-T), più isakmp su udp 500 per IKEv2. Per WireGuard: udp port 51820 (o custom). Per OpenVPN-UDP: udp port 1194. Per L2TP: udp port 1701. Per GRE: ip proto 47. Localmente, filtri host per IP server VPN per non catturare troppo traffico.

Ricetta: sul client tcpdump -ni eth0 udp port 51820 e host X.X.X.X — mostra solo WireGuard verso nodo specifico. Sul server utile monitorare interfacce esterne per perdite e interfaccia tunnel interna (wg0, tun0, ipsecX) per confrontare direzioni. Differenza nei contatori indica problemi: pacchetti persi o PMTUD fallito.

Leggiamo i campi dei pacchetti a mano

In Wireshark espandi pacchetto ESP. Vedi SPI e Sequence? SPI indica a quale SA appartiene il pacchetto. Sequence aumenta ad ogni pacchetto, utile per perdita e duplicati. In WireGuard guarda il Counter — contatore monotono che protegge da replay e ordina pacchetti. OpenVPN ha intestazione più semplice ma mostra Key ID e tipo messaggio.

Guarda IP esterno: TTL, flag DF, dimensione. IP interno è nascosto, ma nei nodi terminali vedrai la decodifica sull’interfaccia tunnel. Se vedi frammentazione esterna, cerca chi rompe l’MTU. Se contatori errori ICV crescono, verifica chiavi, desincronizzazioni o corruzioni di percorso. Logica semplice ma salva ore.

Debug MTU e frammenti: trucchi rapidi

Comando ping -M do -s 1472 8.8.8.8 (Linux) aiuta a trovare dimensione max senza frammentazione su link MTU 1500 (1472 payload + 28 IP+ICMP). Sul tunnel controlla dentro con ping tra indirizzi interni. Se perdi pacchetti grandi, abbassa MTU o MSS. Semplice ed efficace.

Altro trucco: abilita logging "Fragmentation needed" su router o firewall di confine. Se vedi picchi, PMTUD è bloccato. Allenta temporaneamente con MSS clamp TCP e poi trova dove si perdono ICMP. A volte è un ACL dimenticato, clonato da anni e ora causa problemi.

Dump sicuri e mascheramento dati sensibili

Fai dump su interfaccia esterna se vuoi nascondere IP interni e porte di app. Il traffico esterno è cifrato, quindi contenuto nascosto. Attenzione: rimangono visibili metadati — chi comunica con chi e quando. Se condividi con terzi, taglia pcap per indirizzi e tempo e usa anonimizzazione Wireshark (Replace MAC/IP).

Nel 2026 in molte aziende politiche "privacy by design" sono la norma per debug. Conserva dump poco tempo, cifra archivi, cancella chiavi dopo risoluzione incidente. Scrivi un README con filtri, versione client, MTU. Tra un mese ti ringrazierai da solo.

Crittografia e sicurezza a livello pacchetto

Autenticazione e protezione da replay

Ogni pacchetto protetto passa controlli di integrità e autenticità. In IPsec ESP contatore SeqNum e finestra replay prevengono riutilizzo. In WireGuard coppia di chiavi monotona e contatore fanno lo stesso. Qualunque desincronizzazione causa scarto pacchetti, così monitoriamo aumento "Replay errors" come segnale di problemi o "rekey mancato".

Identificatore Security Association (SPI in IPsec) indica con quale chiave cifrare e verificare tag. Il cambio chiave (rekey) avviene per tempo o volume traffico. Se il rekey è lento, cresce rischio riuso nonce. Controlla timer: un buon log key switch è come cambio marcia macchina — fluido e senza scatti.

GCM vs ChaCha20-Poly1305

AES-GCM è standard de facto in IPsec e TLS grazie ad acceleratori hardware (AES-NI, ARMv8 Crypto Extensions). È rapido e parallelo. ChaCha20-Poly1305 brilla dove manca accelerazione AES e serve performance prevedibile su tutte le piattaforme, da qui la scelta WireGuard. Entrambi offrono AEAD: cifratura e autenticazione in un passaggio solo.

In termini di latenza ChaCha20 è spesso più stabile senza cadute improvvise anche su ARM economici. AES-GCM fa record su server con hardware dedicato. Nel 2026 ibridi sono rari, ma si sperimenta post-quantum nelle fasi di handshake (IKEv2 e TLS 1.3) — comodo sapere ma non riguarda ogni pacchetto, solo lo scambio iniziale.

PFS, rekey e timer di vita chiavi

Perfect Forward Secrecy significa che la compromissione di chiavi a lungo termine non espone le sessioni passate. A livello pacchetto non si nota, ma PFS impone rekey periodici. La vita di SA è limitata in tempo e volume. Nei log si vede come cambio SPI e reset contatori. Timer troppo lunghi aumentano rischio nonce riutilizzati.

In pratica: tunnel ad alto traffico fanno rekey ogni 30–60 minuti o 1–2 GB, secondo rischio. Timer brevi aumentano handshake ma migliorano igiene crittografica. Trova il tuo equilibrio e monitora sempre la telemetria.

Metadati e fughe di pattern

Pur criptando il contenuto, i metadati restano visibili: IP, porte, dimensioni pacchetti, intervalli. DPI impara a riconoscere "impronte" WireGuard o OpenVPN da statistiche dimensioni e keepalive. La lotta è nel mascheramento: trasporto QUIC, porte flottanti, padding, emulazione profilo HTTP/3.

Dal punto di vista ingegneristico, la migliore difesa è la varietà. Rekey regolari, dimensione keepalive variabile, assenza di anomalie come pacchetti fissi identici. È come un mascheramento: più ti muovi naturale tra la folla, meno il sorvegliante DPI ti nota.

Ottimizzazioni e casi 2026

Router domestico e WireGuard: vittoria rapida

Caso: router ARM domestico con provider 500 Mbps. Attivo WireGuard, MTU 1420, flow offload e fq_codel nelle code, MSS clamp 1360. Risultato: 400–480 Mbps VPN stabile con 2–4 ms latenza aggiuntiva. Niente di esotico, solo settaggio attento. Perfetto per streaming 4K fluido nel tunnel.

Aggiungi monitoraggio: ogni 5 minuti breve iperf3 da 2–3 secondi, log RTT su ping verso più regioni, contatori drop su interfaccia. Dopo una settimana avrai mappa qualità canale e baseline chiara. Quando arriva il rallentamento serale lo vedi subito, non litighi con provider a caso.

IPsec aziendale con NAT-T: MTU vs realtà

Caso: sedi collegate da IPsec (IKEv2, AES-GCM), NAT-T inevitabile. All’avvio feedback su "RDP lento e Zoom strano". Primo problema: frammentazione sporadica pacchetti esterni e ICMP tagliati. Soluzione: MTU 1400, MSS clamp 1360, ICMP Type 3 Code 4 permessi, copia DSCP per EF (voce). Poche ore e grafici stabilizzati, voce pulita.

Ultimo tocco: bilanciamento tunnel su due provider e health-check con BFD. A livello pacchetto abbiamo mantenuto stabile dimensioni e priorità, senza "curare" le app. A volte il genio è ingegneria semplice.

OpenVPN in cloud e meltdown TCP: come sopravvivere

Caso: OpenVPN su TCP in segmento cloud con proxy. Perdite 0.2–0.5%, RTT oscillante 20–40 ms. TCP interno ed esterno reagiscono entrambi, creando onde stazionarie. Web app soffre. Rimedio temporaneo: window TCP più grande, BBRv2 su TCP esterno, TLS refresh ridotto. A lungo termine: passare a trasporto UDP o QUIC se policy lo permette.

In parallelo trucco logico: ridurre MTU e MSS per ridurre ritrasmissioni di pacchetti grandi. Non è una bacchetta magica, ma senza è inutile provare. Testa porte alternative e camuffa con HTTP/3: DPI moderni in 2026 sono molto tolleranti con QUIC.

SASE, QUIC VPN e trend 2026

Nel 2026 cresce SASE e SDP: il client si connette al PoP più vicino, poi traffico scorre su dorsale privata con priorità. A livello pacchetto vediamo spesso trasporto QUIC con sopra tunneling e cifratura. Si supera il proxy aziendale e si semplificano regole complesse.

Altro trend: acceleratori hardware ai bordi rete: SmartNIC con offload IPsec, eBPF/XDP per rapido processing, ARMv9 con SVE2 per ChaCha20 costante su router di sede. Ibridazioni post-quantum per IKEv2 e TLS 1.3 in fase pilota, ma realtà vicina. Il mondo sta preparando le chiavi del futuro ed è entusiasmante.

Checklist diagnostica tunnel a livello pacchetti

Sintomi e test rapidi

Sintomo: pagine che caricano a scatti, video inceppato, RDP "gommoso". Test 1: ping con DF e brute force di dimensione — individua soglia sicura. Test 2: tcpdump su interfaccia esterna — cerca frammenti e perdite. Test 3: controlla MSS in SYN, assicurati che clamp sia attivo. Test 4: osserva contatori replay e errori ICV su IPsec/WG.

Se dopo clamp e MTU corretto non cambia, cerca jitter provider o problemi QoS. Test facile: iperf3 su porte diverse e DSCP, guarda stabilità. A volte basta cambiare provider last mile e succedono miracoli. È la vita.

Mappa soluzioni durante l’analisi

Soluzioni a gradini: 1) Definisci overhead e imposta MTU tunnel 80–100 byte sotto 1500 con margine. 2) Attiva MSS clamp. 3) Ristabilisci ICMP «Fragmentation Needed» in perimeter. 4) Se serve, passa a trasporto UDP. 5) Prioritizza voce e flussi interattivi. 6) Controlla rekey e aggiorna client.

Se nulla aiuta, indaga DPI e proxy. Magari il traffico è considerato "sospetto" e bloccato. Testa tunnel QUIC o porta 443/UDP, a volte apre tutte le porte. Non è elusione, ma verifica di ipotesi.

Comandi per diversi OS

Linux: ip link set dev wg0 mtu 1420; iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu; tcpdump -ni eth0 udp port 51820. Windows: netsh interface ipv4 set subinterface "Ethernet" mtu=1500 store=persistent e configurazione MTU adattatore VPN via GUI o PowerShell; Packet capture con pktmon o Wireshark.

BSD e pfSense: nelle interfacce WireGuard/OpenVPN ci sono campi MTU e MSS. Ricordati di attivare scrub in pf per normalizzazione e permettere ICMP necessari. Su router con offload hardware verifica che la crittografia non ricada in software per opzioni esotiche. Un flag sbagliato costa centinaia di Mbps.

Errori comuni e come evitarli

Classico: lasciare MTU 1500 nel tunnel, non limitare MSS e poi sorprendersi di frammentazioni. Secondo errore: bloccare ICMP «per sicurezza» e poi passare un mese a risolvere internet lento. Terzo: TCP su TCP senza reale necessità. Quarto: ignorare contatori errori ESP e WireGuard che mostrano replay o danni.

Quinto: non testare con pacchetti piccoli e servizi interattivi. La banda è metà storia. Jitter e latenza sono l’altra metà. Quando entrambe sono a posto, lo senti subito: clic leggeri, video fluidi, file che volano.

FAQ: breve e chiaro

Come stimare velocemente l’MTU per il mio VPN senza conoscere overhead esatto

Prendi 1500 e togli 100 byte per una stima conservativa. Imposta MTU 1400 sul tunnel e MSS 1360. Prova un ping con DF e payload da 1300 a 1472 per trovare il limite. Se passa, alza MTU a step di 10 fino al primo fallimento e poi scendi di 20–30 byte. È un metodo grezzo ma efficace in reti sconosciute con ICMP bloccati e poca documentazione.

Perché WireGuard è spesso più veloce di OpenVPN sugli stessi server

Due motivi. Primo, overhead minore e stabile con crittografia prevedibile ChaCha20-Poly1305. Secondo, design core protocollo: meno copie, meno switch contesto, implementazione più semplice. Su ARM e x86 senza AES-NI WireGuard supera spesso OpenVPN di 1.5–2 volte in throughput e mantiene RTT costante sotto carico. Eccezioni ci sono, ma rare.

Quanto è dannoso TCP-over-TCP e quando è accettabile

Dannoso dove ci sono perdite e jitter. Doppio controllo congestione si interferiscono, latenza esplode. Accettabile se policy stringente obbliga traffico TCP 443 su proxy o DPI. In quel caso aiuta tuning buffer, BBR sul TCP esterno, buona cache. Ma se puoi, passa a UDP o QUIC. Non è questione di preferenze, è fisica di rete.

Perché IPsec cade con file grandi, anche se il ping è basso

Probabilmente MTU/PMTUD. Il ping usa pacchetti piccoli da 64 byte, i file grandi spingono segmenti al limite. Se ICMP «Fragmentation Needed» è bloccato, il mittente non sa di dover ridurre e vedi timeout, ritrasmissioni e cadute. Cura: MTU tunnel giusta, MSS clamp e ICMP abilitato. Facile da testare: ping con DF su pacchetti grandi e tcpdump.

Ha senso copiare il DSCP dall’IP interno all’esterno nel VPN?

Sì, se hai QoS lungo il percorso e vuoi che voce, video e interattivi abbiano priorità non solo dentro la rete ma anche nel canale verso l’uscita. Molti operatori nel 2026 tengono conto di DSCP nei nuclei di trasporto. Fondamentale accordarsi sui valori e non abusa di EF/CS5 per evitare polizze aggressive. Prima pilota, poi rollout — regola d’oro.

È il momento di passare agli algoritmi post-quantum nel VPN?

Per traffico quotidiano ancora no. Le vere soluzioni post-quantum appaiono in IKEv2/TLS come ibridi durante handshake. A livello di pacchetto la differenza è trascurabile, e overhead e compatibilità possono essere un problema. Però per dati sensibili a lungo termine i piloti sono sensati. Tieni d’occhio gli aggiornamenti e preparati a migrare.

Come capire se la mia rete «stretta» è colpa del VPN o del provider?

Confronta benchmark sullo stesso canale: iperf3 diretto e via tunnel, più misure RTT e jitter su pacchetti piccoli. Se la velocità cala del 30–40% e CPU cifratura sale, è problema VPN o MTU/MSS. Se cala uguale senza VPN e latenza cresce senza carico, è linea provider. Monitora costantemente per un giorno e avrai il quadro.