Configurazione del server WireGuard su Linux (wg0, NAT, peer)

Esegui un server WireGuard quando desideri un accesso privato all’infrastruttura ospitata senza esporre le porte di amministrazione alla rete Internet pubblica. Utilizza l’autenticazione a chiave pubblica, funziona all’interno del kernel Linux a partire dalla versione 5.6 e, una volta avviato, non interferisce con il resto del sistema. Questo articolo spiega quando utilizzare un server WireGuard, come avviarlo wg0e come garantire il corretto funzionamento quotidiano dei peer.

Quando utilizzare un server WireGuard

Tre modelli coprono la maggior parte delle configurazioni: accesso remoto, collegamenti da server a server e routing da sito a sito.

Per l’accesso remoto, esegui il server su un VPS o un host dedicato e instrada il traffico amministrativo attraverso il tunnel. Imposta AllowedIPs su ciascun peer la sottorete di gestione privata (ad esempio 10.0.0.0/24) in modo che solo il traffico destinato ai sistemi interni utilizzi il tunnel. Tutto il resto rimane sulla connessione locale dell’utente. Se gli utenti si connettono da casa o da reti mobili, aggiungere PersistentKeepalive = 25 sul lato client per impedire che le sessioni NAT vengano interrotte.

Per i collegamenti da server a server, mantenere AllowedIPs ristretto. Di solito è sufficiente una singola /32 o una piccola sottorete di backend. Ciò evita di convogliare nel tunnel traffico non correlato e mantiene il routing prevedibile.

Il sito-a-sito è diverso. L’host WireGuard funge da gateway tra le sottoreti, quindi l’inoltro IP deve essere abilitato e le regole NAT devono instradare il traffico di ritorno attraverso l’interfaccia corretta.

Configurazione del server

Il server custodisce la chiave privata, è in ascolto su UDP 51820 per impostazione predefinita e termina il tunnel. La stessa configurazione di base funziona per tutti e tre gli schemi sopra indicati.

Chiavi e wg0.conf

Generare la coppia di chiavi del server:

wg genkey | sudo tee /etc/wireguard/server_private.key | wg pubkey | sudo tee /etc/wireguard/server_public.key

Metti al sicuro la chiave privata:

sudo chmod 600 /etc/wireguard/server_private.key

La chiave privata rimane sul server. La chiave pubblica è quella che si fornisce ai peer.

Creare /etc/wireguard/wg0.conf:

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <SERVER_PRIVATE_KEY>
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o <PUBLIC_IFACE> -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o <PUBLIC_IFACE> -j MASQUERADE
 
[Peer]
PublicKey = <CLIENT_PUBLIC_KEY>
AllowedIPs = 10.8.0.2/32

Individuare l'interfaccia in uscita su cui inserire <PUBLIC_IFACE> utilizzando:

ip -o -4 route show to default | awk '{print $5}'

Inoltro, firewall e NAT

Apri la porta di ascolto:

sudo ufw allow 51820/udp

Abilita l'inoltro IP aggiungendo questa riga a /etc/sysctl.conf:

net.ipv4.ip_forward = 1

Applica senza riavviare:

sudo sysctl -p

Il PostUp e PostDown linee in wg0.conf aggiungono e rimuovono la regola di mascheramento NAT quando l'interfaccia viene attivata o disattivata. Senza di esse, il traffico di ritorno dalla LAN non riesce mai a tornare al peer.

L'attivazione del tunnel

wg-quick gestisce l'interfaccia, l'instradamento e gli PostUp/PostDown hook in un unico comando:

sudo wg-quick up wg0

Per l'avvio automatico dopo il riavvio, abilitare l'unità systemd:

sudo systemctl enable --now wg-quick@wg0

Verificare lo stato con:

sudo wg show

Una riga recente latest handshake riferisce che il tunnel è attivo. Se appare obsoleta o vuota, controllare il firewall, le chiavi su entrambi i lati e il peer AllowedIPs.

Aggiunta e rimozione di peer

Ogni peer necessita di una propria coppia di chiavi. Generarla sul client, quindi aggiungere la chiave pubblica del peer wg0.conf in un nuovo [Peer] blocco con una AllowedIPs voce che gli assegni il proprio IP del tunnel.

Utilizzare /32 per un singolo dispositivo:

AllowedIPs = 10.8.0.3/32

In questo modo si impedisce a un peer di rivendicare indirizzi assegnati a un altro. Per l'accesso con tunnel parziale, elencare solo le sottoreti private che devono passare attraverso il tunnel, ad esempio AllowedIPs = 10.8.0.0/24.

Applica le modifiche alla configurazione senza interrompere le sessioni attive:

sudo wg syncconf wg0 <(wg-quick strip wg0)

La rimozione di un peer funziona allo stesso modo. Eliminare il relativo [Peer] blocco da wg0.conf ed eseguire syncconf di nuovo.

Risoluzione dei problemi

Se un peer si connette ma non riesce a raggiungere alcuna risorsa dall’altra parte, la causa è solitamente una delle quattro seguenti:

• L'inoltro IP è disattivato
• Manca la regola di mascheramento NAT
• L'interfaccia in uscita nella regola NAT è errata
• AllowedIPs non include la destinazione

Verificare l'inoltro:

cat /proc/sys/net/ipv4/ip_forward

Dovrebbe restituire 1. Se restituisce 0, la modifica di sysctl non è stata applicata o non è stata salvata.

Verificare la regola NAT e l'interfaccia in uscita:

sudo iptables -t nat -L POSTROUTING
ip route get 1.1.1.1

Il secondo comando mostra il nome effettivo dell'interfaccia in uscita, ad esempio ens3, enp1s0, oppure eth0. Questo deve corrispondere all’interfaccia specificata nella regola MASQUERADE.

Se manca l’handshake stesso, verificare che la porta UDP 51820 sia aperto sul firewall e presso qualsiasi provider a monte, e che entrambe le parti dispongano della chiave pubblica corretta dell’altra.

Per i peer dietro un NAT residenziale o mobile che interrompe le sessioni UDP inattive, impostare PersistentKeepalive = 25 sul client.

Rotazione delle chiavi e chiavi pre-condivise

Per i tunnel che rimangono attivi per mesi, ruotare le chiavi circa una volta all’anno. Generare una nuova coppia di chiavi, aggiornare entrambe le estremità e applicare con wg syncconf. Non riutilizzare una chiave privata su due peer. Ciò crea conflitti di routing e interrompe la trasmissione tra di essi.

Per un ulteriore livello di sicurezza oltre all’autenticazione a chiave pubblica, aggiungere una chiave pre-condivisa per ogni peer:

wg genpsk

Aggiungere il risultato come PresharedKey = <PSK> nel [Peer] blocco su entrambe le parti. WireGuard integra la PSK nell’handshake, quindi un malintenzionato che in qualche modo comprometta una delle chiavi asimmetriche non potrà comunque decriptare il traffico senza di essa.

Comandi utili per l’uso quotidiano:

Se hai bisogno di un host stabile e accessibile pubblicamente per terminare i tunnel WireGuard e instradare il traffico privato nella tua infrastruttura, dai un'occhiata ai piani VPS illimitati di FDC.