WireGuard per l'accesso remoto: VPN veloce per chi lavora fuori ufficio

Per anni l'accesso remoto in azienda ha voluto dire OpenVPN o la VPN SSL del firewall: client pesanti, connessioni che cadono quando il portatile passa dal Wi-Fi al 4G, prestazioni mediocri. WireGuard ha cambiato le cose. È nel kernel Linux, è supportato nativamente da MikroTik RouterOS 7, dai gateway UniFi e da OPNsense, e ha client ufficiali per Windows, macOS, iOS e Android.

Per le VPN tra sedi ho già scritto un articolo dedicato. Qui parlo del caso più comune: i dipendenti che lavorano da casa o in trasferta.

Perché WireGuard

• Veloce: crittografia moderna e codice snello, throughput molto più alto di OpenVPN a parità di hardware.
• Silenzioso: non risponde a chi non ha una chiave valida. Una scansione della porta non rivela nemmeno che il servizio esiste.
• Roaming trasparente: il portatile cambia rete e il tunnel continua a funzionare, senza riconnessioni.
• Configurazione leggibile: un file di poche righe per lato.

Il rovescio: WireGuard non ha utenti né password, solo coppie di chiavi. Non ha un secondo fattore integrato e non si collega ad Active Directory. Per un'azienda questo va gestito con metodo, come vediamo sotto.

La configurazione

Lato server

# /etc/wireguard/wg0.conf
[Interface]
Address    = 10.66.0.1/24
ListenPort = 51820
PrivateKey = <chiave privata del server>

# Mario Rossi - portatile aziendale
[Peer]
PublicKey  = <chiave pubblica del client>
AllowedIPs = 10.66.0.10/32

# Laura Bianchi - portatile aziendale
[Peer]
PublicKey  = <chiave pubblica del client>
AllowedIPs = 10.66.0.11/32

Lato client

[Interface]
Address    = 10.66.0.10/32
PrivateKey = <chiave privata del client>
DNS        = 192.168.10.1

[Peer]
PublicKey  = <chiave pubblica del server>
Endpoint   = vpn.tuaazienda.it:51820
AllowedIPs = 192.168.10.0/24, 10.66.0.0/24
PersistentKeepalive = 25

AllowedIPs ha due significati diversi, ed è la fonte di quasi tutti gli errori: sul server indica quali IP può usare quel peer; sul client indica quale traffico passa nel tunnel.

Split tunnel o full tunnel

• Split tunnel (AllowedIPs = 192.168.10.0/24): nel tunnel passa solo il traffico verso la rete aziendale. Netflix e gli aggiornamenti di Windows vanno direttamente su Internet. È la scelta giusta nella maggior parte dei casi.
• Full tunnel (AllowedIPs = 0.0.0.0/0): tutto il traffico passa dall'azienda. Serve quando la navigazione deve uscire con l'IP aziendale (portali che filtrano per IP) o passare dal filtro web aziendale. Costa banda in upload alla sede.

Gestire gli utenti con metodo

• Una chiave per dispositivo, mai condivisa. Portatile e telefono della stessa persona sono due peer.
• Le chiavi private non viaggiano per email. L'ideale è generarle sul dispositivo; in alternativa, QR code mostrato di persona per i telefoni.
• Un registro: chi ha quale IP e quale chiave. Quando un dipendente lascia l'azienda o perde il portatile, si rimuove il suo peer e basta.
• Regole firewall per gruppo: il commerciale raggiunge il gestionale, non l'interfaccia del firewall. Assegnare IP per fasce (amministrazione, tecnici, fornitori) rende le regole semplici.
• Se serve il secondo fattore, lo si mette sui servizi raggiunti attraverso la VPN, oppure si usa una soluzione di gestione basata su WireGuard che lo aggiunge.

Tre problemi reali e come evitarli

1. MTU: la VPN va, ma alcune cose no

Il ping funziona, le cartelle di rete si aprono, ma certi siti o applicazioni si bloccano a metà caricamento. È quasi sempre la MTU: WireGuard aggiunge un'intestazione e i pacchetti pieni non passano più, specialmente su connessioni PPPoE o 4G. Si risolve abbassando la MTU del tunnel (1420 è il default, sulle linee difficili si scende a 1380 o meno) e, quando il traffico viene inoltrato attraverso il tunnel, applicando il MSS clamping sul firewall. Ho visto micro-blocchi su un servizio in produzione sparire con due regole di clamping.

2. Il tunnel "attivo ma morto"

Il caso più subdolo: interfaccia attiva, handshake recente, contatori che salgono, ma nessun pacchetto arriva dall'altra parte. WireGuard non ha una sessione da far cadere, quindi non segnala nessun errore. Succede tipicamente quando un lato è dietro NAT e il router rimappa la porta: il peer remoto continua a rispondere alla porta vecchia.

• sul lato dietro NAT imposta una ListenPort fissa invece di una porta casuale;
• tieni PersistentKeepalive sotto il timeout UDP del router (su alcuni gateway è 30 secondi: in quel caso 15–20);
• per i tunnel che devono restare su, un controllo che provi il traffico reale (un ping all'altro capo) e riavvii il tunnel se fallisce. Lo stato del servizio e l'età dell'handshake non bastano.

3. Stessa subnet a casa e in ufficio

Se la sede usa 192.168.1.0/24 e il router di casa del dipendente anche, il traffico non sa dove andare. Per questo le reti aziendali vanno numerate con subnet poco comuni (ad esempio 10.23.40.0/24): costa poco farlo all'inizio e molto rinumerare dopo.