O aplicație prin WireGuard: legarea nu este rutare

Setarea arată ca un comutator pentru fiecare aplicație, așa că oamenii leagă clientul de interfața WireGuard și se așteaptă ca doar acel client să folosească tunelul. Ce face de fapt legarea este să aleagă o adresă sursă. Apoi nucleul caută o rută către destinație, găsește ruta implicită obișnuită și trimite pachetul pe legătura fizică cu adresa tunelului atașată. Doar o rută aleasă pentru acea adresă sursă împlinește intenția.

Mecanismul are două jumătăți: un tabel de rutare pe care ar trebui să-l folosească doar traficul tunelului, și o regulă care trimite acolo sursa potrivită.

Legarea stabilește o adresă sursă și nimic mai mult

Linux alege o interfață de ieșire căutând destinația într-un tabel de rutare, după ce regulile de politică au avut ocazia să redirecționeze acea căutare. Regulile pot selecta după adresa sursă, o marcă de firewall, interfața de intrare, un UID sau chiar un port; fiecare este un alt mod de a spune acest trafic în loc de tot. Configurația clientului VPN alege tabelul care conține rutele tunelului; regula alege ce trafic are voie să îl consulte. Doar legarea nu oferă niciuna dintre ele.

De aceea eșecul pare atât de ciudat. Aplicația folosește fără îndoială adresa tunelului, tunelul este fără îndoială activ, iar traficul iese fără îndoială prin interfața greșită. Fiecare afirmație este adevărată, iar împreună descriu un sistem în care nimic nu a legat adresa de rută.

Dați tunelului propriul tabel

wg-quick instalează rutele acolo unde îi spune profilul. Adăugarea Table = 40 sub [Interface] le mută în tabelul 40 în loc de tabelul principal. Ridicați interfața și confirmați că au ajuns: ip -4 route ls table 40 ar trebui să arate rutele tunelului, iar ip -4 route get 10.66.127.142 arată cum rezolvă nucleul acum una dintre ele. Cu rutele în propriul tabel, tabelul principal continuă să funcționeze pentru tot restul.

Faceți același lucru pentru IPv6 în loc să potriviți un prefix larg. ip -6 rule add from fd00::2/128 lookup 40 fixează o adresă; fc00::/8 poate intra în conflict cu alte interfețe de pe gazdă și poate produce o regulă care se potrivește cu mai mult decât s-a intenționat.

Adăugați regula de sursă și urmăriți contoarele

Apoi conectați cele două jumătăți: ip -4 rule add from 10.66.127.142/32 lookup 40, cu aceeași adresă atașată interfeței WireGuard. Puneți ambele reguli în PostUp pentru ca o reconectare să le restaureze. Verificați cu o cerere reală, nu cu o setare: ip route get 1.1.1.1 from 10.66.127.142 ar trebui să numească dispozitivul tunelului, iar curl --interface wg0 ifconfig.me ar trebui să raporteze adresa tunelului în loc de cea de acasă.

Când tot nu funcționează, citiți ip -s rule. O regulă care există dar nu s-a potrivit niciodată arată contoare zero, iar asta distinge o regulă greșită de lipsa oricărei reguli. Acea singură comandă economisește multe presupuneri despre dacă aplicația și-a ignorat setarea de interfață.

Cazul invers: țineți SSH în afara tunelului

Problema opusă este la fel de frecventă: wg-quick deține ruta implicită și sesiunea SSH către server moare la mijloc. Regulile ei stau la un număr de prioritate mic, așa că o excepție trebuie evaluată înaintea lor. ip rule add dport 22 ipproto tcp table main priority 123 face asta pe un iproute2 recent; unde selectorul nu este disponibil, marcați fluxul în nftables și potriviți marca în schimb.

Verificați și calea de răspuns. O sesiune SSH care se stabilește și apoi tace are de obicei rutare asimetrică, cu o direcție ieșind prin tunel și cealaltă prin interfața fizică. ip route get pentru adresa serverului vă spune încotro ar merge răspunsul.

Notați numărul tabelului, regula de sursă și excepția în profilul însuși. Toate trei aparțin unui singur proiect și vor fi editate împreună.