Prefixul de gazdă WireGuard: de ce funcționează o adresă și restul nu

Tunelul este activ, handshake-ul are loc la fiecare două minute și exact o adresă de pe cealaltă parte răspunde. Ping-urile către adresa de tunel a peer-ului funcționează; nimic din spatele ei nu funcționează. Cineva citește configurația interfeței, vede un prefix de gazdă și concluzionează că masca este greșită. Lărgirea ei la un /24 repară ping-ul o vreme și apoi strică altceva. Prefixul nu a fost niciodată problema, iar ruta care lipsea nu este cea pe care o controlează masca.

Ce creează de fapt prefixul interfeței

Pe Linux, atribuirea unei adrese unei interfețe creează o rută conectată pentru acel prefix. Dacă atribui un prefix de gazdă, ruta conectată acoperă o singură adresă. Dacă atribui un /24, acoperă 256, iar fiecare dintre ele este tratată acum ca accesibilă pe acel link.

ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1

Un prefix de gazdă este o alegere complet normală pentru un tunel punct-la-punct, pentru că există exact un peer la celălalt capăt. A treia comandă este cea care răspunde la întrebarea utilizatorului: spune ce interfață ar folosi nucleul pentru acea destinație și nu va arăta nimic util dacă nicio rută nu se potrivește.

Aceasta este toată explicația simptomului. O adresă răspunde pentru că există o rută conectată pentru ea, sau pentru că lista permisă a peer-ului o include din întâmplare. Pentru orice altceva nu există rută și este aruncat înainte ca WireGuard să fie implicat. Tunelul este sănătos tot timpul, motiv pentru care contorul de handshake continuă să pară liniștitor.

AllowedIPs sunt două reguli sub un singur nume

Lista permisă pe peer din WireGuard face două treburi deodată, iar sintaxa de configurare le face să pară una singură. La intrare, autorizează ce adrese sursă poate prezenta un peer. La ieșire, selectează către ce peer se trimite un pachet, găsind potrivirea cea mai specifică.

Niciuna dintre cele două treburi nu este rutare. Nucleul trebuie încă să decidă că un pachet aparține interfeței tunelului înainte ca WireGuard să se uite la el, iar această decizie vine din tabela de rutare. O intrare de peer cu o listă permisă largă nu instalează singură o rută.

De aceea o configurație poate părea completă și se poate comporta asimetric. Clientul trimite spre celălalt capăt pentru că există o rută, iar răspunsurile nu ajung niciodată pentru că lista permisă a celuilalt capăt nu autorizează sursa clientului, sau pentru că celălalt capăt nu are cale de întoarcere. Ambele direcții sunt decizii separate cu moduri de eșec separate. Să notezi pe care o testezi este jumătate din diagnostic.

De unde vine ruta

Dacă folosești wg-quick, rutele sunt generate pentru tine din lista permisă a fiecărui peer, dacă nu cumva ai setat Table = off și ai preluat tu controlul. Acesta este comportamentul documentat de unealtă și este motivul pentru care o configurație fără directive explicite de rutare funcționează totuși.

sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0

Compară lista permisă cu rutele care există de fapt. Un peer care permite un întreg subnet dar a produs doar o rută de gazdă înseamnă că ajutorul nu a rulat niciodată, sau că gestionezi interfața direct cu wg și ip, iar în acest caz nimic nu generează rute pentru tine.

Când o gestionezi manual, ruta este o singură linie și forma ei este explicită: destinația prin interfață, fără gateway pentru că legătura este punct-la-punct. Adăugarea ei nu este o soluție de compromis pentru un prefix prost; este jumătatea lipsă a unui proiect care a ales să se ocupe singur de rutare.

Lărgirea prefixului nu adaugă intrarea peer-ului

Corectura tentantă este să schimbi adresa într-un /24 astfel încât ruta conectată să acopere LAN-ul serverului. Pare să funcționeze, iar motivul pentru care pare să funcționeze este că ruta conectată se potrivește acum, nu că WireGuard a învățat ceva nou.

Ceea ce ai făcut de asemenea este să revendici întregul interval ca fiind direct accesibil pe acel link, inclusiv adrese care aparțin altor peers sau unui LAN care se află de fapt în spatele serverului. Traficul către acele adrese intră acum în tunel, iar dacă iese pe partea cealaltă depinde de rutarea și listele permise ale serverului însuși.

Partea criptografică nu este afectată în niciun caz. WireGuard are în continuare nevoie de o intrare în lista permisă care acoperă destinația pentru a alege un peer, iar celălalt capăt are în continuare nevoie de o intrare care acoperă sursa ta pentru a o accepta. Un prefix de interfață mai larg nu poate furniza niciuna dintre ele.

Confirmă ambele direcții înainte de a schimba ceva

Lucrează cele două capete separat și notează ce spune fiecare. Pe client, ruta și intrarea peer-ului; pe server, imaginea în oglindă plus propria cale de întoarcere:

ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10

Captura este cea care lămurește disputele despre direcție. Dacă pachetele de ieșire apar pe interfața tunelului și serverul nu înregistrează nimic, capătul îndepărtat le respinge, de obicei pentru că sursa ta este în afara listei sale permise. Dacă nu apare nimic deloc, ruta lipsește sau indică în altă parte.

Apoi repară capătul cel mai îngust. O intrare în lista permisă pe partea serverului pentru adresa clientului tău și o intrare pe partea clientului pentru subnetul de destinație este forma normală, iar aceasta lasă prefixul interfeței în pace. Lărgește prefixul doar dacă planul de adresare vrea cu adevărat un subnet partajat pe acel link, și fă-o ca schimbare de plan, nu ca pas de depanare.