Come configurare un server VPN WireGuard Point-to-Site su Debian 12

Una VPN point-to-site WireGuard su Debian 12 (Bookworm) è un modo pratico per consentire a laptop, telefoni o workstation remote di raggiungere un server o instradare il traffico attraverso di esso. Prima di tutto, è importante chiarire un punto: WireGuard non ha una "modalità server" speciale. Ogni partecipante è un peer. In una configurazione point-to-site, un host Debian funge semplicemente da hub stabile e accessibile pubblicamente, e ogni dispositivo remoto ottiene la propria coppia di chiavi e il proprio indirizzo di tunnel.

Questa guida utilizza gli strumenti WireGuard inclusi nel pacchetto Debian, wg-quickl'inoltro IPv4 e nftables. Presuppone che il server Debian abbia accesso root o sudo e che la porta UDP 51820sia raggiungibile. Se il server si trova dietro un router domestico o aziendale, è necessario inoltrare la porta UDP all'host Debian. Se il provider di servizi Internet utilizza NAT di livello carrier (CGNAT), il normale inoltro delle porte del router potrebbe non essere sufficiente; verificare di avere effettivamente un indirizzo IP pubblico raggiungibile prima di risolvere i problemi relativi a WireGuard.

Che effetto avrà questa configurazione?

L'esempio di VPN utilizza 10.8.0.0/24. Il server è 10.8.0.1, e il primo client è 10.8.0.2. Il client può essere configurato come VPN full-tunnel, in cui il traffico Internet IPv4 esce attraverso il server Debian, oppure come split tunnel, in cui solo le reti private selezionate utilizzano WireGuard.

La documentazione ufficiale di Debian su WireGuard conferma che WireGuard è disponibile tramite i pacchetti della distribuzione, mentre la guida rapida ufficiale di WireGuard documenta la generazione delle chiavi wg-quicke il comportamento keepalive persistente opzionale. Consultare la documentazione di Debian su WireGuard , la guida rapida ufficiale di WireGuard e la pagina del manuale wg-quick di Debian .

Passaggio 1: Installare WireGuard e nftables

Aggiorna i metadati del pacchetto, quindi installa WireGuard e nftables:

sudo apt update
sudo apt install wireguard nftables

Un errore comune è pensare che Debian 12 necessiti di un modulo del kernel WireGuard esterno. Non è così. WireGuard è integrato nel kernel Linux da anni; i pacchetti Debian forniscono gli strumenti di gestione dello spazio utente necessari. Soluzione: utilizzare i pacchetti Debian anziché scaricare uno script di installazione non verificato.

Passaggio 2: Generare la coppia di chiavi del server

Crea i file chiave con autorizzazioni restrittive:

sudo -i
install -d -m 700 /etc/wireguard
umask 077
wg genkey | tee /etc/wireguard/server_private.key | wg pubkey > /etc/wireguard/server_public.key
chmod 600 /etc/wireguard/server_private.key
cat /etc/wireguard/server_public.key

La chiave privata deve rimanere tale. La chiave pubblica è quella che si copia nelle configurazioni del client. Idealmente, la chiave privata di ciascun client dovrebbe essere generata sul client stesso, anziché sul server. In questo modo, il server non avrà mai bisogno di conoscere le chiavi private dei client.

Passaggio 3: Abilitare l'inoltro IPv4

È possibile che un tunnel VPN si stabilisca correttamente anche se il traffico instradato continua a non funzionare. Il motivo è che l'inoltro IP di Linux è un'impostazione del kernel separata da WireGuard stesso. Crea un file sysctl persistente:

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

Il comando finale dovrebbe riportare net.ipv4.ip_forward = 1. La documentazione del kernel di Debian descrive ip_forwardcome l'interruttore che abilita l'inoltro dei pacchetti IPv4. Azione: verificare esplicitamente questo valore anziché presumere che l'interfaccia tunnel attivi automaticamente il routing. Consultare il manuale ip(7) di Debian e la documentazione di sysctl.conf .

Passaggio 4: Creare la configurazione del server

Leggi la chiave privata del server, quindi crea /etc/wireguard/wg0.conf:

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

[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 10.8.0.2/32

Quindi proteggi il file:

sudo chmod 600 /etc/wireguard/wg0.conf

AllowedIPsViene spesso frainteso come una semplice lista di indirizzi consentiti in stile firewall. In realtà, controlla anche il routing. Sul server, l'assegnazione 10.8.0.2/32a questo peer indica a WireGuard che i pacchetti per quell'indirizzo di tunnel specifico appartengono a questo client. Assegna a ogni client un indirizzo univoco e un [Peer]blocco separato.

Un'altra scelta utile è ometterlo SaveConfig = truequando si intende gestire questo file manualmente. Con SaveConfig, wg-quickè possibile riscrivere lo stato attivo nella configurazione allo spegnimento, il che potrebbe sovrascrivere le modifiche manuali. Azione: mantenere il file dichiarativo a meno che non si desideri specificamente salvare lo stato attivo.

Passaggio 5: Configurare il masquerading di nftables

Se i client full-tunnel devono accedere a Internet tramite il server Debian, la soluzione più semplice è il masquerading IPv4. Per prima cosa, identifica l'interfaccia di uscita del server:

ip route get 1.1.1.1

Cerca l'interfaccia dopo dev, come eth0, ens3, o enp1s0. Non dare per scontato che sia sempre eth0.

Se gestisci già /etc/nftables.conf, unisci la seguente tabella NAT al tuo set di regole esistente invece di sostituire il file:

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

Sostituire eth0con l'interfaccia di uscita effettiva. Convalidare prima del caricamento:

sudo nft -c -f /etc/nftables.conf
sudo systemctl enable --now nftables
sudo nft list ruleset

Il NAT non è intrinsecamente richiesto da WireGuard. Se la LAN di destinazione ha già una rotta di ritorno verso 10.8.0.0/24, l'accesso instradato può funzionare senza masquerading. Il NAT è utile principalmente quando si desidera che i client remoti utilizzino la rotta Internet esistente del server e non si controllano le rotte di ritorno altrove. Azione: utilizzare il masquerading per il semplice caso di uscita da Internet; preferire l'instradamento esplicito quando si controlla la rete e si desidera che gli indirizzi sorgente vengano preservati.

Hai bisogno anche di regole firewall?

Dipende dal firewall già installato. Se la policy di input di nftables è restrittiva, consenti il ​​traffico UDP in entrata 51820. Se la tua catena di inoltro ha una policy di blocco predefinita, aggiungi delle regole per consentire il traffico in wg0entrata verso la destinazione prevista e per consentire il traffico di ritorno stabilito. I provider di VPS cloud potrebbero anche avere un gruppo di sicurezza separato o un firewall del provider che deve consentire il traffico UDP 51820.

Non incollare ciecamente un set di regole firewall completamente nuovo e predefinito in un server SSH remoto. Questo potrebbe impedirti l'accesso. Azione consigliata: esamina sudo nft list rulesete integra WireGuard nel firewall che già possiedi.

Passaggio 6: Creare il profilo del cliente

Sul client, genera la propria coppia di chiavi utilizzando l'app WireGuard o wg genkey. Un profilo IPv4 full-tunnel ha questo aspetto:

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

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

Sostituire vpn.example.comcon il nome DNS pubblico o l'indirizzo IP pubblico del server. La DNSriga è facoltativa e il supporto dell'implementazione client varia. Per uno split tunnel, modificare AllowedIPssolo le reti che devono attraversare la VPN, ad esempio 10.8.0.0/24più una LAN privata come 192.168.50.0/24.

PersistentKeepalive = 25È anche facoltativo. La documentazione ufficiale di WireGuard raccomanda 25 secondi come valore ragionevole quando un peer dietro NAT o un firewall stateful deve mantenere la propria mappatura durante i periodi di inattività. Non si tratta di un'impostazione relativa alle prestazioni e non è obbligatoria per ogni client. Azione: utilizzarla principalmente per i client in roaming o NAT che altrimenti diventano irraggiungibili dopo un periodo di inattività.

Passaggio 7: Avviare WireGuard all'avvio del sistema

Avvia prima nftables, poi abilita l'interfaccia WireGuard:

sudo systemctl enable --now nftables
sudo systemctl enable --now wg-quick@wg0
systemctl is-active nftables
systemctl is-active wg-quick@wg0

wg-quick@wg0legge /etc/wireguard/wg0.conf. Il wg-quickmanuale conferma che questa convenzione di denominazione è la normale scorciatoia per le configurazioni memorizzate in /etc/wireguard. Azione: utilizzare il servizio anziché uno script di avvio personalizzato a meno che non si disponga di una progettazione di Network Manager più complessa.

Passaggio 8: Verificare l'handshake e il traffico

Collega il client, quindi ispeziona il server:

sudo wg show
ip address show wg0
ping -c 3 10.8.0.2

Un peer funzionante normalmente mostra un handshake recente e contatori di trasferimento diversi da zero dopo che il traffico ha attraversato il tunnel. Se hai configurato un tunnel completo, verifica l'indirizzo IPv4 pubblico del client con un servizio di verifica IP affidabile; dovrebbe corrispondere all'indirizzo di uscita del server Debian.

Problemi comuni e il loro vero significato

Tunnel intero o tunnel diviso: quale scegliere?

Utilizza un tunnel completo quando l'obiettivo è proteggere il traffico su reti Wi-Fi non attendibili o far uscire il traffico Internet dal server Debian. Utilizza un tunnel diviso quando hai bisogno solo di accedere in remoto a un server, una rete domestica, un laboratorio o un'applicazione interna e desideri che il normale traffico Internet rimanga locale. La scelta è controllata principalmente dal client AllowedIPs.

Per una piccola implementazione point-to-site, la configurazione sopra descritta è sufficiente per stabilire una base di partenza gestibile: un blocco peer per client, indirizzi tunnel univoci, servizi gestiti da Debian e nftables per il comportamento di routing effettivamente necessario. Per implementazioni più grandi, la distribuzione delle chiavi, il ciclo di vita dei peer, il DNS, la registrazione dei log e la gestione della configurazione diventano problematiche operative, sebbene il protocollo WireGuard in sé rimanga semplice.

Lista di controllo per la verifica finale

• wg-quick@wg0è attivo e wg0ha 10.8.0.1/24.
• Il server è in ascolto su UDP 51820e tale porta è raggiungibile attraverso qualsiasi firewall o router a monte.
• Ogni client possiede una propria coppia di chiavi e /32una voce univoca sul server.
• net.ipv4.ip_forwarduguale 1quando è richiesto l'accesso instradato.
• Il masquerading di nftables è presente per l'accesso a Internet full-tunnel, a meno che non si utilizzino intenzionalmente percorsi di ritorno instradati.
• wg showMostra l'handshake più recente dopo che il client ha inviato il traffico.
• Il cliente AllowedIPscorrisponde al progetto previsto per la galleria completa o per la galleria divisa.

Questi passaggi sono pensati per Debian 12 e per gli strumenti WireGuard standard disponibili tramite Debian. La topologia di rete, il NAT upstream, i firewall cloud, il routing LAN privato e le policy IPv6 sono specifici dell'ambiente, quindi non possono essere dedotti dalla sola configurazione di WireGuard. È necessario convalidare ciascun elemento separatamente, anziché considerare ogni problema di connettività come un errore di WireGuard.