Én app gennem WireGuard: binding er ikke routing

Indstillingen ligner en kontakt per applikation, så folk binder klienten til WireGuard-interfacet og forventer, at kun den klient bruger tunnelen. Hvad bindingen faktisk gør, er at vælge en kildeadresse. Derefter slår kernen en rute op til destinationen, finder den almindelige standardrute og sender pakken ud ad det fysiske link med tunneladressen påklistret. Kun en rute, der er valgt for netop den kildeadresse, opfylder hensigten.

Mekanismen har to halvdele: en routingtabel, som kun tunnelens trafik bør bruge, og en regel, der sender den matchende kilde derhen.

Binding sætter en kildeadresse og intet andet

Linux vælger et udgående interface ved at slå destinationen op i en routingtabel, efter at politikregler har haft mulighed for at omdirigere det opslag. Regler kan vælge ud fra kildeadressen, et firewall-mærke, det indgående interface, en UID eller endda en port; hver af dem er en anden måde at sige denne trafik i stedet for det hele. VPN-klientens konfiguration vælger den tabel, der indeholder tunnelruterne; reglen vælger, hvilken trafik der må konsultere den. Binding alene leverer ingen af delene.

Derfor ser fejlen så mærkelig ud. Applikationen bruger afgjort tunneladressen, tunnelen er afgjort oppe, og trafikken forlader afgjort det forkerte interface. Hvert udsagn er sandt, og sammen beskriver de et system, hvor intet bandt adressen til ruten.

Giv tunnelen sin egen tabel

wg-quick installerer ruter, hvor profilen end siger det. Tilføjer du Table = 40 under [Interface], flyttes de til tabel 40 i stedet for hovedtabellen. Tag interfacet op og bekræft, at de nåede frem: ip -4 route ls table 40 bør vise tunnelens ruter, og ip -4 route get 10.66.127.142 viser, hvordan kernen i øjeblikket opløser en af dem. Med ruterne i deres egen tabel bliver hovedtabellen ved med at fungere for alt andet.

Gør det samme for IPv6 i stedet for at matche et bredt præfiks. ip -6 rule add from fd00::2/128 lookup 40 fastlåser én adresse; fc00::/8 kan kollidere med andre interfaces på værten og give en regel, der matcher mere end tilsigtet.

Tilføj kildereglen, og hold øje med tællerne

Forbind så de to halvdele: ip -4 rule add from 10.66.127.142/32 lookup 40, med den samme adresse knyttet til WireGuard-interfacet. Læg begge regler i PostUp, så en genopkobling genskaber dem. Verificér med en rigtig anmodning i stedet for en indstilling: ip route get 1.1.1.1 from 10.66.127.142 bør navngive tunneleenheden, og curl --interface wg0 ifconfig.me bør rapportere tunnelens adresse i stedet for hjemmeadressen.

Når det stadig fejler, så læs ip -s rule. En regel, der findes, men aldrig har matchet, viser nul tællere, og det skelner en forkert regel fra ingen regel. Den ene kommando sparer en masse gætteri om, hvorvidt applikationen ignorerede sin interface-indstilling.

Det omvendte tilfælde: hold SSH ude af tunnelen

Det modsatte problem er lige så almindeligt: wg-quick ejer standardruten, og SSH-sessionen til serveren dør midt i sessionen. Dets regler ligger på et lavt prioritetsnummer, så en undtagelse skal evalueres før dem. ip rule add dport 22 ipproto tcp table main priority 123 gør det på en nyere iproute2; hvor vælgeren ikke findes, markér flowet i nftables, og match mærket i stedet.

Kontrollér også svarvejen. En SSH-session, der etableres og derefter går i stå, har som regel asymmetrisk routing, hvor den ene retning går ud gennem tunnelen og den anden gennem det fysiske interface. ip route get for serveradressen fortæller, hvilken vej svaret ville gå.

Notér tabelnummeret, kildereglen og undtagelsen i selve profilen. Alle tre hører til ét design og vil blive redigeret sammen.