Come configurare WireGuard su Ubuntu

Introduzione

WireGuard è una rete privata virtuale (VPN) leggera che supporta sia connessioni IPv4 che IPv6. Una VPN ti permette di attraversare reti non affidabili come se fossi su una rete privata. Ti offre la possibilità di accedere a Internet in modo più sicuro da dispositivi come laptop o telefoni cellulari quando sei connesso a reti non affidabili, comprese le reti WiFi pubbliche.

La crittografia di WireGuard si basa su chiavi pubbliche e private affinché i peer possano stabilire tunnel criptati tra di loro. Ogni versione di WireGuard utilizza un insieme fisso di metodi crittografici moderni, il che aiuta a mantenere il protocollo semplice e prevedibile. Questo design evita negoziazioni a runtime e riduce il rischio di errori di configurazione.

In confronto, altri software VPN come OpenVPN e IPsec si basano su Transport Layer Security e certificati per autenticare e stabilire tunnel crittografati. Sebbene questo approccio offra flessibilità e supporti un'ampia gamma di client, aumenta anche la complessità della configurazione e rende più difficile comprendere il comportamento operativo.

In questo tutorial, configurerai WireGuard su un server Ubuntu e configurerai un altro computer per connettersi ad esso come peer utilizzando sia IPv4 che IPv6, comunemente definito come configurazione dual-stack. Imparerai anche come instradare il traffico dei peer attraverso il server WireGuard in una configurazione gateway, oltre a come utilizzare la VPN per la comunicazione peer-to-peer crittografata.

Oltre alla configurazione di base, questa guida tratta argomenti pratici importanti per le implementazioni nel mondo reale. Questi includono la comprensione dell'architettura peer-to-peer di WireGuard, la gestione e la rotazione delle chiavi, la gestione corretta di IPv6 e del routing dual-stack, il miglioramento dell'affidabilità per i peer dietro NAT, l'ottimizzazione delle prestazioni e la comprensione di come WireGuard si confronta con OpenVPN in termini di protocolli di trasporto e comportamento del firewall.

Ai fini di questo tutorial, un altro sistema Ubuntu viene utilizzato come Peer di WireGuard. I tutorial successivi di questa serie coprono l'installazione e l'uso di WireGuard su Windows, macOS, Android e iOS.

Prerequisiti

Per seguire questo tutorial, avrai bisogno di:

• Un server Ubuntu con un utente sudo non root e un firewall abilitato. Per configurarlo, puoi seguire il nostro tutorial Configurazione Iniziale del Server con Ubuntu. Faremo riferimento a questo come il Server WireGuard in tutta la guida.

• Avrai bisogno di una macchina client che utilizzerai per connetterti al tuo server WireGuard. In questo tutorial ci riferiremo a questa macchina come al Peer WireGuard. Ai fini di questo tutorial, è consigliato utilizzare la tua macchina locale come Peer WireGuard, ma puoi usare server remoti o telefoni cellulari come client se preferisci. Se stai usando un sistema remoto, assicurati di seguire tutte le sezioni opzionali più avanti in questo tutorial, altrimenti potresti bloccarti fuori dal sistema.

• Per utilizzare WireGuard con IPv6, dovrai anche assicurarti che il tuo server sia configurato per supportare quel tipo di traffico. Se desideri abilitare il supporto IPv6 con WireGuard e stai utilizzando un Droplet di Linux-Console.net, consulta questa pagina della documentazione Come Abilitare IPv6 sui Droplet. Puoi aggiungere il supporto IPv6 durante la creazione di un Droplet, o successivamente seguendo le istruzioni presenti in quella pagina.

Panoramica dell'architettura di WireGuard

Prima di configurare WireGuard, è utile capire come interagiscono sistemi, peer e traffico di rete. WireGuard utilizza un'architettura volutamente semplice che evita piani di controllo, autorità di certificazione e negoziazione in tempo reale dei parametri di configurazione. Tutti i comportamenti di crittografia, autenticazione e instradamento sono definiti esplicitamente tramite file di configurazione.

Terminologia della progettazione e topologia Peer-to-Peer

WireGuard è fondamentalmente un protocollo peer-to-peer. Lo stesso software WireGuard e il modulo del kernel funzionano su tutti i sistemi partecipanti, e non esiste un binario server o client distinto.

In questo tutorial, il termine WireGuard Server si riferisce a un hub centrale in una topologia a stella. Questo sistema è accessibile pubblicamente e agisce come punto di coordinamento per altri peer. Il termine WireGuard Peer si riferisce ai dispositivi che si collegano a questo hub. Questi termini descrivono la topologia di rete utilizzata in questa guida, non ruoli o funzionalità software differenti.

Comprendere questa distinzione è importante perché WireGuard non ha opzioni di configurazione solo per il server. Qualsiasi sistema può fungere da hub, da spoke o da entrambi, a seconda di come sono definiti le chiavi, gli indirizzi e le regole di instradamento.

Componenti principali in una distribuzione di WireGuard

Un deployment di WireGuard consiste in un piccolo numero di componenti chiaramente definiti, ciascuno con una responsabilità specifica.

• Peer Centrale (Hub): Il peer centrale è un sistema raggiungibile pubblicamente che ascolta il traffico UDP criptato su una singola porta. Ospita un'interfaccia virtuale di tunnel, comunemente chiamata wg0, e memorizza le chiavi pubbliche degli altri peer autorizzati a comunicare con esso. L'hub non rileva dinamicamente i peer né accetta connessioni implicitamente. Il traffico è accettato solo dai peer le cui chiavi pubbliche e intervalli IP consentiti sono configurati esplicitamente.

• Connessione dei Peer (Spoke): I peer connessi sono dispositivi che stabiliscono tunnel criptati con il peer centrale. Questi dispositivi possono essere laptop, server, macchine virtuali o sistemi mobili. Ogni peer ha una coppia di chiavi crittografiche unica e uno o più indirizzi IP privati assegnati alla sua interfaccia tunnel. Un peer invia traffico nel tunnel solo quando le sue regole di instradamento gli indicano di farlo.

• Interfaccia Tunnel (wg0): L'interfaccia tunnel è un dispositivo di rete virtuale creato su ciascun sistema partecipante. Tutto il traffico criptato entra ed esce attraverso questa interfaccia. Dal punto di vista del sistema operativo, wg0 si comporta come un'interfaccia di rete standard, il che consente di applicare normali tabelle di routing, regole del firewall e comportamenti di inoltro.

Crittografia, Autenticazione e Stretta di mano

WireGuard utilizza la crittografia a chiave pubblica per autenticare i peer e criptare il traffico. Ogni peer genera una chiave privata a lungo termine che rimane sul sistema locale e non viene mai trasmessa. La corrispondente chiave pubblica viene condivisa con gli altri peer e aggiunta alle loro configurazioni.

Quando la comunicazione inizia, WireGuard esegue un handshake crittografico silenzioso e automatico basato sul framework del protocollo Noise. Questo handshake stabilisce chiavi di sessione effimere e garantisce la Segretezza Totale Avanzata (Perfect Forward Secrecy). Queste chiavi di sessione vengono ruotate periodicamente senza intervento dell'utente.

WireGuard non negozia suite di cifratura, metodi di autenticazione o versioni del protocollo. Tutti gli elementi crittografici sono fissi per progettazione. Questo elimina un'intera classe di errori di configurazione pur garantendo una sicurezza moderna.

Tipologie di flusso di traffico supportate

WireGuard supporta diversi schemi di traffico a seconda di come sono configurati il routing e l'inoltro. Questo tutorial si concentra sui due casi d'uso più comuni.

Accesso Peer-to-Peer o Rete Interna

In una configurazione peer-to-peer o di accesso interno, il traffico è criptato solo tra i sistemi che fanno parte della VPN. Il peer centrale funge da punto finale sicuro o da relè, ma non inoltra il traffico verso reti esterne.

Questa configurazione è tipicamente utilizzata per accedere a servizi privati, amministrare l'infrastruttura o connettere sistemi isolati. Il traffico viene instradato nel tunnel solo quando l'indirizzo di destinazione corrisponde agli intervalli di IP privati definiti nella configurazione del peer.

Modalità Gateway VPN

In modalità gateway, il peer centrale inoltra il traffico dagli altri peer verso reti esterne, incluso Internet pubblico. I peer inviano parte o tutto il loro traffico nel tunnel, e il peer centrale instrada quel traffico utilizzando l'inoltro IP e la traduzione degli indirizzi di rete.

Questa configurazione richiede impostazioni di sistema aggiuntive, inclusi il forwarding del kernel e le regole del firewall. Quando la modalità gateway è attivata, il traffico in uscita dai peer appare come proveniente dall'indirizzo IP pubblico del peer centrale.

Il duplice ruolo di AllowedIPs

La direttiva AllowedIPs serve a due scopi distinti in WireGuard.

Per prima cosa, definisce il comportamento del routing in uscita. Quando l’indirizzo di destinazione di un pacchetto corrisponde a una voce in AllowedIPs, quel pacchetto viene instradato attraverso il tunnel WireGuard.

In secondo luogo, AllowedIPs funge da elenco di controllo degli accessi in ingresso rigoroso. Quando un pacchetto viene ricevuto da un peer, WireGuard controlla l’indirizzo IP di origine del pacchetto. Se l’indirizzo di origine non è elencato in AllowedIPs di quel peer, il pacchetto viene scartato immediatamente.

Questo doppio ruolo è intenzionale ed è una delle cause più comuni di errori di configurazione. Il routing corretto da solo non è sufficiente. Gli indirizzi IP di origine che un peer è autorizzato a utilizzare devono essere esplicitamente consentiti.

Automazione del Routing e Strumenti di Supporto

Il modulo kernel di WireGuard non modifica le route di sistema, le impostazioni DNS o le regole del firewall. Si limita a criptare e decriptare i pacchetti e ad associarli ai peer.

L'automazione del routing è gestita da strumenti di supporto come wg-quick. Questa utility legge il file di configurazione di WireGuard e applica le voci necessarie nella tabella di routing, le impostazioni DNS e le regole del firewall quando un tunnel viene attivato o disattivato.

Se WireGuard è configurato utilizzando strumenti alternativi come i comandi raw wg, systemd-networkd o script personalizzati, queste modifiche di instradamento devono essere gestite manualmente.

Questa separazione mantiene il protocollo di base semplice pur consentendo un'integrazione flessibile con diverse stack di rete del sistema.

Passo 1 — Installazione di WireGuard e generazione di una coppia di chiavi

Il primo passo di questo tutorial è installare WireGuard sul tuo server. Per cominciare, aggiorna l'indice dei pacchetti del tuo server WireGuard e installa WireGuard utilizzando i seguenti comandi. Potrebbe esserti chiesto di inserire la password del tuo utente sudo se è la prima volta che usi sudo in questa sessione:

sudo apt update

sudo apt install wireguard

Ora che hai installato WireGuard, il passo successivo è generare una coppia di chiavi privata e pubblica per il server. Userai i comandi integrati wg genkey e wg pubkey per creare le chiavi e poi aggiungerai la chiave privata al file di configurazione di WireGuard.

Dovrai anche modificare i permessi della chiave che hai appena creato usando il comando chmod, poiché per impostazione predefinita il file è leggibile da qualsiasi utente sul tuo server.

Crea la chiave privata per WireGuard e modifica i suoi permessi utilizzando i seguenti comandi:

wg genkey | sudo tee /etc/wireguard/private.key

sudo chmod go= /etc/wireguard/private.key

Il comando sudo chmod go=... rimuove qualsiasi permesso sul file per utenti e gruppi diversi dall'utente root, per garantire che solo quest'ultimo possa accedere alla chiave privata.

Dovresti ricevere una singola linea di output codificata in base64, che rappresenta la chiave privata. Una copia dell'output viene anche salvata nel file /etc/wireguard/private.key per un riferimento futuro tramite la parte tee del comando. Fai attenzione a prendere nota della chiave privata mostrata, poiché sarà necessario aggiungerla al file di configurazione di WireGuard più avanti in questa sezione.

Il passo successivo è creare la corrispondente chiave pubblica, che viene derivata dalla chiave privata. Usa il seguente comando per creare il file della chiave pubblica:

sudo cat /etc/wireguard/private.key | wg pubkey | sudo tee /etc/wireguard/public.key

Questo comando consiste di tre comandi individuali collegati insieme usando l'operatore | (pipe):

• sudo cat /etc/wireguard/private.key: questo comando legge il file della chiave privata e lo invia allo stream di output standard.
• wg pubkey: il secondo comando prende l'output del primo comando come input standard e lo elabora per generare una chiave pubblica.
• sudo tee /etc/wireguard/public.key: il comando finale prende l'output del comando di generazione della chiave pubblica e lo reindirizza nel file denominato /etc/wireguard/public.key.

Quando esegui il comando, riceverai nuovamente una singola riga di output codificata in base64, che rappresenta la chiave pubblica del tuo server WireGuard. Copiala da qualche parte come riferimento, poiché dovrai distribuire la chiave pubblica a qualsiasi peer che si connetta al server.

Fase 2 — Scelta degli indirizzi IPv4 e IPv6

Nella sezione precedente hai installato WireGuard e generato una coppia di chiavi che verrà utilizzata per criptare il traffico da e verso il server. In questa sezione, creerai un file di configurazione per il server e configurerai WireGuard in modo che si avvii automaticamente quando il server viene riavviato. Definirai inoltre indirizzi IPv4 e IPv6 privati da utilizzare con il tuo server WireGuard e i peer.

Se prevedi di utilizzare sia indirizzi IPv4 che IPv6, segui entrambe queste sezioni. Altrimenti, segui le istruzioni nella sezione appropriata in base alle esigenze di rete della tua VPN.

Fase 2(a) — Scelta di un intervallo IPv4

Se stai utilizzando il tuo server WireGuard con peer IPv4, il server ha bisogno di un intervallo di indirizzi IPv4 privati da utilizzare per i client e per la sua interfaccia tunnel. Puoi scegliere qualsiasi intervallo di indirizzi IP dai seguenti blocchi di indirizzi riservati (se desideri saperne di più su come questi blocchi sono allocati, visita la specifica RFC 1918):

• 10.0.0.0 a 10.255.255.255 (prefisso 10/8)
• 172.16.0.0 a 172.31.255.255 (prefisso 172.16/12)
• 192.168.0.0 a 192.168.255.255 (prefisso 192.168/16)

Ai fini di questo tutorial useremo 10.8.0.0/24 come blocco di indirizzi IP dal primo intervallo di IP riservati. Questo intervallo permetterà fino a 255 connessioni peer differenti e, in generale, non dovrebbe avere indirizzi sovrapposti o conflittuali con altri intervalli di IP privati. Sentiti libero di scegliere un intervallo di indirizzi che funzioni con la configurazione della tua rete se questo intervallo di esempio non è compatibile con le tue reti.

Il server WireGuard utilizzerà un singolo indirizzo IP dal range per il suo indirizzo IPv4 del tunnel privato. Qui useremo 10.8.0.1/24, ma può essere utilizzato qualsiasi indirizzo nel range da 10.8.0.1 a 10.8.0.255. Prendi nota dell'indirizzo IP che scegli se utilizzi qualcosa di diverso da 10.8.0.1/24. Aggiungerai questo indirizzo IPv4 al file di configurazione che definisci in Creazione di una configurazione del server WireGuard.

Fase 2(b) — Scelta di un intervallo IPv6

Se stai usando WireGuard con IPv6, allora dovrai generare un prefisso di indirizzo unicast IPv6 locale unico basato sull'algoritmo descritto nella RFC 4193. Gli indirizzi che utilizzi con WireGuard saranno associati a un'interfaccia tunnel virtuale. Dovrai completare alcuni passaggi per generare un prefisso IPv6 casuale e unico all'interno del blocco riservato fd00::/8 di indirizzi privati IPv6.

Secondo l'RFC, il modo consigliato per ottenere un prefisso IPv6 unico è combinare l'orario con un valore identificativo unico proveniente da un sistema come un numero di serie o un ID dispositivo. Questi valori vengono poi hashati e troncati, risultando in un insieme di bit che possono essere usati come indirizzo unico all'interno del blocco di IP riservato privato fd00::/8.

Per iniziare a generare un intervallo IPv6 per il tuo server WireGuard, raccogli un timestamp a 64 bit utilizzando l'utilità date con il seguente comando:

date +%s%N

Riceverai un numero come il seguente, che rappresenta il numero di secondi (il %s nel comando date) e i nanosecondi (il %N) trascorsi dal 1970-01-01 00:00:00 UTC combinati insieme:

1628101352127592197

Registra il valore da qualche parte per utilizzarlo più avanti in questa sezione. Successivamente, copia il valore machine-id del tuo server dal file /var/lib/dbus/machine-id. Questo identificatore è unico per il tuo sistema e non dovrebbe cambiare finché il server esiste.

cat /var/lib/dbus/machine-id

Riceverai un output simile al seguente:

/var/lib/dbus/machine-id
20086c25853947c7aeee2ca1ea849d7d

Ora devi combinare il timestamp con il machine-id e hashare il valore risultante utilizzando l'algoritmo SHA-1. Il comando utilizzerà il seguente formato:

printf <timestamp><machine-id> | sha1sum

Esegui il comando sostituendo i valori del timestamp e dell'identità della macchina:

printf 162810135212759219720086c25853947c7aeee2ca1ea849d7d | sha1sum

Riceverai un valore hash simile al seguente:

4f267c51857d6dc93a0bca107bca2f0d86fac3bc  -

Nota che l'output del comando sha1sum è in esadecimale, quindi l'output utilizza due caratteri per rappresentare un singolo byte di dati. Ad esempio, 4f e 26 nell'output di esempio sono i primi due byte dei dati hashati.

L'algoritmo nell'RFC richiede solo i 40 bit meno significativi (finali), o 5 byte, dell'output hashato. Usa il comando cut per stampare gli ultimi 5 byte codificati in esadecimale dall'hash:

printf 4f267c51857d6dc93a0bca107bca2f0d86fac3bc | cut -c 31-

L'argomento -c indica al comando cut di selezionare solo un insieme specifico di caratteri. L'argomento 31- dice a cut di stampare tutti i caratteri dalla posizione 31 fino alla fine della linea di input.

Dovresti ricevere un output simile al seguente:

0d86fac3bc

In questo esempio di output, il set di byte è: 0d 86 fa c3 bc.

Ora puoi costruire il tuo prefisso di rete IPv6 unico aggiungendo i 5 byte che hai generato con il prefisso fd, separando ogni 2 byte con due punti : per renderlo più leggibile. Poiché ogni sottorete del tuo prefisso unico può contenere un totale di 18.446.744.073.709.551.616 indirizzi IPv6 possibili, puoi limitare la sottorete a una dimensione standard di /64 per semplicità.

Usando i byte precedentemente generati con la dimensione di subnet /64, il prefisso risultante sarà il seguente:

Unique Local IPv6 Address Prefix
fd0d:86fa:c3bc::/64

Questo intervallo fd0d:86fa:c3bc::/64 è quello che utilizzerai per assegnare indirizzi IP individuali alle interfacce del tunnel WireGuard sul server e sui peer. Per assegnare un IP al server, aggiungi un 1 dopo i caratteri finali ::. L'indirizzo risultante sarà fd0d:86fa:c3bc::1/64. I peer possono usare qualsiasi IP nell'intervallo, ma in genere incrementerai il valore di uno ogni volta che aggiungi un peer, ad esempio fd0d:86fa:c3bc::2/64. Prendi nota dell'IP e procedi a configurare il server WireGuard nella sezione successiva di questo tutorial.

Considerazioni sulla configurazione di IPv6 e Dual-Stack

I passaggi esistenti in questo tutorial spiegano come generare indirizzi IPv6 e assegnarli alle interfacce WireGuard. Tuttavia, il comportamento di IPv6 in WireGuard differisce in diversi modi importanti da quello di IPv4, soprattutto quando WireGuard viene utilizzato come gateway VPN. Comprendere queste differenze aiuta a prevenire guasti di instradamento, tunnel parziali e perdite comuni di IPv6.

Supporto IPv6 in WireGuard

WireGuard supporta l'IPv6 come protocollo di prima classe. Il traffico IPv6 viene cifrato, autenticato e instradato utilizzando gli stessi meccanismi del traffico IPv4. Non esiste una modalità IPv6 separata né un flag di configurazione aggiuntivo. Se agli indirizzi IPv6 viene assegnata un'interfaccia tunnel e le regole di routing lo consentono, il traffico IPv6 fluisce automaticamente attraverso il tunnel.

A differenza di IPv4, IPv6 è progettato per evitare il NAT utilizzando indirizzi instradabili a livello globale, ma nella pratica molti ambienti VPN e cloud continuano a usare il NAT per semplicità operativa. Tuttavia, questo comportamento dipende dall'ambiente di rete. In molte configurazioni di gateway VPN, come le istanze VPS cloud o i router domestici, il server non riceve un prefisso IPv6 delegato che possa essere instradato verso i peer VPN.

In questi scenari comuni, ai peer vengono assegnati indirizzi IPv6 privati, solitamente da un intervallo di Indirizzi Locali Unici (ULA). Quando vengono utilizzati indirizzi IPv6 privati e il server non ha un prefisso instradabile per essi, è comunque necessario il masquerading IPv6. Questo viene solitamente implementato con regole ip6tables -t nat, simili al masquerading IPv4, per consentire ai peer VPN di raggiungere Internet pubblico.

IPv6 può evitare completamente il NAT quando è disponibile una corretta delega dei prefissi. Tuttavia, la maggior parte delle implementazioni di gateway VPN semplici si affida ancora al masquerading IPv6 per mantenere gestibile il routing.

Comportamento Dual-Stack Spiegato

Una configurazione dual-stack consente sia IPv4 che IPv6 sulla stessa interfaccia WireGuard. In questo setup, all'interfaccia wg0 viene assegnato un indirizzo IPv4 e un indirizzo IPv6, e ciascun protocollo viene instradato in modo indipendente.

Il sistema operativo valuta separatamente le rotte IPv4 e IPv6. Un peer può instradare con successo il traffico IPv4 attraverso il tunnel mentre il traffico IPv6 lo bypassa, o viceversa. Questo comportamento è normale e quasi sempre indica un problema di configurazione piuttosto che un problema con WireGuard stesso.

Perché il routing dual-stack funzioni correttamente, devono essere soddisfatte diverse condizioni. Sia il server sia il peer devono avere indirizzi IPv4 e IPv6 assegnati alle loro interfacce WireGuard. La direttiva AllowedIPs deve includere sia gli intervalli IPv4 sia quelli IPv6. Il forwarding IP deve essere abilitato separatamente per IPv4 e IPv6. Le regole del firewall devono consentire il forwarding e il traffico di ritorno per entrambi i protocolli.

Assegnazione degli indirizzi e lunghezze del prefisso

Per IPv4, le implementazioni di WireGuard utilizzano tipicamente intervalli di indirizzi privati come 10.0.0.0/8 o 192.168.0.0/16. A ciascun peer viene comunemente assegnato un singolo indirizzo IPv4.

Per IPv6, è comune definire la rete VPN come un prefisso /64, come fd00::/64. Mentre le reti Ethernet richiedono un /64 per la scoperta dei vicini e l'autoconfigurazione degli indirizzi, WireGuard opera come un'interfaccia punto-punto a livello 3 e non utilizza questi meccanismi.

Per questo motivo, è sicuro e spesso consigliato assegnare a ciascun peer un indirizzo IPv6 /128, come fd00::2/128. L'utilizzo di indirizzi /128 garantisce un comportamento di instradamento rigoroso e impedisce ai peer di tentare di comunicare direttamente con altri indirizzi nella sottorete senza regole di instradamento appropriate.

Definire la rete come /64 assegnando ai peer indirizzi /128 fornisce chiarezza ed evita percorsi ambigui.

Instradamento di tutto il traffico con IPv6

Quando WireGuard è configurato come gateway VPN, il traffico IPv6 deve essere instradato esplicitamente allo stesso modo del traffico IPv4.

Per IPv4, il routing di tutto il traffico utilizza il prefisso 0.0.0.0/0. Per IPv6, il prefisso equivalente è ::/0. Entrambi i prefissi devono essere inclusi se l'obiettivo è instradare tutto il traffico tramite la VPN.

Se viene configurato solo 0.0.0.0/0, il traffico IPv4 viene inviato tramite la VPN mentre il traffico IPv6 continua a utilizzare l'interfaccia di rete locale. Questa situazione è nota come perdita di IPv6. Comunemente porta a query DNS, traffico web o connessioni di applicazioni che bypassano la VPN tramite IPv6 mentre il traffico IPv4 rimane protetto.

Le perdite di IPv6 sono una fonte frequente di confusione e dovrebbero sempre essere testate quando è abilitata la rete dual-stack.

Firewall, Inoltro e ICMPv6

Il forwarding IPv6 deve essere abilitato indipendentemente dal forwarding IPv4. Abilitare uno non abilita automaticamente l'altro. Entrambe le impostazioni sono necessarie quando si instrada il traffico tra interfacce.

Le regole del firewall devono essere definite anche esplicitamente per IPv6. Strumenti come ufw, iptables e nftables trattano IPv4 e IPv6 come set di regole separati. La mancanza di regole IPv6 può bloccare silenziosamente il traffico anche quando la connettività IPv4 sembra funzionare.

È particolarmente importante consentire il traffico ICMPv6. A differenza di IPv4, IPv6 dipende da ICMPv6 per funzioni essenziali come la scoperta della MTU del percorso (Path MTU Discovery). Se ICMPv6 viene bloccato, le connessioni possono bloccarsi o fallire quando vengono trasmessi pacchetti più grandi, anche se i pacchetti piccoli sembrano funzionare.

Errori Comuni del Dual-Stack

In molte implementazioni dual-stack di WireGuard si verificano comunemente diversi problemi. Le rotte IPv6 potrebbero essere assenti dalla direttiva AllowedIPs, causando il bypass del tunnel per il traffico IPv6. Il forwarding IPv6 potrebbe non essere abilitato sul server, impedendo al traffico di uscire dall'interfaccia del tunnel. Le regole del firewall potrebbero consentire il traffico IPv4 ma bloccare il traffico IPv6 o ICMPv6. I resolver DNS potrebbero restituire indirizzi IPv6 anche se il routing IPv6 non è configurato correttamente.

Questi problemi si manifestano spesso come guasti intermittenti e vengono frequentemente diagnosticati erroneamente come problemi dell'applicazione o del protocollo.

Scegliere tra IPv4 soltanto, IPv6 soltanto e Dual-Stack

In alcuni ambienti, usare un unico protocollo semplifica le operazioni.

Le distribuzioni solo IPv4 sono più facili da integrare con sistemi e strumenti legacy. Le distribuzioni solo IPv6 eliminano la necessità del NAT IPv4 e evitano l'esaurimento degli indirizzi, ma richiedono un supporto IPv6 coerente da parte dei provider e delle reti dei clienti.

Le implementazioni a doppio stack offrono la massima flessibilità, ma richiedono anche la pianificazione, la configurazione e la convalida più accurate.

Passo 3 — Creazione di una configurazione del server WireGuard

Prima di creare la configurazione del tuo server WireGuard, avrai bisogno delle seguenti informazioni:

• Assicurati di avere a disposizione la chiave privata da Installare WireGuard e Generare una Coppia di Chiavi.
• Se stai usando WireGuard con IPv4, avrai bisogno dell'indirizzo IP che hai scelto per il server in Scegliere un intervallo IPv4, che in questo esempio è 10.8.0.1/24.
• Se stai usando WireGuard con IPv6, avrai bisogno dell'indirizzo IP del server che hai generato in Scelta di un intervallo IPv6. In questo esempio l'IP è fd0d:86fa:c3bc::1/64.

Una volta ottenuta la chiave privata necessaria e l'indirizzo IP (o gli indirizzi IP), crea un nuovo file di configurazione utilizzando nano o il tuo editor preferito eseguendo il seguente comando:

sudo nano /etc/wireguard/wg0.conf

Aggiungi le seguenti righe al file, sostituendo la tua chiave privata al posto del valore evidenziato base64_encoded_private_key_goes_here, e l'indirizzo(i) IP sulla riga Address. Puoi anche modificare la riga ListenPort se desideri che WireGuard sia disponibile su una porta diversa:

/etc/wireguard/wg0.conf
[Interface]
PrivateKey = base64_encoded_private_key_goes_here
Address = 10.8.0.1/24, fd0d:86fa:c3bc::1/64
ListenPort = 51820
SaveConfig = true

La riga SaveConfig assicura che quando un'interfaccia WireGuard viene chiusa, tutte le modifiche vengano salvate nel file di configurazione.

Salva e chiudi il file /etc/wireguard/wg0.conf. Se stai usando nano, puoi farlo premendo CTRL+X, poi Y e INVIO per confermare. Ora hai una configurazione iniziale del server su cui puoi basarti a seconda di come intendi utilizzare il tuo server VPN WireGuard.

Fase 4 — Regolazione della configurazione di rete del server WireGuard

Se stai usando WireGuard per connettere un peer al server WireGuard al fine di accedere ai servizi presenti solo sul server, allora non è necessario completare questa sezione. Se desideri instradare il traffico Internet del tuo peer WireGuard attraverso il server WireGuard, dovrai configurare l’inoltro IP seguendo questa sezione del tutorial.

Per configurare l'inoltro, apri il file /etc/sysctl.conf utilizzando nano o l'editor che preferisci:

sudo nano /etc/sysctl.conf

Se stai usando IPv4 con WireGuard, aggiungi la seguente riga in fondo al file:

net.ipv4.ip_forward=1

Se stai usando IPv6 con WireGuard, aggiungi questa riga in fondo al file:

net.ipv6.conf.all.forwarding=1

Se stai utilizzando sia IPv4 che IPv6, assicurati di includere entrambe le righe. Salva e chiudi il file quando hai finito.

Per leggere il file e caricare i nuovi valori per la tua sessione terminale corrente, esegui:

sudo sysctl -p

net.ipv6.conf.all.forwarding = 1
net.ipv4.ip_forward = 1

Ora il tuo server WireGuard sarà in grado di inoltrare il traffico in arrivo dal dispositivo Ethernet virtuale VPN verso altri sul server, e da lì verso Internet pubblico. Utilizzando questa configurazione potrai instradare tutto il traffico web dal tuo Peer WireGuard tramite l'indirizzo IP del server, e l'indirizzo IP pubblico del tuo client sarà effettivamente nascosto.

Tuttavia, prima che il traffico possa essere instradato correttamente tramite il tuo server, dovrai configurare alcune regole del firewall. Queste regole garantiranno che il traffico da e verso il tuo server e i peer WireGuard scorra correttamente.

Passo 5 — Configurazione del firewall del server WireGuard

In questa sezione modificherai la configurazione del server WireGuard per aggiungere regole del firewall che garantiranno che il traffico da e verso il server e i client sia instradato correttamente. Come nella sezione precedente, salta questo passaggio se stai utilizzando il tuo VPN WireGuard solo per una connessione da macchina a macchina per accedere a risorse che sono limitate alla tua VPN.

Per consentire il traffico VPN WireGuard attraverso il firewall del server, dovrai abilitare il masquerading, che è un concetto di iptables che fornisce la traduzione dinamica degli indirizzi di rete (NAT) al volo per instradare correttamente le connessioni dei client.

Per prima cosa trova l'interfaccia di rete pubblica del tuo server WireGuard usando il sottocomando ip route:

ip route list default

L'interfaccia pubblica è la stringa presente nell'output di questo comando che segue la parola "dev". Ad esempio, questo risultato mostra l'interfaccia chiamata eth0, evidenziata di seguito:

default via 203.0.113.1 dev eth0 proto static

Annota il nome del tuo dispositivo poiché lo aggiungerai alle regole di iptables nel passaggio successivo.

Per aggiungere regole del firewall al tuo server WireGuard, apri di nuovo il file /etc/wireguard/wg0.conf con nano o con l'editor che preferisci.

sudo nano /etc/wireguard/wg0.conf

In fondo al file, dopo la riga SaveConfig=true, incolla le seguenti righe:

/etc/wireguard/wg0.conf
. . .
PostUp = ufw route allow in on wg0 out on eth0
PostUp = iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PostUp = ip6tables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PreDown = ufw route delete allow in on wg0 out on eth0
PreDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
PreDown = ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

Le righe PostUp verranno eseguite quando il server WireGuard avvia il tunnel VPN virtuale. Nell'esempio qui, aggiungerà tre regole ufw e iptables:

• ufw route allow in on wg0 out on eth0: Questa regola permetterà l'inoltro del traffico IPv4 e IPv6 che arriva sull'interfaccia VPN wg0 verso l'interfaccia di rete eth0 del server. Funziona in combinazione con i valori sysctl net.ipv4.ip_forward e net.ipv6.conf.all.forwarding che hai configurato nella sezione precedente.
• iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE: Questa regola configura il masquerading e riscrive il traffico IPv4 che arriva sull'interfaccia VPN wg0 per farlo apparire come se provenisse direttamente dall'indirizzo IPv4 pubblico del server WireGuard.
• ip6tables -t nat -I POSTROUTING -o eth0 -j MASQUERADE: Questa regola configura il masquerading e riscrive il traffico IPv6 che arriva sull'interfaccia VPN wg0 in modo che sembri provenire direttamente dall'indirizzo IPv6 pubblico del server WireGuard.

Le regole PreDown vengono eseguite quando il server WireGuard interrompe il tunnel VPN virtuale. Queste regole sono l'inverso delle regole PostUp e servono a annullare le regole di inoltro e mascheramento per l'interfaccia VPN quando la VPN viene interrotta.

In entrambi i casi, modifica la configurazione per includere o escludere le regole IPv4 e IPv6 appropriate per la tua VPN. Ad esempio, se utilizzi solo IPv4, puoi escludere le righe con i comandi ip6tables.

Al contrario, se stai usando solo IPv6, modifica la configurazione per includere solo i comandi ip6tables. Le righe ufw dovrebbero esistere per qualsiasi combinazione di reti IPv4 e IPv6. Salva e chiudi il file quando hai finito.

L'ultima parte della configurazione del firewall sul tuo server WireGuard consiste nel consentire il traffico verso e dal porto UDP di WireGuard stesso. Se non hai modificato il porto nel file /etc/wireguard/wg0.conf del server, il porto che aprirai sarà 51820. Se hai scelto un porto diverso durante la modifica della configurazione, assicurati di sostituirlo nel seguente comando UFW.

Nel caso tu abbia dimenticato di aprire la porta SSH mentre seguivi il tutorial dei prerequisiti, aggiungila anche qui:

sudo ufw allow 51820/udp

sudo ufw allow OpenSSH

Dopo aver aggiunto quelle regole, disabilita e poi riabilita UFW per riavviarlo e caricare le modifiche da tutti i file che hai modificato:

sudo ufw disable

sudo ufw enable

Puoi confermare che le regole sono attive eseguendo il comando ufw status. Eseguilo e dovresti ricevere un output simile al seguente:

sudo ufw status

Status: active

To                         Action      From
--                         ------      ----
51820/udp                  ALLOW       Anywhere                  
22/tcp                     ALLOW       Anywhere                  
51820/udp (v6)             ALLOW       Anywhere (v6)             
22/tcp (v6)                ALLOW       Anywhere (v6)

Il tuo server WireGuard è ora configurato per gestire correttamente il traffico della VPN, inclusi l'inoltro e il mascheramento per i peer. Con le regole del firewall impostate, puoi avviare il servizio WireGuard stesso per ascoltare le connessioni dei peer.

Fase 6 — Avvio del server WireGuard

WireGuard può essere configurato per funzionare come un servizio systemd usando il suo script integrato wg-quick. Sebbene tu possa utilizzare manualmente il comando wg per creare il tunnel ogni volta che vuoi usare la VPN, farlo è un processo manuale che diventa ripetitivo e soggetto a errori. Invece, puoi usare systemctl per gestire il tunnel con l'aiuto dello script wg-quick.

Usare un servizio systemd significa che puoi configurare WireGuard per avviarsi all'accensione del sistema, così da poter connetterti alla tua VPN in qualsiasi momento finché il server è in esecuzione. Per farlo, abilita il servizio wg-quick per il tunnel wg0 che hai definito aggiungendolo a systemctl:

sudo systemctl enable wg-quick@wg0.service

Ora avvia il servizio:

sudo systemctl start wg-quick@wg0.service

Controlla due volte che il servizio WireGuard sia attivo con il seguente comando. Dovresti vedere il servizio elencato come attivo. Nota che wg-quick termina dopo aver configurato l'interfaccia, quindi active (exited) è normale.

sudo systemctl status wg-quick@wg0.service

● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
     Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled; vendor preset: enabled)
     Active: active (exited) since Wed 2021-08-25 15:24:14 UTC; 5s ago
       Docs: man:wg-quick(8)
             man:wg(8)
             https://www.wireguard.com/
             https://www.wireguard.com/quickstart/
             https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
             https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
    Process: 3245 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=0/SUCCESS)
   Main PID: 3245 (code=exited, status=0/SUCCESS)

Aug 25 15:24:14 wg0 wg-quick[3245]: [#] wg setconf wg0 /dev/fd/63
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] ip -4 address add 10.8.0.1/24 dev wg0
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] ip -6 address add fd0d:86fa:c3bc::1/64 dev wg0
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] ip link set mtu 1420 up dev wg0
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] ufw route allow in on wg0 out on eth0
Aug 25 15:24:14 wg0 wg-quick[3279]: Rule added
Aug 25 15:24:14 wg0 wg-quick[3279]: Rule added (v6)
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] ip6tables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
Aug 25 15:24:14 wg0 systemd[1]: Finished WireGuard via wg-quick(8) for wg0.

L'output mostra i comandi ip utilizzati per creare il dispositivo virtuale wg0 e assegnargli gli indirizzi IPv4 e IPv6 che hai aggiunto al file di configurazione. Puoi usare queste regole per risolvere problemi con il tunnel, oppure con il comando wg stesso se vuoi provare a configurare manualmente l'interfaccia VPN.

Con il server configurato e in esecuzione, il passo successivo è configurare il tuo computer client come Peer WireGuard e connettersi al server WireGuard.

Passo 7 — Configurazione di un Peer WireGuard

Configurare un Peer WireGuard è simile a configurare il Server WireGuard. Una volta installato il software client, genererai una coppia di chiavi pubblica e privata, sceglierai un indirizzo IP o più indirizzi per il peer, definirai un file di configurazione per il peer e poi avvierai il tunnel usando lo script wg-quick.

Puoi aggiungere tutti i peer che vuoi al tuo VPN generando una coppia di chiavi e la configurazione utilizzando i seguenti passaggi. Se aggiungi più peer al VPN, assicurati di tenere traccia dei loro indirizzi IP privati per evitare collisioni.

Per configurare il Peer WireGuard, assicurati di aver installato il pacchetto WireGuard utilizzando i seguenti comandi apt. Sul Peer WireGuard esegui:

sudo apt update

sudo apt install wireguard

Creazione della coppia di chiavi del peer WireGuard

Successivamente, dovrai generare la coppia di chiavi sul peer utilizzando gli stessi passaggi che hai usato sul server. Dalla tua macchina locale o dal server remoto che fungerà da peer, procedi e crea la chiave privata per il peer utilizzando i seguenti comandi:

wg genkey | sudo tee /etc/wireguard/private.key

sudo chmod go= /etc/wireguard/private.key

Ancora una volta riceverai una singola riga di output codificato in base64, che rappresenta la chiave privata. Una copia dell'output viene anche salvata in /etc/wireguard/private.key. Prendi attentamente nota della chiave privata che viene visualizzata, poiché dovrai aggiungerla al file di configurazione di WireGuard più avanti in questa sezione.

Quindi usa il seguente comando per creare il file della chiave pubblica:

sudo cat /etc/wireguard/private.key | wg pubkey | sudo tee /etc/wireguard/public.key

Riceverai nuovamente una singola riga di output codificata in base64, che è la chiave pubblica per il tuo Peer WireGuard. Copiala da qualche parte per riferimento, poiché dovrai distribuire la chiave pubblica al Server WireGuard per stabilire una connessione crittografata.

Creazione del file di configurazione del peer WireGuard

Ora che hai una coppia di chiavi, puoi creare un file di configurazione per il peer che contiene tutte le informazioni necessarie per stabilire una connessione al server WireGuard.

Avrai bisogno di alcune informazioni per il file di configurazione:

• La chiave privata codificata base64 che hai generato sul peer.
• Gli intervalli di indirizzi IPv4 e IPv6 che hai definito sul server WireGuard.
• La chiave pubblica codificata base64 dal server WireGuard.
• L'indirizzo IP pubblico e il numero di porta del server WireGuard. Di solito questo sarà l'indirizzo IPv4, ma se il tuo server ha un indirizzo IPv6 e il tuo computer client ha una connessione IPv6 a Internet puoi usare questo invece dell'IPv4.

Con tutte queste informazioni a disposizione, apri un nuovo file /etc/wireguard/wg0.conf sulla macchina Peer di WireGuard utilizzando nano o l'editor che preferisci:

sudo nano /etc/wireguard/wg0.conf

Aggiungi le seguenti righe al file, sostituendo i vari dati nelle sezioni evidenziate secondo necessità:

/etc/wireguard/wg0.conf
[Interface]
PrivateKey = base64_encoded_peer_private_key_goes_here
Address = 10.8.0.2/24
Address = fd0d:86fa:c3bc::2/64

[Peer]
PublicKey = U9uE2kb/nrrzsEU58GD3pKFU3TLYDMCbetIsnV8eeFE=
AllowedIPs = 10.8.0.0/24, fd0d:86fa:c3bc::/64
Endpoint = 203.0.113.1:51820

Nota come la prima riga Address utilizzi un indirizzo IPv4 dal sottorete 10.8.0.0/24 che hai scelto in precedenza. Questo indirizzo IP può essere qualsiasi nell'ambito della sottorete purché sia diverso dall'IP del server. Incrementare gli indirizzi di 1 ogni volta che aggiungi un peer è generalmente il modo più semplice per assegnare gli IP.

Allo stesso modo, nota come la seconda riga Address utilizzi un indirizzo IPv6 dalla sottorete che hai generato in precedenza e incrementi di uno l’indirizzo del server. Anche in questo caso, qualsiasi IP nel range è valido se decidi di utilizzare un indirizzo diverso.

L'altra parte notevole del file è l'ultima riga AllowedIPs. Questi due intervalli IPv4 e IPv6 istruiscono il peer a inviare traffico sulla VPN solo se il sistema di destinazione ha un indirizzo IP in uno dei due intervalli. Utilizzando la direttiva AllowedIPs, puoi limitare la VPN sul peer a connettersi solo ad altri peer e servizi sulla VPN, oppure puoi configurare l'impostazione per instradare tutto il traffico tramite la VPN e utilizzare il Server WireGuard come gateway.

Se stai usando solo IPv4, allora ometti l'intervallo finale fd0d:86fa:c3bc::/64 (inclusa la , virgola). Al contrario, se stai usando solo IPv6, includi solo il prefisso fd0d:86fa:c3bc::/64 e ometti l'intervallo IPv4 10.8.0.0/24.

In entrambi i casi, se desideri inviare tutto il traffico del tuo peer tramite la VPN e utilizzare il server WireGuard come gateway per tutto il traffico, puoi utilizzare 0.0.0.0/0, che rappresenta l'intero spazio degli indirizzi IPv4, e ::/0 per l'intero spazio degli indirizzi IPv6.

(Opzionale) Configurazione di un peer per instradare tutto il traffico attraverso il tunnel

Se hai scelto di instradare tutto il traffico del peer attraverso il tunnel utilizzando le rotte 0.0.0.0/0 o ::/0 e il peer è un sistema remoto, dovrai completare i passaggi in questa sezione. Se il tuo peer è un sistema locale, è meglio saltare questa sezione.

Per i peer remoti a cui accedi tramite SSH o un altro protocollo utilizzando un indirizzo IP pubblico, dovrai aggiungere alcune regole extra al file wg0.conf del peer. Queste regole garantiranno che tu possa ancora connetterti al sistema dall'esterno del tunnel quando è connesso. Altrimenti, quando il tunnel è stabilito, tutto il traffico che normalmente verrebbe gestito sull'interfaccia di rete pubblica non verrà instradato correttamente per bypassare l'interfaccia del tunnel wg0, rendendo il sistema remoto inaccessibile.

Per prima cosa, dovrai determinare l'indirizzo IP che il sistema utilizza come gateway predefinito. Esegui il seguente comando ip route:

ip route list table main default

Riceverai un output simile al seguente:

default via 203.0.113.1 dev eth0 proto static

Annota l'indirizzo IP evidenziato del gateway 203.0.113.1 per un uso successivo e il dispositivo eth0. Il nome del tuo dispositivo potrebbe essere diverso. In tal caso, sostituiscilo al posto di eth0 nei comandi seguenti.

Successivamente, trova l'indirizzo IP pubblico del sistema esaminando il dispositivo con il comando ip address show:

ip -brief address show eth0

Riceverai un output simile al seguente:

eth0             UP             203.0.113.5/20 10.20.30.40/16 2604:a880:400:d1::3d3:6001/64 fe80::68d5:beff:feff:974c/64

In questo esempio di output, l'indirizzo IP evidenziato 203.0.113.5 (senza il /20 finale) è l'indirizzo pubblico assegnato al dispositivo eth0 che dovrai aggiungere alla configurazione di WireGuard.

Ora apri il file /etc/wireguard/wg0.conf del Peer di WireGuard con nano o il tuo editor preferito.

sudo nano /etc/wireguard/wg0.conf

Prima della riga [Peer], aggiungi le seguenti 4 righe:

PostUp = ip rule add table 200 from 203.0.113.5
PostUp = ip route add table 200 default via 203.0.113.1
PreDown = ip rule delete table 200 from 203.0.113.5
PreDown = ip route delete table 200 default via 203.0.113.1

[Peer]
. . .

Queste righe creeranno una regola di instradamento personalizzata e aggiungeranno un percorso personalizzato per garantire che il traffico pubblico verso il sistema utilizzi il gateway predefinito.

• PostUp=ip rule add table 200 from 203.0.113.5 - Questo comando crea una regola che verifica eventuali voci di routing nella tabella numerata 200 quando l'IP corrisponde all'indirizzo pubblico del sistema 203.0.113.5.
• PostUp=ip route add table 200 default via 203.0.113.1 - Questo comando assicura che tutto il traffico gestito dalla tabella 200 utilizzi il gateway 203.0.113.1 per il routing, invece dell'interfaccia WireGuard.

Le linee PreDown rimuovono la regola e la route personalizzate quando il tunnel viene chiuso.

Se stai instradando tutto il traffico del peer tramite la VPN, assicurati di aver configurato correttamente le regole sysctl e iptables sul server WireGuard in Regolazione della configurazione di rete del server WireGuard e Configurazione del firewall del server WireGuard.

(Opzionale) Configurazione dei resolver DNS del peer WireGuard

Se stai utilizzando il server WireGuard come gateway VPN per tutto il traffico dei tuoi peer, dovrai aggiungere una riga nella sezione [Interface] che specifichi i resolver DNS. Se non aggiungi questa impostazione, le tue richieste DNS potrebbero non essere protette dalla VPN oppure potrebbero essere rivelate al tuo fornitore di servizi Internet o ad altri terzi.

Se stai usando WireGuard solo per accedere alle risorse sulla rete VPN o in una configurazione peer-to-peer, puoi saltare questa sezione.

Per aggiungere risolutori DNS alla configurazione del tuo peer, determina prima quali server DNS sta utilizzando il tuo Server WireGuard. Esegui il seguente comando sul Server WireGuard, sostituendo il nome del dispositivo ethernet al posto di eth0 se è diverso da questo esempio:

resolvectl dns eth0

Dovresti ricevere un output simile al seguente:

Link 2 (eth0): 67.207.67.2 67.207.67.3 2001:4860:4860::8844 2001:4860:4860::8888

Gli indirizzi IP visualizzati sono i resolver DNS che il server sta utilizzando. Puoi scegliere di usarne uno, tutti o solo IPv4 o IPv6 a seconda delle tue esigenze. Prendi nota dei resolver che utilizzerai.

Successivamente dovrai aggiungere i resolver scelti al file di configurazione del Peer di WireGuard. Sul Peer di WireGuard, apri il file /etc/wireguard/wg0.conf usando nano o l’editor che preferisci:

sudo nano /etc/wireguard/wg0.conf

Prima della riga [Peer], aggiungi quanto segue:

DNS = 67.207.67.2 2001:4860:4860::8844

[Peer]
. . .

Ancora una volta, a seconda delle tue preferenze o dei requisiti per IPv4 e IPv6, puoi modificare l'elenco in base alle tue esigenze.

Global: 67.207.67.2 67.207.67.3
. . .

Con tutte queste impostazioni del risolutore DNS configurate, sei ora pronto per aggiungere la chiave pubblica del peer al server e poi avviare il tunnel WireGuard sul peer.

Passo 8 — Aggiungere la chiave pubblica del Peer al server WireGuard

Prima di connettere il peer al server, è importante aggiungere la chiave pubblica del peer al server WireGuard. Questo passaggio assicura che potrai connetterti e instradare il traffico attraverso la VPN. Senza completare questo passaggio, il server WireGuard non permetterà al peer di inviare o ricevere alcun traffico attraverso il tunnel.

Assicurati di avere una copia della chiave pubblica del Peer WireGuard codificata in base64 eseguendo:

sudo cat /etc/wireguard/public.key

PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg=

Ora accedi al server WireGuard ed esegui il seguente comando:

sudo wg set wg0 peer PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg= allowed-ips 10.8.0.2,fd0d:86fa:c3bc::2

Nota che la parte allowed-ips del comando accetta un elenco di indirizzi IPv4 e IPv6 separati da virgole. Puoi specificare singoli IP se desideri limitare l'indirizzo IP che un peer può assegnarsi, oppure un intervallo come nell'esempio se i tuoi peer possono utilizzare qualsiasi indirizzo IP nella gamma VPN. Nota anche che due peer non possono avere la stessa impostazione allowed-ips.

Se desideri aggiornare gli allowed-ips per un peer esistente, puoi eseguire di nuovo lo stesso comando, ma modificare gli indirizzi IP. Sono supportati più indirizzi IP. Ad esempio, per modificare il WireGuard Peer che hai appena aggiunto per aggiungere un IP come 10.8.0.100 agli IP esistenti 10.8.0.2 e fd0d:86fa:c3bc::2, dovresti eseguire il seguente comando:

sudo wg set wg0 peer PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg= allowed-ips 10.8.0.2,10.8.0.100,fd0d:86fa:c3bc::2

Una volta eseguito il comando per aggiungere il peer, verifica lo stato del tunnel sul server usando il comando wg:

sudo wg

interface: wg0
 public key: U9uE2kb/nrrzsEU58GD3pKFU3TLYDMCbetIsnV8eeFE=
 private key: (hidden)
 listening port: 51820

peer: PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg=
 allowed ips: 10.8.0.2/32, fd0d:86fa:c3bc::/128

Nota come la linea peer mostri la chiave pubblica del Peer WireGuard e gli indirizzi IP, o intervalli di indirizzi, che è autorizzato a usare per assegnarsi un IP.

Ora che hai definito i parametri di connessione del peer sul server, il passo successivo è avviare il tunnel sul peer.

Passo 9 — Collegare il Peer WireGuard al Tunnel

Ora che il tuo server e il peer sono entrambi configurati per supportare la tua scelta di IPv4, IPv6, inoltro dei pacchetti e risoluzione DNS, è il momento di collegare il peer al tunnel VPN.

Poiché potresti voler avere il VPN attivo solo per alcuni casi d'uso, useremo il comando wg-quick per stabilire manualmente la connessione. Se desideri automatizzare l'avvio del tunnel come hai fatto sul server, segui quei passaggi nella sezione Avvio del server WireGuard invece di usare il comando wg-quick.

Nel caso in cui instradi tutto il traffico tramite la VPN e abbia configurato l'inoltro DNS, dovrai installare l'utilità resolvconf sul Peer WireGuard prima di avviare il tunnel. Esegui il seguente comando per configurarlo:

sudo apt install resolvconf

Per avviare il tunnel, esegui il seguente comando sul Peer WireGuard:

sudo wg-quick up wg0

Riceverai un output simile al seguente:

[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.8.0.2/24 dev wg0
[#] ip -6 address add fd0d:86fa:c3bc::2/64 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] resolvconf -a tun.wg0 -m 0 -x

Nota gli indirizzi IPv4 e IPv6 evidenziati che hai assegnato al peer.

Se imposti AllowedIPs sul peer su 0.0.0.0/0 e ::/0 (o su intervalli diversi da quelli che hai scelto per la VPN), il tuo output assomiglierà al seguente:

[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.8.0.2/24 dev wg0
[#] ip -6 address add fd0d:86fa:c3bc::2/64 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] resolvconf -a tun.wg0 -m 0 -x
[#] wg set wg0 fwmark 51820
[#] ip -6 route add ::/0 dev wg0 table 51820
[#] ip -6 rule add not fwmark 51820 table 51820
[#] ip -6 rule add table main suppress_prefixlength 0
[#] ip6tables-restore -n
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
[#] iptables-restore -n

In questo esempio, nota le rotte evidenziate che il comando ha aggiunto, le quali corrispondono agli AllowedIPs nella configurazione del peer.

Puoi controllare lo stato del tunnel sul peer utilizzando il comando wg:

sudo wg

interface: wg0
 public key: PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg=
 private key: (hidden)
 listening port: 49338
 fwmark: 0xca6c

peer: U9uE2kb/nrrzsEU58GD3pKFU3TLYDMCbetIsnV8eeFE=
 endpoint: 203.0.113.1:51820
 allowed ips: 10.8.0.0/24, fd0d:86fa:c3bc::/64
 latest handshake: 1 second ago
 transfer: 6.50 KiB received, 15.41 KiB sent

Puoi anche controllare di nuovo lo stato sul server e riceverai un output simile.

Verifica che il tuo peer stia usando la VPN utilizzando i comandi ip route e ip -6 route. Se stai usando la VPN come gateway per tutto il traffico Internet, controlla quale interfaccia sarà utilizzata per il traffico destinato ai resolver DNS di CloudFlare 1.1.1.1 e 2606:4700:4700::1111.

ip route get 1.1.1.1

1.1.1.1 dev wg0 table 51820 src 10.8.0.2 uid 1000
   cache

Nota che viene utilizzato il dispositivo wg0 e l'indirizzo IPv4 10.8.0.2 che hai assegnato al peer. Allo stesso modo, se stai usando IPv6, esegui quanto segue:

ip -6 route get 2606:4700:4700::1111

2606:4700:4700::1111 from :: dev wg0 table 51820 src fd0d:86fa:c3bc::2 metric 1024 pref medium

Nota ancora l'interfaccia wg0 e l'indirizzo IPv6 fd0d:86fa:c3bc::2 che hai assegnato al peer.

Se il tuo interlocutore ha un browser installato, puoi anche visitare ipleak.net e ipv6-test.com per confermare che il traffico del tuo interlocutore passa attraverso la VPN.

Una volta pronto a disconnetterti dalla VPN sul peer, usa il comando wg-quick:

sudo wg-quick down wg0

Riceverai un output simile al seguente che indica che il tunnel VPN è chiuso:

[#] ip link delete dev wg0
[#] resolvconf -d tun.wg0 -f

Se imposti AllowedIPs sul peer su 0.0.0.0/0 e ::/0 (o su intervalli diversi da quelli che hai scelto per la VPN), il tuo output assomiglierà al seguente:

[#] ip rule delete table 200 from 203.0.113.5
[#] ip route delete table 200 default via 203.0.113.1
[#] ip -4 rule delete table 51820
[#] ip -4 rule delete table main suppress_prefixlength 0
[#] ip -6 rule delete table 51820
[#] ip -6 rule delete table main suppress_prefixlength 0
[#] ip link delete dev wg0
[#] resolvconf -d tun.wg0 -f
[#] iptables-restore -n
[#] ip6tables-restore -n

Per riconnettersi alla VPN, eseguire nuovamente il comando wg-quick up wg0 sul peer. Se desideri rimuovere completamente la configurazione di un peer dal server WireGuard, puoi eseguire il seguente comando, assicurandoti di sostituire la chiave pubblica corretta del peer che desideri rimuovere:

sudo wg set wg0 peer PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg= remove

Di solito sarà necessario rimuovere una configurazione peer solo se il peer non esiste più o se le sue chiavi di crittografia sono compromesse o modificate. Altrimenti è meglio lasciare la configurazione in atto in modo che il peer possa riconnettersi alla VPN senza richiedere di aggiungere ogni volta la sua chiave e allowed-ips.

Gestione e Rotazione delle Chiavi WireGuard

WireGuard si basa su coppie di chiavi pubbliche e private statiche per l'autenticazione e la crittografia. Questo design riduce significativamente la complessità della configurazione, ma pone anche la responsabilità della gestione delle chiavi interamente sull'amministratore. Per implementazioni VPN di lunga durata, infrastrutture condivise o ambienti con più peer, una gestione attenta delle chiavi è essenziale per mantenere la sicurezza e la stabilità operativa.

Comprendere i tipi di chiavi di WireGuard

Ogni peer WireGuard utilizza due categorie di chiavi crittografiche.

• Chiavi private a lungo termine: Una chiave privata identifica in modo univoco un peer e deve rimanere segreta in ogni momento. Questa chiave viene utilizzata durante i handshake crittografati per autenticare il peer e derivare chiavi di sessione a breve termine. Se una chiave privata viene compromessa, qualsiasi sistema che possiede quella chiave può impersonare il peer.

• Chiavi pubbliche a lungo termine: Una chiave pubblica è derivata da una chiave privata e viene condivisa con altri peer. Sul nodo centrale, le chiavi pubbliche determinano quali peer sono autorizzati a comunicare e quali indirizzi IP possono utilizzare.

Oltre a queste chiavi a lungo termine, WireGuard genera automaticamente chiavi di sessione effimere durante le handshake crittografate. Queste chiavi di sessione vengono ruotate periodicamente e garantiscono la Perfetta Segretezza Avanzata senza l'intervento dell'amministratore.

Pratiche consigliate per la gestione delle chiavi

Le seguenti pratiche aiutano a ridurre i rischi e a semplificare le operazioni in corso:

• Assegna una coppia di chiavi univoca a ciascun peer: ciascun dispositivo dovrebbe avere la propria coppia di chiavi privata e pubblica. Utilizzare chiavi uniche consente di revocare l'accesso a un singolo dispositivo senza influire sugli altri. Riutilizzare le chiavi su più sistemi aumenta l'impatto di una violazione e complica le attività di audit.

• Limitare l'accesso al materiale della chiave privata: i file della chiave privata dovrebbero essere leggibili solo dall'utente root. Nei sistemi Linux, questo di solito significa impostare i permessi su 600 utilizzando un comando come chmod 600 /etc/wireguard/private.key. Limitare l'accesso ai file aiuta a prevenire la divulgazione accidentale tramite backup, log o utenti non privilegiati.

• Mantenere un inventario esplicito dei peer: Tieni un registro che associ ciascuna chiave pubblica del peer al nome del dispositivo, agli indirizzi IPv4 e IPv6 assegnati e allo scopo previsto. Questa documentazione diventa sempre più importante man mano che aumenta il numero di peer e semplifica la risoluzione dei problemi, le verifiche e la manutenzione ordinaria.

• Rimuovere prontamente i peer inutilizzati o inattivi: quando un dispositivo viene dismesso o non necessita più dell'accesso VPN, rimuovere la sua chiave pubblica dalla configurazione centrale dei peer. Lasciare chiavi inutilizzate aumenta la superficie di attacco e rende più difficili le revisioni future.

Situazioni che richiedono la rotazione delle chiavi

La rotazione delle chiavi dovrebbe essere eseguita in diversi scenari comuni:

• Sospetta o confermata esposizione della chiave: Se una chiave privata potrebbe essere stata copiata, divulgata o accessibile a una parte non autorizzata, deve essere ruotata immediatamente per prevenire l'usurpazione d'identità.

• Dispositivi smarriti o rubati: Quando un dispositivo viene smarrito o rubato, ruotare le chiavi assicura che non possa più connettersi alla VPN, anche se la configurazione originale viene recuperata.

• Requisiti di sicurezza organizzativa: Alcuni ambienti richiedono una rotazione periodica delle chiavi per rispettare le politiche interne o gli standard di conformità, anche se non si sospetta alcuna compromissione.

• Cambiamenti nella proprietà o nel ruolo del dispositivo: Quando un dispositivo viene riassegnato a un utente o a uno scopo diverso, ruotare le sue chiavi previene accessi continui non intenzionati.

Ruotare in sicurezza le chiavi di un collega

WireGuard associa gli indirizzi IP interni a chiavi pubbliche specifiche utilizzando una tabella di routing crittografica. A causa di questo design, lo stesso indirizzo IP interno non può essere assegnato in sicurezza a due chiavi pubbliche contemporaneamente. La rotazione delle chiavi comporta quindi di solito una breve interruzione della connettività mentre la configurazione viene aggiornata.

Per ruotare le chiavi di un peer, segui questo processo:

1. Genera una nuova coppia di chiavi privata e pubblica sul peer.
2. Aggiorna la configurazione del peer centrale per sostituire la vecchia chiave pubblica con la nuova, mantenendo gli stessi valori di AllowedIPs. Non riavviare ancora l'interfaccia.
3. Aggiorna il file di configurazione del peer per usare la nuova chiave privata.
4. Applica la configurazione aggiornata sul peer centrale, ad esempio ricaricando il servizio WireGuard o usando wg syncconf. A questo punto, il peer perderà temporaneamente la connettività.
5. Riavvia l'interfaccia WireGuard sul peer in modo che inizi a utilizzare la nuova chiave privata.
6. Verifica che un nuovo handshake venga completato e che il traffico fluisca correttamente.
7. Rimuovi eventuali riferimenti rimanenti alla vecchia chiave se sono ancora presenti.

Questo approccio basato sulla sostituzione riflette come WireGuard applica il routing crittografico ed evita configurazioni ambigue o in conflitto.

Rotazione delle chiavi sul peer centrale

La rotazione della chiave privata del peer centrale influisce su tutti i peer connessi. La configurazione di ciascun peer deve essere aggiornata con la nuova chiave pubblica prima di poter ripristinare la connettività.

Poiché questa modifica influisce su tutti i peer contemporaneamente, la rotazione della chiave del peer centrale dovrebbe essere pianificata attentamente e eseguita durante una finestra di manutenzione. In pratica, le chiavi centrali vengono ruotate meno frequentemente rispetto alle chiavi dei peer.

Gestione delle chiavi precondivise (Opzionale)

Oltre alle coppie di chiavi pubbliche e private, WireGuard supporta una Chiave Pre-Condivisa (PSK) opzionale per ciascun peer. Una PSK aggiunge un ulteriore livello di crittografia simmetrica sopra la crittografia già esistente di WireGuard.

Le chiavi pre-condivise sono comunemente utilizzate in ambienti ad alta sicurezza come difesa contro futuri avanzamenti crittografici. Se il traffico crittografato viene registrato oggi e in futuro l'algoritmo a chiave pubblica sottostante viene compromesso, una PSK impedirebbe comunque la decrittazione delle sessioni passate.

Se vengono utilizzati PSK, devono essere trattati come segreti sensibili e ruotati periodicamente. La rotazione di un PSK segue lo stesso schema operativo della rotazione delle chiavi dei peer e deve essere coordinata su entrambi i lati della connessione.

Scegliere una frequenza di rotazione

WireGuard non impone un programma fisso di rotazione delle chiavi. Gli intervalli di rotazione appropriati dipendono dall'ambiente.

• Le missioni personali o di breve durata potrebbero non richiedere una rotazione programmata.
• Gli ambienti condivisi o di produzione di solito ruotano le chiavi ogni 6-12 mesi.
• Gli ambienti ad alta sicurezza possono richiedere una rotazione più frequente in base alla politica.

La rotazione regolare riduce il rischio associato alle credenziali di lunga durata e allinea le implementazioni di WireGuard alle comuni pratiche di sicurezza.

WireGuard vs OpenVPN: differenze pratiche

WireGuard e OpenVPN sono entrambe tecnologie VPN ampiamente utilizzate, ma adottano approcci molto diversi per quanto riguarda la crittografia, la configurazione e il comportamento della rete. Comprendere queste differenze aiuta gli sviluppatori a scegliere la soluzione che meglio si adatta ai loro vincoli operativi.

Modello di Configurazione e Operativo

WireGuard utilizza un modello di configurazione statico basato su coppie di chiavi pubbliche e private. Tutti i peer sono definiti esplicitamente e il comportamento del routing è controllato tramite valori di configurazione fissi. Non esiste un canale di controllo, un'autorità di certificazione o una negoziazione dinamica dei parametri.

OpenVPN si basa su TLS e certificati X.509. Utilizza un canale di controllo per autenticare i client, negoziare le impostazioni di crittografia e gestire le sessioni. Questo modello offre flessibilità ma aumenta la complessità di configurazione e operativa.

In pratica, le configurazioni di WireGuard sono più brevi, più facili da verificare e meno soggette a configurazioni errate sottili. Le configurazioni di OpenVPN offrono maggiore controllo, ma richiedono una gestione attenta per rimanere sicure e coerenti.

Crittografia e Progettazione della Sicurezza

WireGuard utilizza un insieme fisso di metodi crittografici moderni. Queste scelte non sono configurabili. Questo design elimina gli attacchi di downgrade crittografico e rimuove la necessità di selezionare suite di cifratura.

OpenVPN supporta un'ampia gamma di algoritmi di crittografia e metodi di autenticazione. Sebbene questa flessibilità consenta la compatibilità con i sistemi legacy, aumenta anche il rischio di configurazioni deboli o incoerenti.

Entrambe le soluzioni supportano il Perfect Forward Secrecy. WireGuard esegue la rotazione delle chiavi automaticamente tramite il suo meccanismo di handshake, mentre OpenVPN si basa sul comportamento delle sessioni TLS.

Caratteristiche delle prestazioni

WireGuard è progettato per alte prestazioni e bassa latenza. Funziona nel kernel di Linux e ha una base di codice ridotta, il che riduce l'overhead e il cambio di contesto. Nella maggior parte degli ambienti, WireGuard offre una maggiore velocità di trasferimento e una latenza più costante con una minima configurazione.

Storicamente, OpenVPN funziona nello spazio utente e comporta un sovraccarico aggiuntivo dovuto ai cambi di contesto e alla gestione del protocollo. Le versioni moderne di OpenVPN supportano il Kernel Data Channel Offload (DCO), che migliora significativamente le prestazioni, ma questa funzione non è sempre abilitata o disponibile nelle implementazioni predefinite.

Anche con DCO, WireGuard di solito raggiunge prestazioni elevate con meno variabili di configurazione.

Roaming di rete e attraversamento del firewall

WireGuard gestisce i cambiamenti della rete in modo efficiente. Se l’indirizzo IP di un peer cambia, ad esempio quando si passa tra WiFi e reti mobili, il tunnel continua a funzionare senza necessità di rinegoziazione.

Tuttavia, WireGuard funziona esclusivamente su UDP. Sebbene UDP sia efficiente, a volte viene bloccato su reti WiFi pubbliche restrittive, firewall aziendali o reti istituzionali. WireGuard non prevede un meccanismo di fallback nativo quando il traffico UDP è bloccato.

OpenVPN supporta sia UDP che TCP. Quando UDP non è disponibile, OpenVPN può essere configurato per funzionare tramite la porta TCP 443, facendo apparire il traffico VPN simile al normale traffico HTTPS. Questa capacità rende OpenVPN più affidabile in ambienti con regole firewall rigide o censura.

Per gli utenti che operano dietro reti restrittive, il supporto TCP è spesso il fattore decisivo nella scelta di OpenVPN rispetto a WireGuard.

Ambito delle Funzionalità ed Estendibilità

OpenVPN include funzionalità che WireGuard intenzionalmente non offre. Queste includono l'autenticazione basata sull'utente, l'assegnazione dinamica degli indirizzi e l'integrazione con sistemi di identità esterni.

WireGuard si concentra esclusivamente sul tunneling sicuro. I flussi di lavoro per l'autenticazione, il controllo degli accessi e la configurazione dinamica devono essere gestiti al di fuori del protocollo.

Questo rende OpenVPN più adatto per ambienti che richiedono un'autenticazione complessa o una gestione centralizzata degli utenti, mentre WireGuard è più indicato per VPN a livello di infrastruttura e accesso tra pari.

Confronto riepilogativo

Scegliere tra WireGuard e OpenVPN

WireGuard è ben adatto per VPN infrastrutturali, tunnel site-to-site, client mobili e ambienti in cui semplicità, prestazioni e prevedibilità sono prioritarie.

OpenVPN rimane una scelta solida per ambienti aziendali che richiedono tunneling basato su TCP, autenticazione avanzata o funzionamento affidabile dietro firewall restrittivi.

In molte implementazioni moderne, WireGuard sostituisce OpenVPN non perché offra più funzionalità, ma perché offre meno funzionalità con un comportamento più chiaro.

Ottimizzazione delle prestazioni

WireGuard funziona bene con le impostazioni predefinite, ma le condizioni della rete nel mondo reale possono influire sull'affidabilità e sulla larghezza di banda. Fattori come la dimensione dei pacchetti, l'ambito del routing, il comportamento del NAT e la risoluzione DNS influenzano tutti il comportamento del tunnel durante un utilizzo continuo o intermittente.

Diamo un'occhiata alle aree di regolazione più comuni e a quando sono appropriati gli aggiustamenti.

Selezione MTU e frammentazione dei pacchetti

L'Unità Massima di Trasmissione (MTU) definisce la dimensione massima dei pacchetti che possono essere trasmessi senza frammentazione. WireGuard cripta e incapsula i pacchetti, il che riduce l'MTU effettivo rispetto a un'interfaccia di rete fisica.

Per impostazione predefinita, WireGuard utilizza un MTU di 1420. Questo valore tiene conto dell'overhead combinato dei header IPv6, UDP e della incapsulazione di WireGuard e funziona bene per la maggior parte delle reti basate su Ethernet. Alcuni ambienti richiedono un MTU più piccolo. Questo è comune nelle reti mobili, nelle connessioni PPPoE e nelle piattaforme cloud con ulteriori livelli di incapsulazione. Quando l'MTU è troppo grande, i pacchetti possono essere scartati o frammentati. Ciò spesso provoca connessioni che funzionano per richieste di piccole dimensioni ma si bloccano o falliscono per trasferimenti più grandi. Se si verificano questi sintomi, è consigliabile ridurre l'MTU gradualmente. Valori come 1360 o, in ambienti più restrittivi, 1280, che è l'MTU minimo per IPv6, risolvono spesso questi problemi con un impatto minimo sulla velocità di trasmissione.

L'MTU dovrebbe essere impostato esplicitamente nella sezione [Interface] del file di configurazione per garantire un comportamento coerente durante i riavvii.

Ambito e Impatto di AllowedIPs

La direttiva AllowedIPs influenza sia il comportamento del routing sia le prestazioni. Ampi intervalli di indirizzi fanno sì che più traffico attraversi il tunnel, aumentando il carico di crittografia e sul server. Usare valori ristretti di AllowedIPs limita il tunnel solo al traffico che richiede protezione. Ciò riduce l'uso della CPU ed evita incapsulamenti non necessari.

Quando 0.0.0.0/0 o ::/0 è configurato, tutto il traffico viene instradato tramite la VPN. Questa configurazione è appropriata quando la privacy, il controllo centralizzato dell'uscita o le reti non sicure sono una preoccupazione, ma aumenta la latenza e l'utilizzo delle risorse per il traffico Internet generale.

L'ottimizzazione delle prestazioni spesso implica restringere i AllowedIPs dove possibile ed evitare il routing a tunnel completo, a meno che non sia necessario.

Attraversamento NAT e Stabilità della Connessione (PersistentKeepalive)

WireGuard è intenzionalmente silenzioso quando non vengono trasmessi dati. Di default non invia pacchetti keepalive periodici. In ambienti che utilizzano NAT, come router domestici, reti mobili o molte reti cloud, questo silenzio può far sì che il dispositivo NAT chiuda la mappatura della connessione. Quando ciò accade, il traffico in arrivo dal server viene bloccato fino a quando il peer non invia nuovamente traffico. Questo comportamento è spesso percepito come ritardo, connessioni in ritardo o guasti intermittenti.

Per prevenire ciò, WireGuard fornisce l'impostazione PersistentKeepalive. Questa opzione può essere aggiunta alla sezione [Peer] della configurazione del peer. Fa sì che il peer invii un piccolo pacchetto keepalive a intervalli fissi per mantenere aperta la mappatura NAT. Un valore di 25 secondi è comunemente utilizzato e funziona bene con la maggior parte dei dispositivi NAT. Se una connessione funziona inizialmente ma fallisce dopo essere rimasta inattiva, abilitare PersistentKeepalive=25 è la soluzione principale e raccomandata.

Risoluzione DNS e comportamento del tunnel

La configurazione del DNS ha un impatto significativo sulle prestazioni percepite della VPN. Quando i resolver DNS non sono correttamente instradati attraverso il tunnel, le applicazioni possono sembrare lente o inaffidabili anche quando il tunnel stesso funziona correttamente.

Nelle configurazioni del gateway, le query DNS dovrebbero essere inviate tramite la VPN per garantire un instradamento coerente ed evitare perdite. Questo richiede di definire esplicitamente i resolver DNS nella configurazione del peer. Quando il DNS è configurato in modo errato, i sintomi comuni includono caricamenti lenti delle pagine, connettività incoerente o traffico instradato al di fuori della VPN nonostante un tunnel attivo.

Selezionare i resolver raggiungibili tramite il tunnel e che rispondono rapidamente migliora sia l'affidabilità che l'esperienza dell'utente.

Differenze di prestazioni tra IPv4 e IPv6

Negli ambienti dual-stack, IPv4 e IPv6 possono comportarsi in modo diverso. I percorsi IPv6 possono avere diversi vincoli MTU, politiche di routing o comportamenti del firewall.

Testare entrambi i protocolli indipendentemente aiuta a identificare problemi specifici di ciascun protocollo. Strumenti come ping, tracepath e ip route get sono utili per convalidare il routing e il comportamento dell'MTU per ciascuna famiglia di indirizzi.

Se le prestazioni di IPv6 sembrano incoerenti, verifica che il traffico ICMPv6 sia consentito. ICMPv6 è necessario per la scoperta del MTU del percorso e bloccarlo può causare il blocco delle connessioni su pacchetti più grandi.

CPU e sovraccarico della crittografia

WireGuard utilizza una crittografia moderna che è efficiente sulla maggior parte dei sistemi. Tuttavia, la crittografia consuma comunque risorse della CPU.

Su piccole macchine virtuali, router integrati o sistemi senza accelerazione hardware, le configurazioni a tunnel completo possono saturare la CPU sotto carico sostenuto.

Monitorare l'utilizzo della CPU durante il traffico intenso aiuta a determinare se i problemi di prestazioni sono causati dal sovraccarico di crittografia piuttosto che dalla configurazione della rete. In tali casi, potrebbe essere necessario ridurre il traffico incapsulato o aggiornare l'istanza del server.

Validazione delle modifiche alle prestazioni

La messa a punto delle prestazioni dovrebbe essere effettuata in modo incrementale. Dopo ogni modifica, la connettività e la stabilità dovrebbero essere verificate prima di applicare ulteriori aggiustamenti.

Passi di convalida utili includono il controllo della stabilità dell'handshake con wg, la misurazione della latenza e della velocità di trasmissione prima e dopo le modifiche, e la conferma del comportamento del routing con ip route e ip -6 route. Questo approccio riduce al minimo il rischio e semplifica la risoluzione dei problemi.

Domande frequenti

1. Cos'è WireGuard e come funziona su Ubuntu?

WireGuard è una tecnologia VPN moderna progettata per essere molto più veloce e facile da configurare rispetto alle opzioni più vecchie come OpenVPN o IPsec. Puoi pensarla come a un tunnel sicuro che collega direttamente i tuoi dispositivi. A differenza delle VPN più vecchie, che sono pesanti e complesse, WireGuard è estremamente leggero. Su Ubuntu, funziona eseguendo direttamente all'interno del kernel Linux; il "motore" centrale del sistema operativo. Poiché funziona in profondità nel sistema invece che come applicazione separata sopra, consuma pochissima batteria e processa i dati incredibilmente velocemente.

Per stabilire una connessione, WireGuard utilizza un metodo molto simile a SSH. Genera una coppia di "chiavi" per ogni dispositivo: una chiave privata (che rimane segreta sul dispositivo) e una chiave pubblica (che condividi con gli altri dispositivi a cui vuoi connetterti). La connessione avviene solo se le chiavi corrispondono perfettamente, rendendo il handshake veloce e sicuro.

2. WireGuard è più sicuro di OpenVPN?

Per la maggior parte degli utenti, WireGuard è considerato più sicuro grazie alla sua semplicità e al design moderno. La ragione principale è la dimensione del suo codice. WireGuard è costruito con circa 4.000 righe di codice, mentre OpenVPN ne ha oltre 100.000. Questa enorme differenza significa che è molto più facile per gli esperti di sicurezza leggere il codice di WireGuard e trovare vulnerabilità (bug) prima che lo facciano gli attori malintenzionati.

WireGuard ti obbliga anche a utilizzare gli standard di crittografia più recenti e più sicuri disponibili oggi. I VPN più vecchi permettono l'agilità crittografica, il che significa che possono degradare a metodi di crittografia più deboli per supportare dispositivi vecchi. WireGuard elimina questa possibilità, impedendo agli aggressori di ingannare il tuo VPN facendogli usare una protezione più debole. Inoltre, WireGuard è stealth per impostazione predefinita; se un dispositivo non autorizzato invia un pacchetto al tuo server, WireGuard semplicemente non risponde. Questo rende il tuo server invisibile agli hacker che cercano porte aperte.

3. Posso configurare WireGuard su Ubuntu senza Docker?

Sì, puoi configurarlo facilmente direttamente sul sistema senza usare container Docker. In effetti, eseguirlo direttamente è spesso il metodo preferito su Ubuntu perché il software è incluso nei repository software standard di Ubuntu. In genere è sufficiente eseguire i normali comandi di installazione indicati di seguito, che scaricheranno il software necessario direttamente dalla fonte ufficiale di Ubuntu.

sudo apt update
sudo apt install wireguard

4. Come aggiungo più client WireGuard (peer)?

WireGuard utilizza un concetto peer-to-peer, il che significa che ogni dispositivo a cui ti connetti è considerato un "peer". Per aggiungere più dispositivi, come un laptop, uno smartphone e un tablet, è sufficiente modificare il file di configurazione del server (solitamente situato in /etc/wireguard/wg0.conf).

Per ogni nuovo dispositivo, aggiungi un nuovo blocco di testo etichettato [Peer]. All'interno di questo blocco, devi incollare la Chiave Pubblica di quel dispositivo specifico e assegnargli un indirizzo IP interno unico (come 10.0.0.2 per il primo dispositivo, 10.0.0.3 per il secondo e così via). È fondamentale che questi indirizzi IP interni non si sovrappongano.

Ecco un semplice esempio di blocco di configurazione:

[Interface]
# Server settings...
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = <Server_Private_Key>

[Peer]
# Client 1 (Laptop)
PublicKey = <Laptop_Public_Key>
AllowedIPs = 10.0.0.2/32

[Peer]
# Client 2 (Phone)
PublicKey = <Phone_Public_Key>
AllowedIPs = 10.0.0.3/32

5. Quali porte utilizza WireGuard?

WireGuard utilizza per impostazione predefinita la porta UDP 51820. Si basa strettamente sul protocollo UDP perché è più veloce per il tunneling dei dati rispetto al TCP. Il TCP richiede una conferma per ogni pacchetto di dati inviato, il che può rallentare notevolmente una connessione VPN. UDP invia semplicemente i dati senza attendere una ricevuta, il che è perfetto per la natura ad alta velocità di WireGuard. Quando configuri il firewall di Ubuntu (UFW), devi consentire specificamente il traffico su questa porta UDP, altrimenti le richieste di connessione saranno bloccate prima di raggiungere il software VPN.

6. Come posso risolvere i problemi di connessione di WireGuard?

La risoluzione dei problemi di WireGuard di solito è semplice perché ci sono meno elementi in gioco. Se non riesci a connetterti, dovresti seguire questa sequenza specifica di controlli:

Per prima cosa, controlla lo stato della stretta di mano eseguendo sudo wg show sul tuo server. Se la connessione è attiva, vedrai una riga con scritto latest handshake seguita da un orario (ad esempio, “1 minuto fa”). Se questa riga manca, significa che i dispositivi non comunicano affatto tra loro. Questo è quasi sempre causato da un firewall che blocca la porta UDP o da una non corrispondenza tra le chiavi pubbliche/private.

In secondo luogo, se il collegamento è attivo ma non riesci a navigare in internet, il problema è probabilmente l'inoltro IP. Devi assicurarti che il tuo server Ubuntu sia autorizzato a instradare il traffico dalla VPN a internet. Puoi verificarlo controllando il file /etc/sysctl.conf e assicurandoti che la riga net.ipv4.ip_forward=1 sia attiva (non commentata).

7. WireGuard supporta IPv6 su Ubuntu?

Sì, WireGuard ha un eccellente supporto per IPv6. È molto flessibile e può incapsulare (wrappare) diversi tipi di traffico. Ad esempio, puoi accedere a un sito web solo IPv4 tramite una connessione IPv6, o viceversa. Per abilitare questa funzione, basta includere nel tuo file di configurazione indirizzi IPv6 separati da virgola insieme ai tuoi indirizzi IPv4 standard. Dovresti aggiungerli sia al campo Address (per l'IP del server) sia al campo AllowedIPs (per gli IP dei client).

8. Come faccio ad abilitare WireGuard per l'avvio automatico all'accensione?

Per assicurarti che la tua VPN si attivi automaticamente ogni volta che riavvii il tuo server Ubuntu, devi usare systemd, che è il gestore di sistema per Linux. Devi usare il comando enable per dire al sistema di cercare il tuo file di configurazione specifico (ad esempio, wg0) e caricarlo durante la sequenza di avvio. Questo garantisce che se il tuo server si riavvia per un aggiornamento, la tua connessione VPN tornerà online senza che tu debba avviarla manualmente.

sudo systemctl enable wg-quick@wg0

Conclusione

In questo tutorial, configuri una VPN WireGuard su un server Ubuntu e colleghi un peer utilizzando sia IPv4 che IPv6. Durante il processo, hai configurato le chiavi, assegnato gli indirizzi del tunnel e abilitato il server a instradare il traffico in modo sicuro, ottenendo una VPN funzionante facile da comprendere e gestire.

La guida ha trattato anche alcuni dettagli pratici che contano una volta che la VPN è in uso regolare, come gestire le chiavi nel tempo, gestire IPv6 e il networking a doppio stack, e migliorare l'affidabilità e le prestazioni con la regolazione dell'MTU, i keepalive e le impostazioni DNS. Con questi elementi a posto, dovresti essere ben preparato a utilizzare WireGuard in ambienti reali o ad adattarlo man mano che le tue esigenze cambiano.

Se desideri saperne di più su WireGuard, incluso come configurare tunnel più avanzati o utilizzare WireGuard con i container, visita la documentazione ufficiale di WireGuard. Per ulteriori tutorial relativi alla protezione dei tuoi sistemi Ubuntu, consulta i seguenti articoli:

• Come Configurare un Firewall con UFW su Ubuntu
• UFW Essenziali: Regole e Comandi Comuni del Firewall per la Sicurezza Linux
• VPC vs VPN: Quale si adatta meglio alle tue esigenze di rete sicura?
• Come configurare e impostare un server OpenVPN su Ubuntu

Grazie per aver imparato con la community di Linux-Console.net.