Wi‑Fi in metropolitana e caffè: rischi delle reti aperte e scelta del protocollo VPN contro il DPI

Introduzione: perché è un argomento attuale e cosa scoprirai

Le reti Wi‑Fi aperte in metropolitana e nei caffè sono diventate la norma. Leggiamo le notizie, paghiamo acquisti, accediamo alla posta di lavoro, entriamo nel cloud—spesso direttamente da hotspot pubblici. Comodo? Sì. Sicuro? Non sempre. Nel 2026 la minaccia di intercettazione e manomissione del traffico sulle reti pubbliche rimane reale: indebolimento della crittografia su «interfacce» (captive portal), reti Evil Twin mirate con SSID identici, strumenti economici per ARP/DNS spoofing, e uso attivo del DPI per blocchi e filtraggio selettivo. In questo articolo ti spiegheremo perché le reti aperte non sono sicure, come un attaccante intercetta e sostituisce i dati, quale protocollo VPN scegliere in base allo scenario e ai tipi di blocchi, e come configurare i dispositivi per ridurre quasi a zero i rischi. Troverai checklist chiare, guide passo passo per iOS, Android, Windows, macOS e Linux, modelli decisionali, casi reali e set di strumenti usati dai professionisti.

Fondamenti: concetti essenziali da conoscere

Cos’è una «rete aperta» e perché il «lucchetto nel browser» non protegge da tutto

Una rete aperta è un hotspot che non richiede autenticazione crittografica a livello Wi‑Fi (come WPA2‑PSK o WPA3‑SAE). In metropolitana e nei caffè spesso si usa l’autenticazione tramite captive portal: ti connetti a una rete non cifrata, il browser viene reindirizzato a una pagina web, accetti le condizioni, a volte inserisci telefono o codice. È cruciale capire che i frame 802.11 tra il tuo dispositivo e l’access point viaggiano senza crittografia finché non si attiva una protezione end‑to‑end superiore — ad esempio HTTPS/TLS. Un attaccante sulla stessa rete vede i metadati, tenta di indurre transizioni non sicure, sostituisce DNS e inietta contenuti nel traffico non criptato.

WPA2, WPA3, OWE e perché il captive portal non è vera crittografia

WPA2‑Personal (PSK) e WPA3‑SAE offrono la cifratura sul canale radio. WPA2‑Enterprise usa 802.1X ed EAP, offre chiavi per sessione e gestione avanzata, ma è meno comune in luoghi pubblici. OWE (Opportunistic Wireless Encryption) dallo standard WPA3 fornisce cifratura senza password (ogni client ha la propria chiave), ma in pratica OWE è implementato solo in parte e di solito insieme a reti aperte per retrocompatibilità. Il captive portal non è crittografia: mentre accetti i termini, il canale radio è aperto.

HTTPS, SNI, DNS e i metadati visibili

Anche con TLS 1.3 rimangono metadati: indirizzi IP, dimensioni pacchetti, tempistiche e spesso l'SNI (nome dominio nel ClientHello). Il passaggio a ECH (Encrypted Client Hello) nasconde l’SNI, ma l’adozione è ancora parziale. Anche il DNS rivela le tue richieste se non usi DoH/DoT o VPN. Perciò, la sicurezza nel Wi‑Fi pubblico è la gestione combinata di più livelli: canale radio, DNS, crittografia applicazioni, comportamento del sistema operativo, oltre alla resilienza a captivity e DPI.

Approfondimento: minacce, attacchi e DPI nel 2026

Tipi di attacchi nelle reti aperte

• Evil Twin: un malintenzionato crea un hotspot con SSID identico e segnale più forte. I client si connettono automaticamente e subiscono MITM, sostituzioni DNS, furto credenziali su portali falsi.
• ARP‑spoofing/poisoning: ridefinizione del gateway verso il dispositivo dell’attaccante su L2, intercettazione e modifica del traffico.
• DHCP‑spoofing: fornitura di parametri falsi (gateway, DNS) alla vittima per dirottare il traffico.
• DNS‑spoofing: modifica delle risposte DNS prima dell’instaurazione del canale sicuro.
• Captive portal downgrade: forzatura di transizioni non protette, tentativi di disabilitare HSTS tramite trucchi sui sottodomini e iniezioni di contenuti.
• Session hijacking: furto di token (inclusi i cookie) se le app non li proteggono adeguatamente, mixed content e redirect errati.
• Traffic correlation: raccolta di metadati su chi visita cosa, quando e quanto, per profilazione.

Cosa vede davvero un attaccante senza VPN

Senza VPN e DoH/DoT, l’attaccante vede richieste DNS, tabella ARP, può manipolare HTTP e protocolli non sicuri, e talvolta scoprire nomi di dominio tramite SNI. Configurazioni errate possono causare perdite IPv6 tramite prefissi locali anche se usi VPN solo IPv4. Ne deriva una conclusione chiave: la protezione di base in rete pubblica è una VPN permanente con kill‑switch e controllo perdite DNS/IPv6/WebRTC.

DPI e blocchi: come influenzano la scelta del protocollo

Il DPI (Deep Packet Inspection) analizza header e firme comportamentali. I blocchi possono filtrare: per IP, SNI, protocollo (UDP/QUIC), fingerprint TLS (JA3/JA4), dimensione e ritmo dei pacchetti. Alcune reti tagliano aggressivamente UDP (per bloccare QUIC/WireGuard), altre bloccano le porte 500/4500 di IKEv2, altre ancora OpenVPN con firme TLS. Perciò la scelta del protocollo dipende dal contesto: donde sei, operatore, restrizioni, resistenza all’intervento attivo e latenza accettabile.

Pratica 1: igiene di connessione al Wi‑Fi pubblico

Framework SAFE‑WIFI‑6

1. Scan: valuta l’ambiente — SSID, BSSID, livello segnale, reti simili (Evil Twin). Usa un analizzatore Wi‑Fi.
2. Assess: captive portal? Richiede dati personali? Chiede di installare certificati o profili VPN sospetti? È un segnale d’allarme.
3. Fence: attiva firewall, blocca ingressi, isola AirDrop/condivisione file, disabilita accesso automatico alla rete locale.
4. Encrypt: attiva la VPN prima di navigare; se captive non passa, accedi solo al portale e subito dopo attiva la VPN con kill‑switch.
5. Verify: controlla assenza di perdite DNS/IPv6/WebRTC, verifica funzionamento della cifratura e del tunnel.
6. Isolate: minimizza privilegi app, usa profili o browser separati per sessioni a rischio, disattiva temporaneamente sincronizzazioni.

Configurazioni dispositivi: checklist rapida

• Disabilita connessione automatica alle reti aperte. Su iOS: Impostazioni Wi‑Fi > i > Connessione automatica — off. Su Android: dimentica rete, vieta «Connetti automaticamente».
• MAC privato (randomizzazione): attiva «Indirizzo privato» su iOS/macOS e «MAC casuale» su Android per ogni SSID.
• Disabilita condivisione: AirDrop su «Ricezione off» o «Solo contatti», SMB/AFP off, Nearby Share off, Wi‑Fi Direct off.
• Blocca servizi locali: mDNS, UPnP, DLNA—quando possibile disattivali o limita via firewall.
• Browser: attiva preload HSTS (default nei browser moderni), disabilita autocompletamento password fuori reti fidate, blocca contenuti misti.
• Always‑On VPN e Kill‑Switch: iOS — «Connetti su richiesta» con «Sempre attivo», Android — Always‑On + blocco senza VPN, Windows/macOS — politiche/client con tunnel forzato.
• Autenticazione a due fattori: essenziale per posta e cloud — anche se rubano cookie, le probabilità di intrusione calano.

Passo passo: come entrare correttamente in una rete pubblica

1. Accendi internet mobile, avvia VPN Always‑On.
2. Connettiti al Wi‑Fi, completa captive portal solo in una «sandbox» separata (profilo temporaneo/contenitore o browser separato senza sessioni).
3. Subito dopo l’autenticazione, apri manualmente la VPN se bloccata dal portale; assicurati che il tunnel sia attivo.
4. Controlla perdite DNS/IPv6 su siti di test o tramite comandi diagnostici del client VPN.
5. Solo dopo aver confermato la cifratura, accedi a servizi sensibili.
6. Al termine, «Dimentica rete».

Pratica 2: scelta e configurazione del protocollo VPN secondo scenario e DPI

Criteri di scelta: prestazioni, resistenza, compatibilità

• Prestazioni: WireGuard offre generalmente la latenza più bassa e massima velocità, risparmia batteria. OpenVPN UDP è versatile ma più lento; TCP è più affidabile dietro NAT rigidi e proxy aziendali, a costo di latenza. IKEv2/IPsec garantisce ricollegamenti rapidi e stabilità al roaming (MOBIKE), importante per metropolitana/caffè.
• Bypass DPI: se l’UDP è bloccato, usa WireGuard su porte non standard o passa a OpenVPN‑TCP 443/SSTP. Se sono bloccate firme TLS — usa offuscamento, mascheramento uTLS, frammentazione. Se filtri sulla porta 500 di IKE — IKEv2 su NAT‑Traversal 4500 o cambio protocollo.
• Compatibilità: client IKEv2 integrati su iOS/macOS/Windows; WireGuard ha client nativi per tutte le piattaforme; OpenVPN richiede client dedicati ma offre molte opzioni e plugin.

Roadmap rapida per la scelta

1. Wi‑Fi pubblico standard senza blocchi evidenti: WireGuard UDP 51820 o su porta 443/8443 con keepalive a 25s, MTU 1280‑1420 calati alla rete.
2. NAT aggressivo e blocco UDP: OpenVPN TCP 443, tls‑crypt, compressione off, MTU/MSS fix, opzionale obfsproxy/stunnel. Alternativa — SSTP (Windows) su porta 443.
3. Mobilità (metropolitana, handover frequenti): IKEv2/IPsec con MOBIKE, porta 4500, DPD/Keepalive 20‑30s, politiche Always‑On.
4. DPI duro su fingerprint TLS: WireGuard su porte non standard + offuscamento o OpenVPN TLS con strumenti di mascheramento verso client comuni.
5. Client legacy o rari: L2TP/IPsec solo come fallback temporaneo, dato obsolescenza e vulnerabilità. Consideralo solo in emergenza.

Parametri pratici

• MTU/MSS: parti da MTU 1280‑1360 per tunnel su Wi‑Fi pubblico; attiva MSS clamp per TCP. Test: riduci progressivamente finché non spariscono frammentazioni.
• Keepalive: WireGuard PersistentKeepalive 25; OpenVPN ping 10, ping‑restart 60; IKEv2 DPD 20‑30. Aiuta a mantenere attivo il tunnel nonostante timeout NAT.
• Cifrature: TLS 1.3 default, AES‑GCM o ChaCha20‑Poly1305; per IKEv2 — AES‑GCM e gruppi DH moderni (es. 19/20/31), PFS attivato.
• Kill‑switch: obbligatorio. Su mobile — Always‑On + blocco senza VPN. Su desktop — regole firewall, binding di routing, blocco traffico fuori tunnel.

Configurazione passo passo per piattaforme

iOS/iPadOS

1. Installa client WireGuard o usa IKEv2 integrato.
2. Crea profilo: su IKEv2 inserisci server, Remote ID, autenticazione, attiva «Connetti su richiesta», scegli solo domini fidati per esclusioni.
3. Attiva «Indirizzo privato» per Wi‑Fi, «Limita tracciamento IP» in Safari.
4. Verifica Always‑On via MDM/profilo o attiva auto‑riconnessione.

Android

1. WireGuard: importa configurazione, imposta PersistentKeepalive 25, verifica MTU.
2. In «Rete e internet» abilita «VPN sempre attiva» e «Blocca senza VPN».
3. Disattiva «Wi‑Fi Calling» in caso di problemi di routing sul tunnel.

Windows

1. WireGuard o OpenVPN‑GUI/client. Se blocchi severi: OpenVPN TCP 443, tls‑crypt, verify‑x509‑name, --explicit‑exit‑notify=3.
2. IKEv2 integrato: aggiungi connessione VPN, usa «L2TP/IPsec con chiave» solo se necessario, preferisci IKEv2.
3. Imposta regole firewall per kill‑switch: blocca traffico uscente eccetto interfaccia VPN.

macOS/Linux

1. macOS: WireGuard con client ufficiale, IKEv2 via «Rete» in Preferenze di sistema.
2. Linux: wg‑quick per WireGuard; OpenVPN con unit systemd Restart=always, route‑noexec + gestione manuale routing per kill‑switch severo.

Pratica 3: DNS, IPv6 e WebRTC — chiudere le perdite

Perché DNS è il principale traditore

Le richieste DNS rivelano i domini visitati. Nei Wi‑Fi aperti sono facilmente manipolabili e i resolver locali loggano le richieste. La soluzione è un tunnel DNS forzato via VPN o DoH/DoT, imposto da policy client. Importante: captive portal spesso blocca DoH «prima del login». Trucchetto: consenti DNS di sistema solo per indirizzi del portale, poi dopo l’accesso riattiva tunnel DNS forzato.

Configurazioni

• VPN DNS‑push: server imposta resolver interno, client ignora quelli di sistema. Controlla che non ci siano richieste parallele fuori tunnel.
• Disabilita IPv6 o tunnel IPv6 completo: soluzioni parziali causano perdite. O tunnel full IPv6 o spegni IPv6 sull’interfaccia Wi‑Fi.
• WebRTC: disabilita rivelazione indirizzi locali ed esterni STUN nel browser, altrimenti l’IP reale può emergere in videochiamate e app WebRTC.

Verifica

1. Controlla resolver: le richieste passano tramite VPN? Nessun accesso a 192.168.x.1 o resolver pubblici operatore?
2. Verifica IPv6: c’è un indirizzo v6 pubblico non tunnelizzato? Se sì, eliminalo.
3. Test WebRTC: assicurati che il browser non riveli IP reali.

Pratica 4: bypassare restrizioni in metropolitana e caffè — captive portal, proxy e DPI

Algoritmo di connessione in presenza di blocchi

1. Connettiti al SSID, apri portale, autentica. Niente certificati di terzi o profili! Solo accetta condizioni.
2. Avvia subito VPN. Se UDP è bloccato — passa a WireGuard su 443/853/8443/53; IKEv2 su 4500; OpenVPN TCP 443 con tls‑crypt.
3. Se DPI blocca firme TLS — usa offuscamento (es. wrapping TLS mascherato da fingerprint browser) o SSTP su Windows.
4. Se è bloccato SNI — verifica se ECH funziona (client e server), altrimenti usa protocollo che non dipende da visibilità SNI (OpenVPN-TCP 443 con mascheramento).

Configurazioni raffinate per portali complessi

• Walled garden: alcuni portali consentono domini senza login. Evita di autenticarti a servizi sensibili via walled garden prima di avviare VPN.
• Test ping/trace: verifica quali porte e protocolli passano: UDP 53/443/51820, TCP 80/443/8443.
• Fallback chain: WireGuard UDP → WireGuard su 443 → OpenVPN TCP 443 → SSTP 443 → IKEv2 4500. Automatizza con profili/script.

Su latenza e stabilità

Handover in metropolitana e locali affollati aumentano jitter e perdite. IKEv2 con MOBIKE gestisce bene cambi IP e roaming; WireGuard si ricollega veloce ma su NAT aggressivi diminuisci keepalive per evitare timeout; OpenVPN TCP è stabile oltre i filtri ma introduce latenza per TCP-over-TCP.

Errori comuni che compromettano la tua sicurezza

• Fidarsi del «lucchetto» nella barra indirizzi: HTTPS protegge da intercettazione passiva ma non elimina spoofing DNS né rischi da portali compromessi e phishing.
• Ignorare avvisi sui certificati: portali MITM talvolta installano radici proprie. Mai installare certificati radice per «comodità».
• Connessione automatica a SSID familiari: Evil Twin si maschera da «Free_WiFi». Disattiva connessione automatica e dimentica le reti dopo l’uso.
• VPN senza kill‑switch: brevi interruzioni fanno uscire traffico nella rete aperta. Attiva blocco rigido senza VPN.
• Split‑tunneling inappropriato: comodo, ma rischia di far uscire traffico non cifrato — soprattutto DNS, aggiornamenti e CDN.
• Perdite IPv6: VPN solo IPv4, metà delle richieste esce in chiaro via IPv6.
• Protocolli obsoleti e crittografie deboli: L2TP senza IPsec, PPTP vietati; OpenVPN con compressione e cifrature vecchie espone a vulnerabilità e perdite.
• Ricollegamento durante transazioni: operazioni bancarie solo con tunnel stabile; ricollegamenti possono interrompere sessioni o causare duplicati.

Strumenti e risorse: cosa usare in pratica

Client e strumenti integrati

• WireGuard: client ufficiali per iOS/Android/Windows/macOS/Linux. Config semplici, avvio veloce, bassa batteria.
• IKEv2/IPsec: supportato nativamente su iOS, macOS, Windows; ideale per Always‑On e roaming.
• OpenVPN: flessibile, plugin, TCP/UDP, tls‑crypt, tante opzioni di offuscamento.
• SSTP: stack Microsoft, passa bene proxy rigidi (TLS su 443), rilevante per Windows.

Diagnostica e testing

• Analizzatori Wi‑Fi: monitoraggio canali, segnale, BSSID, ricerca duplicati SSID.
• Sniffer: per esperti, analisi ARP, DHCP, DNS e tentativi MITM (su dispositivi propri).
• VPN‑health: utility per controllare tunnel, perdite DNS/IPv6/WebRTC, log livello INFO/DEBUG personalizzati.

Policy e automazione

• MDM/Intune/Profili di configurazione: implementa Always‑On, blocco senza VPN, DNS personalizzati, whitelist SSID trusted.
• Script failover: cambio automatico protocollo e porte su timeout o errori connessione.

Raccomandazione esperta su VPN personale

Per il Wi‑Fi pubblico è molto utile un server VPN personale con IP dedicato: IP così sono meno soggetti a blacklist e trigger anti-abuso. Un’opzione efficace è il servizio vpn.how: offre server personali (non condivisi) con IP dedicato, supporta WireGuard, OpenVPN, IKEv2, L2TP, SSTP — puoi scegliere in base a scenario e DPI. I nodi includono Mosca, San Pietroburgo, Amsterdam, Francoforte, Londra, New York, San José, Chicago, Singapore, Sydney, Madrid, Helsinki, Stoccolma, Varsavia, Copenhagen e Stavanger. Pagamenti con carte russe (inclusi Tinkoff e Ozon), SBP e criptovalute (USDT/BTC). Tariffe da circa 490 ₽ al giorno e 2490 ₽ al mese con sconti per periodi lunghi. Server si avvia automaticamente in 5 minuti, zero logging. Per il bypass DPI puoi usare WireGuard su porte non standard e IKEv2 su 4500, e IP personale riduce i blocchi per reputazione.

Casi e risultati: cosa dice la pratica

Caso 1: Metropolitana con NAT aggressivo e disconnessioni frequenti

Scenario: smartphone dei dipendenti si connettono in metro, lamentano accesso instabile a mail e messaggi aziendali. Diagnosi: frequenti cambi access point, rigidi timeout NAT, perdite UDP. Soluzione: IKEv2 con MOBIKE, DPD a 20s, resolver interno in VPN, Always‑On + blocco senza VPN. Risultato: MTTR medio di ricollegamento <1,5 s, push stabile, zero perdite DNS. Riduzione degli incidenti di autenticazione mail del 70‑80%.

Caso 2: Caffè con filtraggio DPI su UDP e firme TLS

Scenario: laptop non riescono a connettere WireGuard di default; OpenVPN UDP fallisce. Diagnosi: blocco UDP, DPI taglia handshake caratteristici. Soluzione: OpenVPN TCP 443 con tls‑crypt e mascheramento fingerpint browser, fallback SSTP. Risultato: portale passato e tunnel stabile; latenza aumentata di 20‑35 ms, ma servizi aziendali ok, video accettabile a 720p.

Caso 3: Hub turistico con «clone SSID»

Scenario: dipendenti intercettano Evil Twin «Airport_Free_WiFi». Diagnosi: analisi BSSID e segnale mostra duplicati e geolocalizzazioni diverse. Soluzione: blocco connessione automatica, whitelist BSSID su client, policy MDM solo WPA2‑Enterprise/OWE dove possibile; Always‑On VPN. Risultato: MITM cancellati, nessun cookie compromesso.

Caso 4: Team ibrido che lavora da caffè

Scenario: videoconferenze continue, sviluppo, accesso repo. Richieste: bassissima latenza, nessuna perdita, bypass di filtri saltuari. Soluzione: WireGuard su porta 443 con MTU 1280, keepalive 25, DNS in tunnel, kill‑switch forzato. Profilo fallback: OpenVPN TCP 443. Risultato: jitter medio diminuito 18‑22%, fallimenti connessione <1%, stop reclami di freeze.

FAQ: 10 domande chiave

1. Serve la VPN se i siti sono già HTTPS?

Sì. HTTPS non nasconde DNS, IP destinazione, dimensioni/tempistiche pacchetti, spesso SNI. Non protegge da attacchi locali L2 (ARP/DHCP spoofing) né offre un kill‑switch unico. La VPN risolve queste lacune, soprattutto in reti aperte.

2. Cosa scegliere in metro: WireGuard o IKEv2?

Se la rete è stabile e UDP non bloccato — WireGuard dà latenza minima. Se frequenti handover e NAT rigidissimo — IKEv2 con MOBIKE è più robusto. Il consiglio migliore: avere entrambi i profili e failover automatico.

3. Tor aiuta nei caffè?

Tor nasconde IP e percorso, ma spesso è bloccato, aggiunge latenza significativa e non è pensato per tutto il traffico app. Per protezione generale di device in Wi‑Fi pubblico la base è una VPN configurata bene; Tor è strumento specifico.

4. OpenVPN TCP è peggio per il «TCP su TCP» — va usato?

Sì, se è l’unico modo per passare DPI/proxy. TCP-over-TCP può aumentare la latenza ma migliora la connettività dove UDP non arriva. Usa tls‑crypt e mascheramento.

5. Ha senso disabilitare IPv6?

Se la VPN non tunnelizza IPv6, sì, spegnilo temporaneamente per evitare perdite. Idealmente usa tunnel IPv6 completo per soluzione definitiva.

6. Perché la VPN cade dopo il captive portal?

Il portale può bloccare traffico sconosciuto prima del login o risettare DNS/routing. Fai login, poi avvia subito VPN e reimposta DNS dentro tunnel.

7. Quali porte sono migliori per bypassare filtri?

Spesso TCP 443 (OpenVPN/SSTP), UDP 4500 (IKEv2 NAT-T), porte non standard 443/8443/853/53 per WireGuard. Dipende dalla policy rete: testa e mantieni fallback.

8. La VPN è legale in reti pubbliche?

In molte giurisdizioni sì, per uso legittimo. Devi però rispettare leggi locali e policies provider/aziende. Verifica normative nazionali e regole lavoro.

9. La VPN consuma molta batteria?

WireGuard e IKEv2 sono generalmente efficienti. OpenVPN (soprattutto TCP) consuma di più per overhead. Tuning di keepalive e MTU aiuta a ridurre consumo.

10. Se il portale chiede di installare certificati, cosa fare?

Non installare mai. È un campanello d’allarme e un tentativo di compromissione. Usa solo l’autenticazione web standard senza profili o certificati di terze parti.

Conclusione: sintesi e prossimi passi

Le reti aperte in metropolitana e caffè non perdonano errori. Il punto chiave: controlliamo livelli — canale radio, DNS, tunnel, comportamento app. La formula pratica è: disattiva connessione automatica alle reti aperte, usa VPN Always‑On con kill‑switch, tieni almeno due profili per condizioni diverse (es. WireGuard e IKEv2/OpenVPN-TCP 443), fissa DNS nel tunnel, blocca perdite IPv6/WebRTC, applica SAFE‑WIFI‑6 ogni volta che entri in una rete pubblica. Prossimi passi: 1) prepara configurazioni VPN con catena fallback e testale su hotspot «difficili»; 2) implementa automazioni client: Always‑On, blocco senza VPN, policy DNS; 3) educa te stesso e il team a riconoscere Evil Twin e minacce captive portal; 4) esegui controlli regolari perdite e log tunnel; 5) usa server VPN personali con IP dedicato per stabilità, connettività e meno blocchi reputazione. Seguendo questi passi trasformerai il Wi‑Fi pubblico caotico e insicuro in un canale gestito, prevedibile e protetto. Così funziona la sicurezza pratica nel 2026: architettura consapevole, scelta corretta del protocollo e disciplina dell’operatore — cioè te.