Tunel divizat WireGuard: configurare fără rută implicită

Un tunel divizat este definit de ce lași afară, iar WireGuard ia această decizie într-un singur câmp. AllowedIPs de pe peer-ul clientului selectează simultan ce destinații trec prin tunel și filtrează ce adrese sursă interne sunt acceptate, iar wg-quick transformă aceeași listă în rute de gazdă. Dacă lista este greșită, tunelul fie înghite tot, fie nu transportă nimic.

Stabilește mai întâi lista de prefixe

Notează destinațiile care trebuie să folosească tunelul înainte de a atinge un fișier de configurare. Subrețele de birou, un interval de bază de date, o rețea de administrare: fiecare este un prefix cu un motiv. Tot ce nu este pe listă rămâne pe calea fizică, iar acesta este tot sensul proiectării.

Dacă lista conține 0.0.0.0/0 sau ::/0, ai construit un tunel complet și ar trebui să spui asta, pentru că modurile de eșec și așteptările DNS sunt diferite.

Ține lista suficient de scurtă încât un recenzent să o poată compara mai târziu cu tabela de rutare.

Configurația clientului: peer, AllowedIPs, DNS

Blocul de interfață al clientului conține propria adresă de tunel și cheia privată. Blocul de peer conține cheia publică a serverului, punctul final și prefixele din primul pas:

[Interface]
Address = 10.9.0.2/32
PrivateKey = <client-private-key>
DNS = 10.20.0.53

[Peer]
PublicKey = <server-public-key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16, 10.30.0.0/24
PersistentKeepalive = 25

AllowedIPs pe client este mulțimea destinațiilor la distanță, nu adresa proprie a clientului. Linia DNS are efect doar prin integrarea resolverului din wg-quick, așa că un host fără suport pentru resolvconf sau systemd-resolved o va ignora. PersistentKeepalive menține în viață o mapare NAT și este inutil pe o cale directă.

Comentează fiecare prefix cu serviciul pe care îl deservește, altfel următoarea modificare va fi o presupunere.

Configurația serverului: punctul de vedere opus

Pe server, intrarea de peer reprezintă clientul, deci AllowedIPs al acesteia este adresa de tunel a clientului, de obicei /32. Nu este subrețeaua biroului. Copierea listei clientului în intrarea serverului este cea mai frecventă greșeală a tunelului divizat și fie lărgește accesul, fie strică verificarea sursei interne la handshake.

Adresa de interfață proprie a serverului și rutele de care are nevoie spre birou sunt separate de orice intrare de peer.

Două fișiere, două puncte de vedere, un set de prefixe împărțit între ele.

Ridică-l și citește rutele

Pornește interfața cu managerul acceptat și apoi uită-te la ce a instalat, nu la ce intenționai. wg-quick derivă rute din AllowedIPs; dacă profilul setează Table = off, nu se instalează nimic și rutarea este responsabilitatea ta. Citește ruta fiecărui prefix și confirmă că indică interfața WireGuard. O listă de rute goală înseamnă de obicei că profilul aplicat nu este cel pe care l-ai editat.

Verifică și contoarele de handshake, pentru că un peer fără handshake are o problemă de cheie, punct final sau accesibilitate, nu de rutare.

Scrie comanda exactă pe care ai folosit-o, pentru că următoarea persoană o va rula sub presiune.

Verifică ambele părți, apoi notează revenirea

Testează o adresă privată, numele ei intern și o destinație care trebuie să rămână directă. Dacă adresa privată funcționează și destinația directă iese acum prin tunel, lista de prefixe este prea largă. Dacă numele eșuează în timp ce adresa funcționează, linia DNS nu a intrat în vigoare. Revenirea este o singură comandă și aparține aceleiași note.

După o reconectare, confirmă că rutele sunt încă acolo, pentru că un manager care reaplică profilul poate înlocui rutele manuale.

Păstrează un singur proprietar al configurației, pentru că doi manageri care produc aceeași interfață vor ajunge în cele din urmă să nu fie de acord. Manualul wg-quick documentează comportamentul rutelor și DNS pe care îl oferă.