Configurazione di WireGuard su Windows

Questa guida spiega come configurare un tunnel VPN WireGuard tra due computer Windows: un server WireGuard in esecuzione su un host Windows remoto, ad esempio un VPS Windows, e un client WireGuard in esecuzione sul computer Windows locale. Una volta attivo il tunnel, i due computer scambiano dati tramite una connessione privata cifrata ed è possibile, facoltativamente, instradare tutto il traffico del client attraverso il server.

La configurazione di base crea un tunnel tra il server e il client. Per instradare tutto il traffico Internet del client attraverso il server è necessario anche il NAT sul server, vedere «Configurazione del NAT sul server per il full tunneling».

Per semplificare la generazione delle chiavi, questa guida crea sia la configurazione del server sia quella del client all'interno di un'unica applicazione WireGuard e poi distribuisce ciascun file di configurazione sul computer a cui appartiene. La configurazione del server viene eseguita sul server e quella del client sul client. Il server e il client sono sempre computer distinti. Lo stesso procedimento si usa per aggiungere un numero qualsiasi di client aggiuntivi.

Prima di iniziare, installare l'ultima versione di WireGuard dalla pagina di installazione di WireGuard sia sul server sia sul client e assicurarsi di disporre dei privilegi di amministratore su ciascun computer.

La configurazione di questa guida è la seguente:

Server (IP pubblico, in ascolto su UDP 51820)
Indirizzo del tunnel 10.0.0.1/24
        |
        |  tunnel WireGuard cifrato
        |
Client
Indirizzo del tunnel 10.0.0.2/32

Creazione della configurazione del server

Eseguire C:\Program Files\WireGuard\wireguard.exe, fare clic su Add tunnel e scegliere Add empty tunnel. WireGuard genera automaticamente una coppia di chiavi. La chiave pubblica mostrata nella parte superiore della finestra è la chiave pubblica del server. Servirà più avanti per configurare il client.

Assegnare un nome al tunnel e compilare la sezione Interface con la chiave privata del server, la porta su cui WireGuard resterà in ascolto e l'indirizzo interno che il server utilizzerà all'interno del tunnel.

[Interface]
PrivateKey = # chiave privata del server WireGuard
ListenPort = # porta su cui WireGuard resterà in ascolto
Address = # indirizzo IP interno del server WireGuard, ad esempio 10.0.0.1/24

Utilizzare una subnet privata per la rete del tunnel e mantenere il server e tutti i client nello stesso intervallo. Una scelta comune è 10.0.0.1/24 per il server e 10.0.0.2/32, 10.0.0.3/32 e così via per ciascun client. Il server usa il prefisso /24 in modo da considerare l'intero intervallo del tunnel raggiungibile tramite l'interfaccia WireGuard. Ogni client usa /32, perché un client rappresenta un singolo indirizzo e non una subnet. Un client impostato su /24 presumerebbe che l'intero intervallo si trovi sulla propria interfaccia e non invierebbe nel tunnel il traffico destinato ad altri indirizzi del tunnel.

La configurazione del server non mostra la casella Block untunneled traffic (kill-switch). Questa opzione compare solo in una configurazione client che instrada tutto il traffico attraverso il tunnel, vedere «Creazione della configurazione del client».

Per un ulteriore livello di sicurezza, è possibile aggiungere una chiave precondivisa a ciascun peer. Generarla una sola volta e aggiungere la stessa riga alla sezione [Peer] corrispondente sia sul server sia sul client:

PresharedKey = # chiave precondivisa, identica sul server e sul client

È possibile generare la chiave con lo strumento wg fornito con WireGuard:

"C:\Program Files\WireGuard\wg.exe" genpsk

Creazione della configurazione del client

Fare clic su Add tunnel e scegliere Add empty tunnel una seconda volta, questa volta per il client. La chiave pubblica mostrata per questo tunnel è la chiave pubblica del client, di cui il server ha bisogno per accettare il client.

Compilare la configurazione del client:

[Interface]
PrivateKey = # chiave privata del client WireGuard
Address = # indirizzo IP interno del client WireGuard, ad esempio 10.0.0.2/32
DNS = 1.1.1.1, 1.0.0.1
[Peer]
PublicKey = # chiave pubblica del server WireGuard
AllowedIPs = # 0.0.0.0/0 per un full tunnel oppure 10.0.0.0/24 per uno split tunnel
Endpoint = # indirizzo IP pubblico e porta del server WireGuard
PersistentKeepalive = 25

Endpoint deve essere l'effettivo indirizzo IP pubblico del server insieme alla porta impostata in ListenPort del server, non l'indirizzo interno del tunnel. Per scegliere il valore di AllowedIPs, vedere la sezione «Comprendere AllowedIPs» più avanti.

Le righe DNS e PersistentKeepalive sono facoltative. DNS imposta i server DNS utilizzati mentre il tunnel è attivo, il che aiuta a evitare problemi di risoluzione dei nomi dopo la connessione. È possibile usare resolver pubblici come 1.1.1.1, 1.0.0.1 oppure 8.8.8.8, 8.8.4.4, oppure il server DNS della stessa rete VPN. PersistentKeepalive = 25 invia un piccolo pacchetto ogni 25 secondi e aiuta a mantenere aperta la connessione quando il client si trova dietro un NAT.

Quando la configurazione del client contiene un solo [Peer] e il suo AllowedIPs comprende 0.0.0.0/0 (o ::/0), l'editor del tunnel mostra la casella Block untunneled traffic (kill-switch) sotto il campo di configurazione. Con uno split tunnel, ad esempio AllowedIPs = 10.0.0.0/24, la casella non compare affatto.

Il kill-switch è abilitato per impostazione predefinita non appena si inserisce 0.0.0.0/0. Mentre il tunnel è attivo, le regole del firewall consentono solo il traffico che passa attraverso il tunnel, il traffico di loopback, DHCP e il neighbor discovery IPv6. Tutto il resto viene bloccato, compresi i dispositivi della rete locale come stampanti e NAS. Se la riga DNS è impostata, le query DNS sono consentite solo verso i server ivi elencati.

Deselezionare la casella non equivale semplicemente a disattivare un'impostazione. L'editor riscrive AllowedIPs: 0.0.0.0/0 diventa 0.0.0.0/1, 128.0.0.0/1 e ::/0 diventa ::/1, 8000::/1. Tutto il traffico Internet continua a passare attraverso il tunnel, ma le regole firewall di blocco non vengono create. Selezionando di nuovo la casella si ripristina 0.0.0.0/0.

Copiare con la massima attenzione le chiavi e l'Endpoint. Una chiave digitata in modo errato o un Endpoint sbagliato è la causa più comune del mancato collegamento di un tunnel.

Aggiunta del client al server

Aprire di nuovo la configurazione del server e aggiungere una sezione [Peer] per il client, utilizzando la chiave pubblica del client ottenuta nel passaggio precedente.

[Peer]
PublicKey = # chiave pubblica del client WireGuard
AllowedIPs = # indirizzo IP interno del client

Nella configurazione del server, AllowedIPs ha due funzioni. Indica al server quale indirizzo del tunnel appartiene a questo client e agisce come elenco di routing: ogni pacchetto indirizzato a tali intervalli viene cifrato e inviato a questo peer. Per un singolo client si tratta del suo indirizzo del tunnel, ad esempio 10.0.0.2/32. Se il client deve rendere raggiungibile anche una rete locale attraverso il tunnel, aggiungere qui anche quella subnet, ad esempio 10.0.0.2/32, 192.168.1.0/24. Ripetere questo passaggio per ogni client aggiuntivo.

Configurazione di Windows Firewall sul server

Il server deve accettare il traffico WireGuard in entrata sulla propria porta UDP. Aprire Windows Defender Firewall con sicurezza avanzata, selezionare Regole connessioni in entrata e fare clic su Nuova regola. Scegliere Porta e fare clic su Avanti. Selezionare UDP, inserire la porta di WireGuard, ad esempio 51820, e fare clic su Avanti. Se si usa più di una porta, elencarle separate da virgole, ad esempio 51820, 51821. Selezionare Consenti la connessione e fare clic su Avanti. Selezionare i profili a cui si applica la regola. Se il server è ospitato in un data center, di norma è sufficiente il profilo Pubblico; altrimenti lasciare selezionati i profili Dominio, Privato e Pubblico. Fare clic su Avanti, assegnare alla regola un nome chiaro come WireGuard UDP 51820 e fare clic su Fine.

Questa regola in entrata è necessaria solo sul server, perché è il lato che riceve le connessioni in entrata. Su un VPS, assicurarsi inoltre che il provider di hosting consenta il traffico UDP in entrata su questa porta a livello di rete, non solo in Windows Firewall.

Esportazione e distribuzione delle configurazioni

Quando entrambe le configurazioni sono pronte, fare clic su Export all tunnels to zip, scegliere una posizione e salvare.

Aprire l'archivio per trovare i file di configurazione di tutti i tunnel. Posizionare la configurazione del server sul server e fornire a ciascun client il proprio file di configurazione. Se il computer contiene molti tunnel, è possibile esportare un singolo tunnel anche dal suo menu contestuale. L'esportazione in un file zip è comoda quando entrambi i tunnel sono stati creati sullo stesso computer, come in questa guida. Se si crea ciascuna configurazione direttamente sul proprio host, l'esportazione non è necessaria ed è possibile copiare il file di configurazione manualmente.

Sul server, selezionare la configurazione del server e fare clic su Activate.

Sul client, fare clic su Add Tunnel, selezionare il file di configurazione del client e aprirlo.

Quindi fare clic su Activate.

Il primo client è ora configurato. Aggiungere altri client allo stesso modo: creare un nuovo tunnel vuoto per ciascun client e aggiungere alla configurazione del server una sezione [Peer] corrispondente con la chiave pubblica e l'indirizzo del tunnel di quel client, come descritto in «Aggiunta del client al server».

Verifica della connessione

Dopo l'attivazione del tunnel, Windows può mostrare l'adattatore WireGuard come «Nessun accesso alla rete» o «Nessun accesso a Internet» nel Centro connessioni di rete e condivisione. Si tratta di un comportamento previsto, perché Windows non considera gli adattatori dei tunnel VPN come normali connessioni Internet, e non influisce sul tunnel. Windows determina questo stato con il proprio controllo di connettività, che interroga specifici URL di Microsoft; l'avviso può quindi comparire anche se tali richieste sono bloccate o non vengono risolte dal DNS, anche quando il tunnel funziona.

Per verificare il funzionamento del tunnel, controllarne lo stato nel client WireGuard. Un tunnel attivo mostra lo stato Active insieme ai contatori di trasferimento dati. Se i contatori aumentano, il tunnel sta trasportando traffico.

Sul server è inoltre possibile verificare che WireGuard sia in ascolto sulla propria porta UDP mentre il tunnel è attivo:

netstat -ano | findstr 51820

In PowerShell il comando equivalente è:

Get-NetUDPEndpoint -LocalPort 51820

Sostituire 51820 con la porta di WireGuard in uso. Se non viene restituito nulla, il tunnel non è attivo oppure la porta è diversa da quella impostata nella configurazione del server.

Successivamente, aprire il Prompt dei comandi ed eseguire il ping all'indirizzo interno del tunnel del server:

ping 10.0.0.1

Sostituire 10.0.0.1 con l'IP interno effettivamente impostato per il server. Se il server risponde, il traffico passa attraverso il tunnel. In assenza di risposta, controllare prima l'handshake: Windows Firewall su Windows Server blocca per impostazione predefinita il ping in entrata, quindi la mancata risposta non significa sempre che il tunnel sia inattivo.

Se il client usa AllowedIPs = 0.0.0.0/0, è anche possibile verificare che il traffico venga instradato attraverso il tunnel:

tracert 8.8.8.8

Il primo hop dovrebbe essere l'indirizzo IP interno del server WireGuard.

Verifica dell'handshake di WireGuard

L'handshake è l'indicatore più utile per diagnosticare una connessione WireGuard. Nell'applicazione WireGuard, aprire il tunnel e osservare il campo Latest handshake. In un tunnel funzionante l'handshake compare entro pochi secondi dall'attivazione e poi si aggiorna periodicamente durante il trasferimento di dati. Se il tunnel è inattivo, può trascorrere del tempo tra un handshake e l'altro, quindi una breve pausa è normale. Se il campo rimane vuoto, i peer non riescono a raggiungersi, il che di solito indica un Endpoint errato, una porta UDP chiusa o chiavi non corrispondenti.

L'handshake può essere verificato anche dalla riga di comando con lo strumento wg fornito con WireGuard:

wg show

L'output elenca ogni peer insieme all'ora dell'ultimo handshake e ai contatori di trasferimento.

Comprendere AllowedIPs

Il valore AllowedIPs nella configurazione del client stabilisce quale traffico viene inviato attraverso il tunnel. In breve, sul client AllowedIPs stabilisce quali pacchetti vengono inviati nel tunnel, mentre sul server stabilisce quali pacchetti vengono accettati da un determinato client e dove vengono instradati.

Il valore 0.0.0.0/0 instrada tutto il traffico attraverso il tunnel, inclusa la normale navigazione Internet. Usarlo quando si desidera una protezione completa del traffico. Perché questo traffico raggiunga Internet, il server deve tradurlo. Vedere «Configurazione del NAT sul server per il full tunneling» più avanti.

Un valore come 10.0.0.0/24 instrada attraverso il tunnel solo il traffico della rete interna, mentre il normale traffico Internet continua a usare la connessione ordinaria. Usarlo quando serve accedere solo a risorse specifiche della rete remota.

È possibile elencare più subnet separate da virgole, ad esempio 10.0.0.0/24, 192.168.1.0/24.

Accesso alla rete locale mentre il tunnel è attivo

Con uno split tunnel, ad esempio AllowedIPs = 10.0.0.0/24, la rete locale continua a funzionare normalmente e non occorre modificare nulla. I passaggi seguenti si applicano a un full tunnel.

L'opzione più semplice è deselezionare la casella Block untunneled traffic (kill-switch) nell'editor del tunnel del client. L'editor sostituisce 0.0.0.0/0 con 0.0.0.0/1, 128.0.0.0/1. La subnet locale, ad esempio 192.168.1.0/24, dispone di una route più specifica attraverso l'adattatore fisico, quindi Windows invia il traffico della LAN direttamente alla rete locale, mentre il traffico Internet passa comunque attraverso il tunnel. Il compromesso è che nulla blocca il traffico se il tunnel si interrompe.

Per essere certi che il traffico della LAN non entri mai nel tunnel, escludere esplicitamente l'intervallo locale da AllowedIPs. Ad esempio, il valore seguente copre ogni indirizzo IPv4 tranne 192.168.0.0/16:

AllowedIPs = 0.0.0.0/1, 128.0.0.0/2, 192.0.0.0/9, 192.128.0.0/11, 192.160.0.0/13, 192.169.0.0/16, 192.170.0.0/15, 192.172.0.0/14, 192.176.0.0/12, 192.192.0.0/10, 193.0.0.0/8, 194.0.0.0/7, 196.0.0.0/6, 200.0.0.0/5, 208.0.0.0/4, 224.0.0.0/3

Se la rete locale usa un intervallo diverso, come 10.x.x.x o 172.16.x.x, calcolare l'elenco per quell'intervallo con un calcolatore di AllowedIPs e assicurarsi che la subnet del tunnel sia ancora inclusa. Poiché questo valore non contiene una route /0, il kill-switch non è disponibile con esso.

Info Evitare di usare la stessa subnet per il tunnel e per la rete locale. Se la rete domestica è 10.0.0.0/24, scegliere un altro intervallo per il tunnel, ad esempio 10.8.0.0/24.

Per raggiungere una rete dietro il server, ad esempio una LAN aziendale 192.168.10.0/24, il server non richiede alcuna voce aggiuntiva, perché dispone già di una route verso la propria LAN. Sul client, aggiungerla ad AllowedIPs nella sezione [Peer], ad esempio AllowedIPs = 10.0.0.0/24, 192.168.10.0/24. Il server deve inoltre inoltrare e tradurre questo traffico, vedere «Configurazione del NAT sul server per il full tunneling». I dispositivi di quella LAN rispondono all'indirizzo LAN del server, quindi il NAT sul server è il modo più semplice per far tornare le risposte attraverso il tunnel.

Configurazione del NAT sul server per il full tunneling

Se i client usano AllowedIPs = 0.0.0.0/0 e si desidera che il loro traffico raggiunga effettivamente Internet attraverso il server, quest'ultimo deve tradurre gli indirizzi interni di WireGuard nel proprio indirizzo esterno. In Windows questo si ottiene con il comando New-NetNat, non con gli script PostUp e PostDown usati in Linux.

Aprire PowerShell come amministratore sul server ed eseguire quanto segue, usando la subnet del tunnel assegnata al server:

New-NetNat -Name WireGuardNAT -InternalIPInterfaceAddressPrefix 10.0.0.0/24

Sostituire 10.0.0.0/24 con la subnet del proprio tunnel e assicurarsi che il prefisso copra tutti gli indirizzi dei client assegnati. Un client al di fuori di questo intervallo, ad esempio 10.0.1.2, non verrebbe intercettato da questa regola. È possibile consultare le regole attive in qualsiasi momento:

Get-NetNat

Per rimuovere in seguito la regola NAT, eseguire:

Remove-NetNat -Name WireGuardNAT

Se i client si connettono e l'handshake riesce, ma il loro traffico Internet continua a non passare attraverso il server, abilitare l'inoltro IP sulle interfacce coinvolte nel routing e riprovare. La forma esatta dipende dalla versione di Windows, ad esempio:

Set-NetIPInterface -InterfaceAlias "Ethernet" -Forwarding Enabled

Applicarlo all'interfaccia esterna che trasporta il traffico Internet e all'interfaccia WireGuard, usando i loro nomi reali ricavati da Get-NetIPInterface.

Risoluzione dei problemi

Il tunnel è attivo ma non c'è connessione al server. Verificare che la porta UDP di WireGuard, ad esempio 51820, sia aperta nel firewall del server. Controllare che le chiavi pubbliche siano state copiate correttamente tra le configurazioni del server e del client. Assicurarsi che l'Endpoint nella configurazione del client punti all'effettivo indirizzo IP pubblico del server, non all'indirizzo interno del tunnel.

Il DNS non funziona dopo la connessione. Aggiungere un server DNS alla sezione Interface del client:

[Interface]
PrivateKey = ...
Address = ...
DNS = 1.1.1.1, 1.0.0.1

I contatori dei pacchetti non aumentano. Il tunnel non trasferisce dati. Verificare che AllowedIPs sia impostato correttamente su entrambi i lati, che gli indirizzi interni di WireGuard non siano in conflitto con la rete locale esistente e che ListenPort non sia già utilizzata da un'altra applicazione.

La casella del kill-switch non si deseleziona. L'editor riscrive AllowedIPs solo quando riesce a leggere l'intera configurazione. Verificare che la sezione [Peer] contenga una chiave pubblica valida copiata dal server e che ogni impostazione si trovi su una riga separata, quindi riprovare.

Servono maggiori dettagli per diagnosticare un problema. Aprire il tunnel nell'applicazione WireGuard e consultare la scheda Log, che registra in tempo reale handshake, errori ed eventi di connessione. Da lì è possibile esportare il registro se occorre condividerlo.

Avvio automatico di WireGuard dopo il riavvio del server

Per mantenere il tunnel in esecuzione dopo i riavvii, installarlo come servizio di Windows. Quando un tunnel è installato come servizio, si avvia automaticamente dopo un riavvio. Aprire il Prompt dei comandi o PowerShell come amministratore ed eseguire quanto segue, usando il percorso del file di configurazione del server:

wireguard /installtunnelservice "C:\Program Files\WireGuard\wg_server.conf"

Eseguire questo comando una sola volta, non a ogni avvio. L'attivazione del tunnel dall'applicazione WireGuard di norma installa lo stesso servizio, quindi in molti casi è sufficiente attivarlo una volta. Per rimuovere il servizio in seguito, usare il nome del tunnel, ovvero il nome del file di configurazione senza l'estensione .conf.

wireguard /uninstalltunnelservice wg_server

Per riavviare il servizio, ad esempio dopo aver modificato la configurazione, eseguire il comando di disinstallazione seguito nuovamente dal comando di installazione.

Riavviare il server e verificare che il tunnel si avvii automaticamente.