OnLinux.ro

, ,

Instalare și configurare WireGuard Server pe Linux: ghid complet

👁 2 vizualizări

Într-un articol anterior am construit un tunnel simplu WireGuard între două servere Linux. Înainte să trecem la arhitecturi mai interesante — site-to-site și client-to-server — merită să construim corect baza: instalarea și configurarea unui nod WireGuard care va funcționa ca punct central al infrastructurii VPN.

Dacă vrei mai întâi o introducere practică foarte simplă, citește WireGuard: VPN simplu între două servere Linux.

În acest ghid vom instala și pregăti un server WireGuard pe Ubuntu LTS, Debian, AlmaLinux și Rocky Linux. Vom discuta despre adresarea tunnel-ului, generarea și protejarea cheilor, configurația wg0, firewall, IP forwarding, systemd și verificările pe care merită să le faci înainte să adaugi primul peer.

Ce este, de fapt, un „WireGuard Server”?

WireGuard nu folosește modelul clasic server/client întâlnit la multe alte aplicații. Din perspectiva protocolului, fiecare participant este un peer.

În practică însă, numim „server WireGuard” nodul care are de obicei:

  • o adresă IP publică sau un hostname stabil;
  • un port UDP fix deschis în firewall;
  • o adresă fixă în rețeaua VPN;
  • o pereche de chei WireGuard;
  • configurațiile peer-ilor care se pot conecta;
  • opțional, rol de router între VPN și alte rețele.

Această diferență este importantă deoarece WireGuard rămâne un protocol peer-to-peer chiar și atunci când construim o topologie de tip hub-and-spoke.

Topologia pe care o pregătim

În acest articol pregătim doar infrastructura de bază:

                     Internet
                        |
                        |
                UDP 51820
                        |
              +----------------+
              | WireGuard      |
              | Server         |
              |                |
              | Public IP      |
              | wg0: 10.44.0.1 |
              +----------------+
                     /   \
                    /     \
                   /       \
             viitor peer   viitor peer

În articolele următoare vom folosi această bază pentru două scenarii:

  1. Site-to-site: două rețele LAN diferite comunicate prin WireGuard.
  2. Client-to-server: laptopuri, telefoane sau stații de administrare conectate la infrastructura noastră prin VPN.

Alegerea rețelei WireGuard

Înainte de instalare trebuie să alegem subnetul pe care îl vom folosi în interiorul tunnel-ului.

Pentru exemplele acestei serii vom folosi:

10.44.0.0/24

Serverul va avea:

10.44.0.1/24

iar peer-ii vor putea folosi ulterior adrese precum:

10.44.0.2
10.44.0.3
10.44.0.4
...

Alege subnetul VPN înainte să începi configurarea și verifică să nu se suprapună cu LAN-uri, VPC-uri, rețele Docker, Kubernetes sau alte VPN-uri existente.

De exemplu, dacă rețeaua unei locații este deja 10.44.0.0/24, folosirea aceleiași rețele pentru tunnel va crea probleme de routing.

Portul WireGuard

Vom utiliza portul UDP standard întâlnit frecvent în exemplele WireGuard:

51820/udp

Nu este obligatoriu să folosești 51820. WireGuard poate asculta pe orice port UDP disponibil, dar pe un nod care primește conexiuni este recomandat să configurezi un port fix și să îl documentezi.

Instalarea WireGuard pe Ubuntu și Debian

Începem prin actualizarea indexului de pachete:

sudo apt update

Apoi instalăm WireGuard:

sudo apt install wireguard

Verificăm utilitarul:

wg --version

Pe kernelurile Linux moderne, suportul WireGuard este disponibil direct în kernel, iar pachetul ne oferă instrumentele de administrare precum wg și wg-quick.

Instalarea pe AlmaLinux și Rocky Linux

Pe distribuțiile Enterprise Linux moderne instalăm instrumentele WireGuard cu DNF:

sudo dnf install wireguard-tools

Dacă pachetul nu este disponibil în repository-urile configurate pe sistemul tău, pe Rocky Linux și alte distribuții compatibile RHEL poate fi necesară activarea EPEL:

sudo dnf install epel-release
sudo dnf install wireguard-tools

Verificare:

wg --version

Verificarea suportului WireGuard

Putem cere kernelului să încarce modulul WireGuard:

sudo modprobe wireguard

și putem verifica:

lsmod | grep wireguard

Pe anumite kerneluri modulul poate fi integrat direct, caz în care interpretarea simplă a rezultatului lsmod trebuie făcută cu atenție. Testul practic rămâne posibilitatea de a crea o interfață WireGuard.

Directorul /etc/wireguard

Configurațiile și cheile sunt păstrate în mod obișnuit în:

/etc/wireguard/

Creăm directorul dacă este necesar și îl protejăm:

sudo mkdir -p /etc/wireguard
sudo chmod 700 /etc/wireguard

Generarea cheilor serverului

WireGuard folosește o pereche de chei publică/privată pentru fiecare peer.

Înainte de generare folosim un umask restrictiv, astfel încât fișierele nou create să nu fie accesibile altor utilizatori:

umask 077

Generăm cheia privată și derivăm cheia publică:

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

Verificăm permisiunile:

sudo ls -l /etc/wireguard/server_*.key

Cheia privată trebuie tratată ca o parolă foarte sensibilă. Nu trebuie publicată într-un articol, repository Git, ticket sau canal de chat.

Cheia publică poate fi afișată fără probleme:

sudo cat /etc/wireguard/server_public.key

Private key vs public key

Cheie Utilizare Poate fi distribuită?
PrivateKey Identitatea secretă a peer-ului Nu
PublicKey Identifică peer-ul în configurația celorlalte noduri Da

Fiecare peer își păstrează propria cheie privată și primește doar cheia publică a celuilalt peer.

Construirea configurației wg0

Convenția uzuală este ca prima interfață WireGuard să se numească wg0.

Fișierul corespunzător va fi:

/etc/wireguard/wg0.conf

Mai întâi citim cheia privată:

sudo cat /etc/wireguard/server_private.key

Apoi construim configurația:

[Interface]
Address = 10.44.0.1/24
ListenPort = 51820
PrivateKey = <SERVER_PRIVATE_KEY>

Înlocuiește <SERVER_PRIVATE_KEY> cu cheia privată reală a serverului.

Protejăm fișierul:

sudo chmod 600 /etc/wireguard/wg0.conf

Ce înseamnă secțiunea [Interface]?

Configurația:

[Interface]
Address = 10.44.0.1/24
ListenPort = 51820
PrivateKey = ...

descrie interfața WireGuard locală.

  • Address este adresa serverului în interiorul tunnel-ului.
  • ListenPort este portul UDP pe care serverul așteaptă trafic WireGuard.
  • PrivateKey este cheia privată a acestui nod.

De ce nu avem încă [Peer]?

În această etapă pregătim doar serverul. Nu am adăugat încă niciun client și niciun site remote.

Ulterior fiecare peer va primi propria secțiune:

[Peer]
PublicKey = ...
AllowedIPs = ...

Pentru peers aflați la adrese cunoscute poate apărea și:

Endpoint = vpn.example.ro:51820

AllowedIPs este una dintre cele mai importante setări WireGuard

Numele poate induce în eroare. AllowedIPs nu este doar o listă de adrese „permise”. În arhitectura WireGuard, această setare participă și la alegerea peer-ului către care este trimis traficul.

De exemplu:

[Peer]
PublicKey = ABC...
AllowedIPs = 10.44.0.2/32

înseamnă că traficul destinat adresei 10.44.0.2 trebuie asociat acelui peer, iar traficul primit de la peer este verificat în raport cu adresele configurate pentru el.

Într-o configurație simplă, oferă fiecărui client o adresă VPN unică și evită suprapunerea inutilă a rețelelor definite în AllowedIPs.

Pornirea interfeței manual

Înainte să activăm serviciul permanent, putem testa configurația cu wg-quick:

sudo wg-quick up wg0

Verificăm interfața:

ip addr show wg0

și starea WireGuard:

sudo wg show

Ar trebui să vedem interfața wg0, cheia publică și portul de ascultare.

Oprirea interfeței

sudo wg-quick down wg0

Acest mecanism este foarte util în timpul testării configurației.

Pornirea automată cu systemd

După ce configurația este validă, o putem activa permanent:

sudo systemctl enable --now wg-quick@wg0

Verificare:

systemctl status wg-quick@wg0

Numele serviciului trebuie să corespundă numelui fișierului din /etc/wireguard. Astfel, wg0.conf este administrat de wg-quick@wg0.

Verificarea portului UDP

sudo ss -lunp | grep 51820

WireGuard utilizează UDP, nu TCP. Acest lucru este important atunci când verifici firewall-ul sau security group-ul furnizorului cloud.

Firewall pe Ubuntu și Debian cu UFW

Dacă folosești UFW, permitem portul WireGuard:

sudo ufw allow 51820/udp

Verificare:

sudo ufw status verbose

Nu uita că un VPS poate avea și un firewall extern configurat în control panel-ul providerului. În acest caz portul UDP trebuie permis și acolo.

Firewall pe AlmaLinux și Rocky Linux

Cu firewalld:

sudo firewall-cmd --permanent --add-port=51820/udp
sudo firewall-cmd --reload

Verificare:

sudo firewall-cmd --list-ports

Este necesar IP forwarding?

Pentru un tunnel în care serverul comunică doar cu propriile adrese VPN, IP forwarding nu este obligatoriu.

Devine necesar când serverul trebuie să ruteze trafic între WireGuard și alte rețele, de exemplu:

  • VPN → Internet;
  • VPN → LAN;
  • LAN A → WireGuard → LAN B;
  • un client VPN care trebuie să acceseze alte rețele prin server.

Acesta va fi obligatoriu în configurațiile noastre site-to-site.

Activarea IPv4 forwarding

Dacă serverul va avea rol de router, creează o configurație persistentă:

sudo tee /etc/sysctl.d/99-wireguard-forward.conf > /dev/null <<'EOF'
net.ipv4.ip_forward = 1
EOF

Aplicăm:

sudo sysctl --system

Verificare:

sysctl net.ipv4.ip_forward

Rezultatul dorit pentru un router este:

net.ipv4.ip_forward = 1

IPv6 forwarding

Dacă proiectezi tunnel-ul și pentru IPv6 și serverul va ruta pachete IPv6, trebuie analizată separat și activarea:

net.ipv6.conf.all.forwarding = 1

Nu activa forwarding-ul doar „pentru orice eventualitate”. Configurează-l atunci când topologia VPN chiar cere rutare.

Routing nu este același lucru cu NAT

O confuzie frecventă este presupunerea că orice server WireGuard are nevoie automat de masquerading/NAT.

Nu este adevărat.

Dacă toate rețelele implicate cunosc rutele către celelalte rețele, putem folosi routing pur, fără NAT. În multe configurații site-to-site aceasta este soluția mai curată.

Masquerading devine util în alte scenarii, de exemplu când un client folosește serverul WireGuard pentru acces la Internet și infrastructura upstream nu are rută către subnetul VPN.

Nu adăuga automat PostUp și PostDown copiate de pe Internet

Multe tutoriale WireGuard folosesc configurații precum:

PostUp = ...
PostDown = ...

Aceste directive pot modifica firewall-ul sau routing-ul atunci când interfața pornește și se oprește.

Sunt utile, dar trebuie înțelese. Nu copia reguli de iptables, nftables sau firewalld fără să știi:

  • ce interfață WAN ai;
  • ce subnet WireGuard folosești;
  • dacă ai nevoie de NAT;
  • ce politică de firewall există deja;
  • dacă serverul folosește nftables, firewalld sau alt manager.

În articolele site-to-site și client-to-server vom construi regulile necesare pentru fiecare scenariu în parte.

Atenție la SaveConfig

wg-quick suportă opțiunea:

SaveConfig = true

Pentru un administrator care menține configurația declarativ în wg0.conf, eu prefer să nu activez această opțiune implicit.

Motivul este simplu: configurația runtime poate fi scrisă înapoi în fișier atunci când interfața este oprită, ceea ce poate suprascrie modificări manuale neașteptat.

PersistentKeepalive

În multe configurații vei întâlni:

PersistentKeepalive = 25

Această setare nu trebuie pusă automat pe fiecare peer.

Este utilă mai ales pentru un peer aflat în spatele NAT-ului sau unui firewall stateful, atunci când vrem ca maparea NAT să rămână disponibilă și peer-ul să poată primi trafic chiar după perioade fără activitate.

O valoare de 25 de secunde este frecvent folosită în acest scenariu.

MTU: nu optimiza înainte să existe o problemă

WireGuard și wg-quick gestionează în mod normal MTU-ul fără să fie nevoie să îl setezi manual.

Uneori, în rețele cu encapsulare suplimentară, PPPoE, cloud networking sau alte tunnel-uri, pot apărea probleme de Path MTU.

Simptomele pot fi interesante: ping-ul funcționează, dar anumite pagini HTTPS sau transferuri mari se blochează.

Nu începe însă configurarea WireGuard prin copierea unei valori MTU din alt tutorial. Testează mai întâi configurația implicită.

Verificarea configurației active

Comanda principală este:

sudo wg show

După ce vom adăuga peers, vom vedea informații precum:

  • public key;
  • endpoint;
  • AllowedIPs;
  • latest handshake;
  • transfer received;
  • transfer sent;
  • persistent keepalive.

Latest handshake este unul dintre primele lucruri pe care le verificăm

După configurarea unui peer, comanda:

sudo wg show

va afișa momentul ultimului handshake reușit.

Dacă handshake-ul nu apare deloc, înainte să investighezi routing-ul LAN verifică:

  • cheile publice;
  • endpoint-ul;
  • portul UDP;
  • firewall-ul;
  • NAT-ul;
  • adresa IP publică;
  • conectivitatea dintre peers.

Verificări de bază pentru server

sudo wg show

ip addr show wg0

ip route

sudo ss -lunp | grep 51820

systemctl status wg-quick@wg0

Dacă serverul va ruta trafic:

sysctl net.ipv4.ip_forward

Verificarea logurilor

Pentru serviciul systemd:

journalctl -u wg-quick@wg0

Pentru boot-ul curent:

journalctl -u wg-quick@wg0 -b

Dacă interfața nu pornește, aceste loguri sunt mult mai utile decât modificarea aleatorie a configurației.

Pentru o abordare mai generală de troubleshooting, vezi și Diagnosticarea și monitorizarea unui Linux Server: ghid practic.

Backup-ul configurației WireGuard

Fișierele din /etc/wireguard fac parte din configurația critică a serverului și trebuie incluse într-o strategie de backup securizată.

Totuși, deoarece directorul conține chei private, backup-ul trebuie protejat cel puțin la același nivel ca serverul original.

Un backup necriptat al cheilor private WireGuard poate transforma o copie de siguranță într-un risc de securitate.

Rotirea unei chei compromise

Dacă o cheie privată a fost expusă, nu încerca să „schimbi parola” cheii. Generează o nouă pereche de chei și actualizează configurația peer-ilor care aveau cheia publică veche.

umask 077
wg genkey | tee new_private.key | wg pubkey > new_public.key

Checklist WireGuard Server

  1. Alege un subnet VPN care nu se suprapune cu celelalte rețele.
  2. Alege un port UDP fix.
  3. Instalează WireGuard din repository-urile distribuției.
  4. Protejează directorul /etc/wireguard.
  5. Generează o pereche de chei unică pentru server.
  6. Nu distribui niciodată cheia privată.
  7. Configurează adresa wg0.
  8. Configurează ListenPort.
  9. Protejează wg0.conf cu permisiuni restrictive.
  10. Deschide doar portul UDP necesar.
  11. Verifică și firewall-ul providerului cloud.
  12. Activează IP forwarding doar când serverul trebuie să ruteze trafic.
  13. Nu adăuga NAT dacă topologia poate funcționa prin routing normal.
  14. Nu copia reguli PostUp/PostDown fără să le înțelegi.
  15. Nu activa SaveConfig automat.
  16. Folosește PersistentKeepalive numai unde este necesar.
  17. Testează interfața cu wg-quick.
  18. Activează serviciul systemd.
  19. Verifică wg show, routing-ul și portul UDP.
  20. Include configurația într-un backup securizat.

Configurația minimă rezultată

La finalul acestui articol serverul nostru are o configurație de bază foarte simplă:

[Interface]
Address = 10.44.0.1/24
ListenPort = 51820
PrivateKey = <SERVER_PRIVATE_KEY>

Interfața este activată cu:

sudo systemctl enable --now wg-quick@wg0

iar starea poate fi verificată cu:

sudo wg show

Ce urmează?

Acum avem fundația corectă pentru următoarele două configurații.

WireGuard site-to-site

Vom conecta două rețele diferite, de exemplu:

Sediul A
192.168.10.0/24
        |
   WireGuard
        |
Sediul B
192.168.20.0/24

Vom discuta despre AllowedIPs, IP forwarding, rute statice, firewall și diferența dintre routing și NAT.

WireGuard client-to-server

Apoi vom conecta laptopuri și telefoane la server:

Laptop
   \
Telefon ---- WireGuard Server ---- LAN / Internet
   /
PC Admin

Vom construi atât un VPN de tip split-tunnel, cât și un scenariu full-tunnel în care traficul Internet al clientului trece prin server.

Concluzie

WireGuard este simplu tocmai pentru că nu încearcă să rezolve automat toate aspectele unei infrastructuri VPN. Protocolul construiește tunnel-ul criptat, iar administratorul păstrează controlul asupra adresării, rutelor, firewall-ului și distribuției cheilor.

O configurație WireGuard bună începe cu câteva decizii foarte clare: un subnet VPN fără suprapuneri, chei individuale pentru fiecare peer, un endpoint stabil, un port UDP documentat și reguli de routing explicite.

În loc să adăugăm de la început NAT, reguli PostUp complexe și zeci de rute, am construit mai întâi un server minimal și predictibil. În articolele următoare vom adăuga funcționalitatea necesară fiecărei topologii exact acolo unde este nevoie.

La WireGuard, configurația simplă nu este doar mai ușor de administrat. Este și mult mai ușor de depanat atunci când apare o problemă.

Continuă seria pornind de la exemplul simplu WireGuard între două servere Linux, iar în următorul ghid vom construi o configurație site-to-site completă.