OnLinux.ro

, ,

WireGuard Site-to-Site pe Linux: conectarea a două rețele prin VPN

👁 1 vizualizare

În articolele anterioare am văzut cum funcționează un tunnel simplu WireGuard între două servere Linux și am construit configurația de bază a unui server WireGuard. Următorul pas este unul dintre cele mai interesante scenarii practice: VPN site-to-site.

Într-o configurație site-to-site nu conectăm doar două servere. Conectăm două rețele întregi, astfel încât sistemele dintr-o locație să poată comunica direct cu sistemele din cealaltă locație prin tunnel-ul criptat WireGuard.

Vom construi această configurație pentru servere Linux precum Ubuntu LTS, Debian, AlmaLinux și Rocky Linux, folosind routing real între rețele și evitând NAT-ul acolo unde nu este necesar.

Dacă nu ai configurat încă nodurile WireGuard, recomand să citești mai întâi Instalare și configurare WireGuard Server pe Linux.

Ce înseamnă WireGuard site-to-site?

Să presupunem că avem două sedii.

SITE A
LAN: 192.168.10.0/24

SITE B
LAN: 192.168.20.0/24

Fără VPN, cele două rețele sunt complet separate.

După configurarea WireGuard vrem ca un sistem:

192.168.10.50

din Site A să poată comunica direct cu:

192.168.20.50

din Site B.

Topologia folosită în acest ghid

             SITE A                         SITE B

        Internet                         Internet

       203.0.113.10                    198.51.100.20
             |                                |
             |                                |
      +-------------+                  +-------------+
      | WG Gateway  |                  | WG Gateway  |
      | Site A      |                  | Site B      |
      |             |                  |             |
      | wg0         |                  | wg0         |
      | 10.44.0.1   |==================| 10.44.0.2   |
      |             |    WireGuard     |             |
      | LAN         |                  | LAN         |
      | .10.254     |                  | .20.254     |
      +-------------+                  +-------------+
             |                                |
             |                                |
    192.168.10.0/24                  192.168.20.0/24
             |                                |
        LAN Site A                       LAN Site B

Adresele publice 203.0.113.10 și 198.51.100.20 sunt folosite doar ca exemple. În configurația reală trebuie înlocuite cu IP-urile sau hostname-urile reale.

Planul de adresare

Element Site A Site B
Public IP 203.0.113.10 198.51.100.20
WireGuard 10.44.0.1 10.44.0.2
LAN 192.168.10.0/24 192.168.20.0/24
WG Gateway LAN 192.168.10.254 192.168.20.254
WireGuard port 51820/UDP 51820/UDP

Regula numărul 1: LAN-urile nu trebuie să se suprapună

Una dintre cele mai importante condiții pentru un VPN site-to-site simplu este ca cele două rețele să folosească subnete diferite.

Această configurație este corectă:

Site A: 192.168.10.0/24
Site B: 192.168.20.0/24

Aceasta va crea însă probleme:

Site A: 192.168.1.0/24
Site B: 192.168.1.0/24

Dacă ambele locații folosesc aceeași rețea, hosturile vor considera adresele remote ca fiind locale și routing-ul normal nu mai poate determina către ce site trebuie trimis traficul.

Planificarea adreselor IP este mult mai simplă decât încercarea de a repara ulterior două LAN-uri suprapuse.

Pregătirea ambelor gateway-uri

WireGuard trebuie instalat pe ambele gateway-uri.

Ubuntu și Debian:

sudo apt update
sudo apt install wireguard

AlmaLinux și Rocky Linux:

sudo dnf install wireguard-tools

Verificare:

wg --version

Generarea cheilor pentru Site A

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

umask 077

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

Cheia publică:

sudo cat /etc/wireguard/public.key

Generarea cheilor pentru Site B

Executăm aceeași operație pe gateway-ul Site B:

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

umask 077

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

Fiecare site trebuie să primească doar cheia publică a celuilalt site.

Cheile private nu trebuie transferate între servere.

Configurarea WireGuard pe Site A

Creăm:

/etc/wireguard/wg0.conf

Configurația:

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

[Peer]
PublicKey = <SITE_B_PUBLIC_KEY>
Endpoint = 198.51.100.20:51820
AllowedIPs = 10.44.0.2/32, 192.168.20.0/24

Protejăm fișierul:

sudo chmod 600 /etc/wireguard/wg0.conf

Configurarea WireGuard pe Site B

[Interface]
Address = 10.44.0.2/24
ListenPort = 51820
PrivateKey = <SITE_B_PRIVATE_KEY>

[Peer]
PublicKey = <SITE_A_PUBLIC_KEY>
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.44.0.1/32, 192.168.10.0/24
sudo chmod 600 /etc/wireguard/wg0.conf

Înțelegerea AllowedIPs în site-to-site

Pe Site A avem:

AllowedIPs = 10.44.0.2/32, 192.168.20.0/24

Asta spune gateway-ului Site A că:

  • 10.44.0.2 aparține peer-ului Site B;
  • întreg subnetul 192.168.20.0/24 trebuie trimis prin peer-ul Site B.

Pe Site B facem operația simetrică:

AllowedIPs = 10.44.0.1/32, 192.168.10.0/24

Cu wg-quick, aceste rețele vor genera și rutele corespunzătoare în tabela de routing a sistemului.

Activarea IP forwarding pe ambele gateway-uri

Până acum gateway-urile pot comunica prin WireGuard, dar avem nevoie ca Linux să transfere pachetele între interfața LAN și wg0.

Pe ambele servere:

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

sudo sysctl --system

Verificare:

sysctl net.ipv4.ip_forward

Trebuie să vedem:

net.ipv4.ip_forward = 1

Pornirea WireGuard

Pe ambele gateway-uri:

sudo systemctl enable --now wg-quick@wg0

Verificare:

systemctl status wg-quick@wg0
sudo wg show

Primul test: tunnel-ul WireGuard

De pe Site A:

ping 10.44.0.2

De pe Site B:

ping 10.44.0.1

Dacă aceste teste nu funcționează, nu are rost să depanăm încă LAN-urile.

Verificăm întâi:

sudo wg show

Trebuie să avem un latest handshake recent și trafic TX/RX.

Verificarea rutelor generate

Pe Site A:

ip route get 192.168.20.50

Traficul trebuie să fie direcționat către wg0.

Pe Site B:

ip route get 192.168.10.50

Cea mai importantă parte: rutele din LAN

Acesta este punctul unde multe configurații site-to-site aparent corecte eșuează.

Să presupunem că un PC din Site A:

192.168.10.50

vrea să contacteze:

192.168.20.50

PC-ul trebuie să știe că rețeaua 192.168.20.0/24 se găsește prin gateway-ul WireGuard Site A.

Dacă serverul WireGuard este gateway-ul implicit al LAN-ului

Nu este necesară o rută suplimentară. Traficul ajunge deja la gateway-ul WireGuard.

Dacă serverul WireGuard NU este gateway-ul implicit

Trebuie să adăugăm o rută statică pe routerul LAN.

Pe routerul Site A:

Destination: 192.168.20.0/24
Next hop:    192.168.10.254

Pe routerul Site B:

Destination: 192.168.10.0/24
Next hop:    192.168.20.254

Fără aceste rute, request-ul poate trece prin VPN, dar răspunsul va fi trimis către gateway-ul implicit greșit.

De ce nu folosim NAT între Site A și Site B?

Multe exemple de pe Internet rezolvă orice problemă de routing printr-o regulă MASQUERADE.

Pentru un VPN site-to-site bine controlat, de obicei nu avem nevoie de NAT între LAN-uri.

Routing-ul normal are avantaje importante:

  • hostul remote vede IP-ul real al sursei;
  • logurile păstrează adresa reală;
  • firewall-urile pot aplica politici pe subnetul remote;
  • conectivitatea poate fi bidirecțională;
  • topologia este mai ușor de înțeles și depanat.

NAT-ul are propriile utilizări, dar nu trebuie folosit pentru a ascunde o problemă de routing.

Firewall-ul trebuie să permită forwarding

IP forwarding activ în kernel nu garantează că firewall-ul permite traficul.

Trebuie să permitem traficul:

LAN A -> wg0 -> LAN B

și

LAN B -> wg0 -> LAN A

Exemplu cu UFW

Să presupunem că interfața LAN pe Site A este ens18.

Permitem traficul din LAN A către LAN B:

sudo ufw route allow \
  in on ens18 \
  out on wg0 \
  from 192.168.10.0/24 \
  to 192.168.20.0/24

Permitem răspunsurile și traficul inițiat din Site B:

sudo ufw route allow \
  in on wg0 \
  out on ens18 \
  from 192.168.20.0/24 \
  to 192.168.10.0/24

Pe Site B facem regulile simetrice pentru interfața LAN locală.

Înlocuiește ens18 cu numele real al interfeței tale:

ip -br link

Firewalld pe AlmaLinux și Rocky Linux

În ecosistemul RHEL este important să verifici zonele și politicile existente înainte să modifici firewall-ul.

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-all

Portul WireGuard trebuie permis:

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

Pentru forwarding între zone recomand să definești explicit politica în funcție de zonele în care se află interfața LAN și wg0, în loc să activezi generic masquerading.

Nu amesteca UFW, firewalld și reguli nftables manuale pe același server fără o strategie clară.

Testează întâi gateway-to-gateway

Ordinea testelor contează.

Pasul 1:

Site A -> 10.44.0.2

Pasul 2:

Site A gateway -> 192.168.20.254

Pasul 3:

Site A gateway -> 192.168.20.50

Pasul 4:

192.168.10.50 -> 192.168.20.50

Fiecare etapă verifică un nivel suplimentar al configurației.

Troubleshooting cu tcpdump

Când routing-ul pare corect, dar traficul nu ajunge, tcpdump este extrem de util.

Pe Site A:

sudo tcpdump -ni wg0 host 192.168.20.50

Pe interfața LAN:

sudo tcpdump -ni ens18 host 192.168.20.50

Dacă pachetele apar pe LAN, dar nu pe wg0, verificăm routing-ul sau firewall-ul Site A.

Dacă apar pe wg0 la Site A, dar nu apar pe wg0 la Site B, investigăm tunnel-ul.

Dacă apar pe wg0 la Site B, dar nu ies pe LAN, verificăm forwarding-ul și firewall-ul Site B.

wg show este primul instrument WireGuard

sudo wg show

Verificăm:

  • latest handshake;
  • endpoint-ul remote;
  • AllowedIPs;
  • traficul received/sent.

Dacă nu există handshake, problema nu este încă la rutarea dintre LAN-uri.

PersistentKeepalive și NAT

Dacă unul dintre site-uri este în spatele NAT-ului, configurația se schimbă puțin.

Să presupunem că Site B nu are IP public direct.

Pe Site B putem păstra:

[Peer]
PublicKey = <SITE_A_PUBLIC_KEY>
Endpoint = vpn-site-a.example.ro:51820
AllowedIPs = 10.44.0.1/32, 192.168.10.0/24
PersistentKeepalive = 25

Site B inițiază astfel conexiunea și păstrează maparea NAT activă.

Pe Site A, pentru peer-ul B, Endpoint poate fi omis dacă adresa lui se poate schimba. WireGuard poate învăța endpoint-ul din traficul autentificat primit.

Dacă ambele site-uri au IP public static

Configurația este mai simplă. Putem specifica endpoint-ul pe ambele gateway-uri și de regulă nu avem nevoie de PersistentKeepalive.

Firewall-urile hosturilor din LAN

Poți avea un tunnel WireGuard perfect și routing corect, dar un server din Site B să refuze conexiunile din subnetul Site A.

De exemplu, firewall-ul unui host din Site B trebuie să permită, unde este necesar:

source 192.168.10.0/24

pentru serviciile care trebuie accesate din Site A.

Acesta este unul dintre avantajele lipsei NAT-ului: serverul remote vede IP-ul real al clientului.

Verificarea completă a rutelor

Pe Site A:

ip route
ip route get 192.168.20.50

Pe Site B:

ip route
ip route get 192.168.10.50

Pe un client din LAN A, verifică și ruta către LAN B.

Pe Linux:

ip route get 192.168.20.50

Traficul trebuie să ajungă la routerul care cunoaște ruta către gateway-ul WireGuard.

Ce se întâmplă cu DNS?

WireGuard rezolvă conectivitatea IP. Nu configurează automat rezoluția numelor dintre cele două site-uri.

Dacă în Site A avem:

db01.site-b.internal -> 192.168.20.50

clienții Site A trebuie să folosească un DNS care cunoaște această zonă sau să existe forwarding DNS între infrastructurile celor două locații.

Testează întotdeauna mai întâi conectivitatea folosind IP-uri. Abia după aceea investighează DNS-ul.

Atenție la rp_filter

Linux poate utiliza Reverse Path Filtering pentru a verifica dacă sursa unui pachet pare să fie accesibilă prin interfața pe care a fost primit.

În configurațiile simple site-to-site nu ar trebui să fie nevoie să modifici această setare. În topologii cu routing asimetric, policy routing sau mai multe uplink-uri poate însă deveni relevantă.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.default.rp_filter

Nu dezactiva global rp_filter doar pentru că ai găsit această recomandare într-un forum. Verifică mai întâi dacă ai într-adevăr o problemă de routing asimetric.

Pornirea automată după reboot

Pe ambele gateway-uri:

sudo systemctl enable wg-quick@wg0

Verificare:

systemctl is-enabled wg-quick@wg0

Backup-ul configurațiilor

Pe ambele gateway-uri trebuie protejate fișierele din:

/etc/wireguard/

Acestea conțin chei private și nu trebuie păstrate într-un repository Git public.

Dacă faci backup configurației, copia trebuie criptată și protejată corespunzător.

Checklist WireGuard Site-to-Site

  1. LAN-urile Site A și Site B folosesc subnete diferite.
  2. Subnetul WireGuard nu se suprapune cu LAN-urile.
  3. Fiecare gateway are propria pereche de chei.
  4. Cheile private nu au fost transferate între site-uri.
  5. UDP 51820 este permis unde este necesar.
  6. Site A are în AllowedIPs subnetul Site B.
  7. Site B are în AllowedIPs subnetul Site A.
  8. net.ipv4.ip_forward=1 pe ambele gateway-uri.
  9. Firewall-ul permite forwarding LAN ↔ WireGuard.
  10. Nu există NAT inutil între cele două LAN-uri.
  11. Routerul Site A are rută către LAN B.
  12. Routerul Site B are rută către LAN A.
  13. Host firewall-urile permit subnetul remote unde este necesar.
  14. wg show indică handshake recent.
  15. Rutele WireGuard sunt corecte.
  16. Testele gateway-to-gateway funcționează înainte de testele LAN-to-LAN.
  17. DNS-ul este testat separat de conectivitatea IP.
  18. Configurațiile sunt incluse într-un backup securizat.

Secvența mea de troubleshooting

Dacă VPN-ul site-to-site nu funcționează, verific în ordinea următoare:

1. systemctl status wg-quick@wg0

2. sudo wg show

3. ping IP-ul WireGuard remote

4. ip route get REMOTE_LAN_IP

5. sysctl net.ipv4.ip_forward

6. verific firewall forwarding

7. tcpdump -ni wg0

8. tcpdump -ni LAN_INTERFACE

9. verific ruta statică pe routerul LAN

10. verific firewall-ul hostului remote

Metoda aceasta separă foarte clar problemele de tunnel de problemele de routing și firewall.

Configurația finală Site A

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

[Peer]
PublicKey = <SITE_B_PUBLIC_KEY>
Endpoint = 198.51.100.20:51820
AllowedIPs = 10.44.0.2/32, 192.168.20.0/24

Configurația finală Site B

[Interface]
Address = 10.44.0.2/24
ListenPort = 51820
PrivateKey = <SITE_B_PRIVATE_KEY>

[Peer]
PublicKey = <SITE_A_PUBLIC_KEY>
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.44.0.1/32, 192.168.10.0/24

Concluzie

Un VPN WireGuard site-to-site nu este doar un tunnel între două adrese wg0. Pentru conectivitate completă între două LAN-uri trebuie să funcționeze împreună patru elemente: WireGuard, routing-ul, IP forwarding-ul și firewall-ul.

WireGuard rezolvă criptarea și asocierea peer-ilor. AllowedIPs definește ce rețele se găsesc prin fiecare peer. Linux trebuie apoi să permită forwarding-ul, iar routerele LAN trebuie să știe cum ajung la subnetul remote.

Pentru o configurație site-to-site clasică, routing-ul fără NAT este de obicei soluția cea mai curată deoarece păstrează IP-urile reale și permite politici de securitate clare între rețele.

Dacă tunnel-ul are handshake, dar LAN-urile nu comunică, problema este aproape întotdeauna în routing, forwarding sau firewall — nu în criptografia WireGuard.

Acest articol continuă seria începută cu WireGuard: VPN simplu între două servere Linux și Instalare și configurare WireGuard Server pe Linux.

În următorul articol vom construi configurația WireGuard client-to-server pentru laptopuri, telefoane și stații de administrare și vom explica diferența dintre split tunnel și full tunnel.