Cum se configurează o rețea VPN punct-la-site WireGuard pe Debian 12

Scenariu ilustrativ: Maya folosește un VPS Debian 12 ca punct final VPN personal atunci când lucrează dintr-o cafenea. Laptopul ei ar trebui să ajungă la VPS printr-un tunel WireGuard criptat și să trimită traficul de internet IPv4 prin acel server. Acest exemplu nu este un raport al unui test live; IP-urile publice, cheile și ieșirea terminalului afișate mai jos sunt substituenți sau machete reprezentative.

Această configurație este un VPN point-to-site: un client se conectează la un server. Folosește instrumentele WireGuard incluse în pachetul Debian, un singur peer, redirecționare IPv4 și NAT IPv4. Presupune că VPS-ul are o adresă IPv4 publică sau redirecționată prin port, îl puteți administra cu sudo și portul UDP 51820 îl poate accesa. Ghidul nu configurează IPv6 rutat sau o rețea privată în spatele VPS-ului.

Planificați mai întâi adresele și accesul

Exemplul folosește 10.8.0.0/24pentru VPN, atât 10.8.0.1pe server, cât și 10.8.0.2pe primul client Maya. Folosește o subrețea care nu se suprapune cu rețelele Wi-Fi, de birou sau cloud ale clientului. O coliziune poate trimite traficul pe o rută greșită chiar și atunci când handshake-ul reușește.

WireGuard utilizează autentificarea cu cheie publică. Serverul are nevoie de cheia publică a clientului, iar clientul are nevoie de cheia publică a serverului; fiecare cheie privată rămâne pe dispozitivul care o deține. Documentația Debian WireGuard descrie configurarea pachetului și a peer-ilor, în timp ce ghidul de pornire rapidă WireGuard documentează generarea de chei și comportamentul keepalive. Consultați documentația Debian WireGuard și Ghidul de pornire rapidă WireGuard .

Configurați serverul Debian 12

1. Instalați uneltele

Actualizați indexul pachetului și instalați WireGuard plus nftables, care vor oferi exemplul de regulă de mascare IPv4. Rulați acestea pe VPS:

sudo apt update
sudo apt install wireguard nftables

Debian împachetează WireGuard prin wireguardmetapachetul și instrumentele sale. Dacă serverul folosește deja un manager de firewall, cum ar fi UFW, firewalld sau reguli gestionate de furnizor, identificați setul său de reguli activ înainte de a adăuga ceva. Nu înlocuiți o configurație de firewall existentă cu acest exemplu.

2. Găsiți interfața orientată spre public și activați redirecționarea

Întreabă tabela de rutare ce interfață folosește Debian pentru a ajunge la o adresă IPv4 externă:

ip route get 1.1.1.1

În exemplu, ruta folosește eth0. VPS-ul dvs. poate afișa un nume diferit, cum ar fi ens3sau enp1s0; utilizați numele din propria ieșire în regula NAT mai târziu. De asemenea, rețineți adresa IPv4 publică sau numele DNS al serverului. Dacă serverul se află în spatele unui router, redirecționați UDP 51820 de la acel router către gazda Debian.

Redirecționarea IPv4 este necesară pentru un tunel complet. Activați-o acum și mențineți-o după repornire:

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

Ultima comandă ar trebui să raporteze [numele net.ipv4.ip_forward = 1codului poștal]. Această setare permite redirecționarea pachetelor; nu deschide singură firewall-ul și nu oferă NAT.

3. Creați cheia serverului și o pereche de chei client

Creați cheia serverului pe gazda Debian cu permisiuni restrictive pentru fișiere:

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ți perechea de chei client pe dispozitivul client atunci când este posibil. Pe un client Linux cu wireguard-toolsinstalat:

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

Pentru un telefon, creați un tunel nou în aplicația oficială WireGuard și lăsați-o să genereze cheile de profil. Copiați doar cheia publică a clientului pe server. Păstrați- client.keyo privată; nu o lipiți niciodată în configurația serverului și nu o trimiteți în chat. Manualul Debian Bookwormwg(8) documentează comenzile de la taste și câmpurile interfeței.

4. Creați interfața serverului și adăugați peer-ul

Realizați /etc/wireguard/wg0.confcu următoarea structură. Înlocuiți fiecare substituent majusculă cu cheia reală corespunzătoare. Citiți cheia privată a serverului local cu sudo cat /etc/wireguard/server.key; plasați cheia publică a clientului în secțiunea 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

Protejați fișierul deoarece conține o cheie privată:

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

AllowedIPs = 10.8.0.2/32atribuie acestui peer o adresă VPN și împiedică un alt peer să o revendice. Atribuiți fiecărui dispozitiv suplimentar propria pereche de chei și o adresă distinctă, cum ar fi 10.8.0.3/32. Nu reutilizați un profil de client pe mai multe dispozitive dacă aveți nevoie de o revocare sau o identitate separată.

5. Adăugați IPv4 NAT și permiteți portul WireGuard

Pentru exemplul de tunel IPv4 complet, pachetele de ieșire de la 10.8.0.0/24trebuie să plece prin interfața orientată spre public cu NAT sursă. Adăugați o regulă echivalentă la configurația nftables existentă a serverului sau la managerul de firewall. Acest tabel nftables independent ilustrează regula; înlocuiți-o eth0cu interfața descoperită la pasul 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
  }
}

Dacă utilizați Debian nftables.service, integrați tabelul în configurația pe care serviciul o încarcă la pornire și validați fișierul complet sudo nft -c -f /etc/nftables.confînainte de a-l reîncărca. Verificați dacă configurația curentă șterge sau înlocuiește regulile existente înainte de a o aplica. NAT singur nu suprascrie o politică de forward-chain care elimină traficul: permiteți redirecționarea de la interfața WAN și traficul de retur în firewall-ul activ. Manualulwg0 Debian documentează încărcarea regulilor nftables și instrucțiunile NAT.nft(8)

Atât în ​​firewall-ul furnizorului VPS, cât și în orice firewall gazdă, permiteți UDP 51820 de intrare. Nu deschideți TCP 51820 pentru acest tunel WireGuard. Mențineți regula de acces SSH activă în timp ce modificați politica firewall-ului și utilizați o consolă a furnizorului sau o altă cale de recuperare dacă o reîncărcare a firewall-ului v-ar putea deconecta.

Configurați și conectați clientul

6. Construiți profilul clientului

Creați un tunel nou în aplicația client WireGuard sau salvați o configurație ca aceasta pe un client Linux. Înlocuiți cheia privată, cheia publică a serverului și punctul final cu valori reale. Adresa TEST-NET de mai jos este doar un exemplu și nu va ajunge la un server real.

[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/0direcționează destinațiile IPv4 prin tunel, deci este opțiunea completă pentru tunelul IPv4. Pentru un tunel îngust și divizat care ajunge doar la adresa serverului WireGuard, utilizați 10.8.0.0/24în schimb . Pentru a ajunge la o rețea locală (LAN) în spatele serverului, includeți subrețeaua reală a acelei rețele locale în fișierul clientului AllowedIPs, adăugați o rută de retur sau un NAT adecvat și permiteți traficul prin firewall-ul serverului; acești pași depind de routerul LAN și sunt în afara acestui exemplu.

PersistentKeepalive = 25poate ajuta un client din spatele NAT să rămână accesibil după perioadele de inactivitate. Este opțional; documentația WireGuard precizează că majoritatea utilizatorilor nu au nevoie de el, dar oferă 25 de secunde ca interval util în general atunci când o mapare NAT trebuie să rămână deschisă. Câmpul DNSeste acceptat de unii clienți și clienți pe baza wg-quick; dacă aplicația dvs. îl ignoră, setați DNS prin intermediul controalelor proprii ale aplicației respective.

7. Porniți tunelul și verificați strângerea de mână

Pe Debian, pornește interfața la boot cu:

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

Importați sau activați profilul clientului după ce UDP 51820 este accesibil. În wg show, verificați dacă apare peer-ul așteptat și dacă latest handshakese actualizează după ce clientul trimite trafic. wg-quick(8)Manualul pentru Debian Bookworm descrie ajutorul de configurare a interfeței utilizat de unitatea systemd.

O strângere de mână lipsă indică în primul rând accesibilitatea sau nepotrivirile de chei: confirmați adresa și portul punctului final, regulile firewall-ului UDP, cheia publică a serverului în profilul clientului, cheia publică a clientului în wg0.confși ora corectă a sistemului. O strângere de mână fără trafic funcțional indică de obicei redirecționarea, NAT, suprapunerea rutelor sau o regulă de redirecționare a lanțului de firewall.

8. Verificați traficul și înțelegeți limita IPv6

Cu clientul conectat, testați mai întâi adresa tunelului serverului, apoi verificați adresa IPv4 publică văzută de un serviciu extern de verificare a adreselor IPv4:

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

Ping-ul ar trebui să ajungă la server dacă ICMP este permis. Verificarea IPv4 externă ar trebui să afișeze adresa publică de ieșire a VPS-ului pentru această configurație full-tunnel. Dacă adresa publică nu se modifică, verificați AllowedIPs, redirecționarea, numele interfeței NAT și politica de redirecționare a firewall-ului.

Acest exemplu este doar pentru IPv4. AllowedIPs = 0.0.0.0/0Nu direcționează IPv6, deci un client cu conectivitate IPv6 poate trimite în continuare trafic IPv6 în afara tunelului. Nu descrieți această configurație ca un tunel de confidențialitate complet cu stivă duală. Pentru a transporta IPv6 prin WireGuard, alocați și direcționați adrese IPv6 pentru tunel, activați redirecționarea IPv6, configurați firewall-ul și regulile de rutare corespunzătoare și adăugați ::/0clientul numai după ce acea cale funcționează de la un capăt la altul. Asistența furnizorului variază. În caz contrar, alegeți o politică de tunel divizat în cunoștință de cauză și verificați comportamentul IPv6 al clientului.

Probleme comune și o verificare finală rapidă

• Fără handshake: confirmați UDP 51820 de intrare atât la firewall-ul furnizorului, cât și la cel al gazdei, adresa IP publică sau DNS-ul endpoint-ului și cheia publică peer a fiecărei părți.
• Strângerea de mână funcționează, dar site-urile web nu se încarcă: confirmați net.ipv4.ip_forward=1, regula NAT folosește interfața de ieșire reală, iar firewall-ul permite traficul redirecționat.
• Doar unele rețele eșuează: verificați dacă 10.8.0.0/24se suprapune cu o rețea locală sau la distanță. Renumerotați tunelul dacă este necesar, actualizând atât peer-ii, cât și regula firewall-ului.
• Funcționează până la repornire: confirmarea wg-quick@wg0este activată și că setările firewall și sysctl sunt persistente prin configurația normală a sistemului.
• IPv6 folosește în continuare conexiunea locală: acest lucru este de așteptat în acest exemplu exclusiv IPv4. Configurați și testați o rută de tunel IPv6 înainte de a vă baza pe o revendicare de confidențialitate pentru întregul tunel.

Înainte de a finaliza configurarea, verificați dacă serviciul serverului este activ, wg showraportează o handshake recentă și contoare de transfer în creștere, clientul poate accesa 10.8.0.1și o verificare de ieșire IPv4 raportează adresa publică a serverului. Reporniți numai după ce setările de firewall persistent și de redirecționare sunt activate, apoi repetați aceste verificări. Pentru peer-i suplimentari, emiteți perechi de chei separate și IP-uri unice de tunel, apoi eliminați un dispozitiv ștergând intrarea peer-ului și reîncărcând interfața.