Come configurare una VPN WireGuard Point-to-Site su Debian 12

Scenario illustrativo: Maya utilizza un VPS Debian 12 come endpoint VPN personale quando lavora da un bar. Il suo laptop dovrebbe raggiungere il VPS tramite un tunnel WireGuard crittografato e instradare il suo traffico internet IPv4 attraverso tale server. Questo esempio non rappresenta un test reale; gli indirizzi IP pubblici, le chiavi e l'output del terminale mostrati di seguito sono segnaposto o simulazioni rappresentative.

Questa configurazione è una VPN point-to-site: un client si connette a un server. Utilizza gli strumenti WireGuard inclusi in Debian, un singolo peer, l'inoltro IPv4 e il NAT IPv4. Si presuppone che il VPS abbia un indirizzo IPv4 pubblico o con port forwarding, che sia amministrabile con sudo e che la porta UDP 51820 sia raggiungibile. La procedura guidata non prevede la configurazione di IPv6 instradato o di una rete privata dietro il VPS.

Pianifica prima gli indirizzi e l'accesso

L'esempio utilizza 10.8.0.0/24la VPN, sia 10.8.0.1sul server che 10.8.0.2sul primo client di Maya. Utilizzare una sottorete che non si sovrapponga alle reti Wi-Fi, dell'ufficio o cloud del client. Una collisione può instradare il traffico lungo il percorso sbagliato anche quando l'handshake ha successo.

WireGuard utilizza l'autenticazione a chiave pubblica. Il server necessita della chiave pubblica del client e il client necessita della chiave pubblica del server; ogni chiave privata rimane sul dispositivo che la possiede. La documentazione di WireGuard per Debian descrive la configurazione del pacchetto e dei peer, mentre la guida rapida di WireGuard illustra la generazione delle chiavi e il comportamento del keepalive. Consultare la documentazione di WireGuard per Debian e la guida rapida di WireGuard .

Configurare il server Debian 12

1. Installa gli strumenti

Aggiorna l'indice dei pacchetti e installa WireGuard più nftables, che fornirà la regola di esempio per il masquerading IPv4. Esegui questi comandi sul VPS:

sudo apt update
sudo apt install wireguard nftables

Debian include WireGuard tramite il wireguardmetapackage e i relativi strumenti. Se il server utilizza già un gestore firewall come UFW, firewalld o regole gestite dal provider, identifica il set di regole attivo prima di aggiungere qualsiasi elemento. Non sostituire una configurazione firewall esistente con questo esempio.

2. Individua l'interfaccia pubblica e abilita l'inoltro

Chiedi alla tabella di routing quale interfaccia Debian utilizza per raggiungere un indirizzo IPv4 esterno:

ip route get 1.1.1.1

Nell'esempio, il percorso utilizza eth0. Il tuo VPS potrebbe mostrare un nome diverso, ad esempio ens3o enp1s0; usa il nome dal tuo output nella regola NAT in seguito. Prendi nota anche dell'indirizzo IPv4 pubblico o del nome DNS del server. Se il server si trova dietro un router, inoltra la porta UDP 51820 da quel router all'host Debian.

Per un tunnel completo è necessario l'inoltro IPv4. Abilitalo ora e mantienilo attivo anche dopo il riavvio del sistema:

echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system
sysctl net.ipv4.ip_forward

L'ultimo comando dovrebbe riportare net.ipv4.ip_forward = 1. Questa impostazione consente l'inoltro dei pacchetti; di per sé non apre il firewall né fornisce il NAT.

3. Creare una coppia di chiavi, una per il server e una per il client.

Crea la chiave del server sull'host Debian con permessi di accesso ai file restrittivi:

sudo install -d -m 700 /etc/wireguard
sudo sh -c 'umask 077; wg genkey > /etc/wireguard/server.key; wg pubkey < /etc/wireguard/server.key > /etc/wireguard/server.pub'

Genera la coppia di chiavi client sul dispositivo client quando possibile. Su un client Linux con wireguard-toolsinstallato:

umask 077
wg genkey | tee client.key | wg pubkey > client.pub

Per un telefono, crea un nuovo tunnel nell'app ufficiale WireGuard e lascia che generi le chiavi del profilo. Copia sul server solo la chiave pubblica del client. Mantienila client.keyriservata; non incollarla mai nella configurazione del server né inviarla in chat. Il manuale di Debian Bookwormwg(8) documenta i comandi principali e i campi dell'interfaccia.

4. Crea l'interfaccia del server e aggiungi il peer

Crea /etc/wireguard/wg0.confcon la seguente struttura. Sostituisci ogni segnaposto in maiuscolo con la corrispondente chiave reale. Leggi la chiave privata del server localmente con sudo cat /etc/wireguard/server.key; inserisci la chiave pubblica del client nella sezione peer.

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = SERVER_PRIVATE_KEY

[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 10.8.0.2/32

Proteggi il file perché contiene una chiave privata:

sudo chown root:root /etc/wireguard/wg0.conf
sudo chmod 600 /etc/wireguard/wg0.conf

AllowedIPs = 10.8.0.2/32assegna a questo peer un indirizzo VPN e impedisce a un altro peer di rivendicarlo. Assegna a ogni dispositivo aggiuntivo una propria coppia di chiavi e un indirizzo distinto, ad esempio 10.8.0.3/32. Non riutilizzare un profilo client su più dispositivi se hai bisogno di revoca o identità separate.

5. Aggiungere NAT IPv4 e consentire la porta WireGuard

Per il tunnel IPv4 completo di esempio, i pacchetti in uscita 10.8.0.0/24devono passare attraverso l'interfaccia pubblica con NAT di origine. Aggiungere una regola equivalente alla configurazione nftables esistente del server o al firewall manager. Questa tabella nftables autonoma illustra la regola; sostituirla eth0con l'interfaccia individuata nel passaggio 2:

table ip wg_nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    ip saddr 10.8.0.0/24 oifname "eth0" masquerade
  }
}

Se si utilizza la versione di Debian nftables.service, unire la tabella alla configurazione che il servizio carica all'avvio e convalidare il file completo sudo nft -c -f /etc/nftables.confprima di ricaricarlo. Verificare se la configurazione corrente elimina o sostituisce le regole esistenti prima di applicarla. Il NAT da solo non sovrascrive una policy di inoltro che blocca il traffico: consentire l'inoltro dall'interfaccia wg0WAN e il traffico di ritorno nel firewall attivo. nft(8)Il manuale di Debian documenta il caricamento delle regole di nftables e le istruzioni NAT.

Sia sul firewall del provider VPS che su quello dell'host, consentite il traffico UDP in entrata sulla porta 51820. Non aprite la porta TCP 51820 per questo tunnel WireGuard. Mantenete attiva la regola di accesso SSH durante la modifica delle impostazioni del firewall e utilizzate la console del provider o un altro percorso di ripristino nel caso in cui un riavvio del firewall possa causare la disconnessione.

Configurare e connettere il client

6. Creare il profilo del cliente

Crea un nuovo tunnel nell'app client WireGuard oppure salva una configurazione simile su un client Linux. Sostituisci la chiave privata, la chiave pubblica del server e l'endpoint con valori reali. L'indirizzo TEST-NET riportato di seguito è solo un esempio e non raggiungerà un server reale.

[Interface]
Address = 10.8.0.2/32
PrivateKey = CLIENT_PRIVATE_KEY
DNS = 1.1.1.1

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = 203.0.113.10:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

AllowedIPs = 0.0.0.0/0Instrada le destinazioni IPv4 attraverso il tunnel, quindi è la scelta completa per il tunnel IPv4. Per un tunnel diviso stretto che raggiunge solo l'indirizzo del server WireGuard, utilizzare 10.8.0.0/24invece. Per raggiungere una LAN dietro il server, includere la sottorete effettiva di tale LAN nel client AllowedIPs, aggiungere una rotta di ritorno o un NAT appropriato e consentire il traffico attraverso il firewall del server; questi passaggi dipendono dal router LAN e non sono inclusi in questo esempio.

PersistentKeepalive = 25Può aiutare un client dietro NAT a rimanere raggiungibile dopo periodi di inattività. È facoltativo; la documentazione di WireGuard afferma che la maggior parte degli utenti non ne ha bisogno, ma indica 25 secondi come intervallo generalmente utile in cui una mappatura NAT deve rimanere aperta. Il DNScampo è supportato da alcuni client e client basati su wg-quick; se la tua app lo ignora, imposta il DNS tramite i controlli di quell'app.

7. Avvia il tunnel e controlla l'handshake

Su Debian, avvia l'interfaccia all'avvio con:

sudo systemctl enable --now wg-quick@wg0
sudo wg show

Importa o attiva il profilo client dopo che la porta UDP 51820 è raggiungibile. In wg show, verifica che il peer previsto appaia e che latest handshakesi aggiorni dopo che il client ha inviato traffico. Il wg-quick(8)manuale di Debian Bookworm descrive l'helper di configurazione dell'interfaccia utilizzato dall'unità systemd.

Un handshake mancante indica innanzitutto problemi di raggiungibilità o di mancata corrispondenza delle chiavi: verificare l'indirizzo e la porta dell'endpoint, le regole del firewall UDP, la chiave pubblica del server nel profilo client, la chiave pubblica del client wg0.confe l'ora di sistema corretta. Un handshake senza traffico funzionante di solito indica problemi di inoltro, NAT, sovrapposizione di route o una regola di inoltro del firewall.

8. Verificare il traffico e comprendere il limite IPv6

Con il client connesso, testare innanzitutto l'indirizzo del tunnel del server, quindi verificare l'indirizzo IPv4 pubblico visualizzato da un servizio esterno di verifica degli indirizzi IPv4:

ping -c 3 10.8.0.1
curl -4 https://ifconfig.me

Il ping dovrebbe raggiungere il server se ICMP è consentito. Il controllo IPv4 esterno dovrebbe mostrare l'indirizzo IPv4 pubblico in uscita del VPS per questa configurazione full-tunnel. Se l'indirizzo pubblico non cambia, controllare AllowedIPsl'inoltro, il nome dell'interfaccia NAT e la policy di inoltro del firewall.

Questo esempio è solo IPv4. AllowedIPs = 0.0.0.0/0Non instrada IPv6, quindi un client con connettività IPv6 potrebbe comunque inviare traffico IPv6 al di fuori del tunnel. Non descrivere questa configurazione come un tunnel di privacy dual-stack completo. Per veicolare IPv6 attraverso WireGuard, allocare e instradare indirizzi IPv6 per il tunnel, abilitare l'inoltro IPv6, configurare le regole firewall e di routing appropriate e aggiungere ::/0il client solo dopo che il percorso funziona end-to-end. Il supporto del provider varia. In caso contrario, scegliere consapevolmente una policy split-tunnel e verificare il comportamento IPv6 del client.

Problemi comuni e un rapido controllo finale

• Nessun handshake: confermare il traffico UDP in entrata sulla porta 51820 sia sul firewall del provider che su quello dell'host, l'indirizzo IP pubblico o il DNS dell'endpoint e la chiave pubblica del peer di ciascuna parte.
• L'handshake funziona, ma i siti web non si caricano: confermare net.ipv4.ip_forward=1che la regola NAT utilizza l'interfaccia di uscita effettiva e che il firewall consente il traffico inoltrato.
• Solo alcune reti presentano problemi: verifica se 10.8.0.0/24si sovrappone a una rete locale o remota. Se necessario, rinumera il tunnel, aggiornando contemporaneamente sia i peer che la regola del firewall.
• Funziona fino al riavvio: verificare wg-quick@wg0che sia abilitato e che le impostazioni del firewall e di sysctl vengano mantenute durante la normale configurazione del sistema.
• IPv6 utilizza ancora la connessione locale: questo è prevedibile in questo esempio che utilizza solo IPv4. Configura e testa una rotta tunnel IPv6 prima di fare affidamento su una dichiarazione di privacy completa del tunnel.

Prima di considerare completata la configurazione, verificare che il servizio server sia attivo, wg showche segnali un handshake recente e contatori di trasferimento in aumento, che il client possa raggiungere 10.8.0.1l'indirizzo IPv4 e che un controllo in uscita IPv4 riporti l'indirizzo pubblico del server. Riavviare solo dopo aver configurato in modo permanente le impostazioni del firewall e dell'inoltro, quindi ripetere tali verifiche. Per i peer aggiuntivi, assegnare coppie di chiavi separate e indirizzi IP di tunnel univoci, quindi rimuovere un dispositivo eliminando la relativa voce peer e ricaricando l'interfaccia.