En app genom WireGuard: bindning är inte routning

Inställningen ser ut som en brytare per program, så folk binder klienten till WireGuard-gränssnittet och förväntar sig att bara den klienten använder tunneln. Vad bindningen faktiskt gör är att välja en källadress. Sedan slår kärnan upp en rutt till destinationen, hittar den vanliga standardrutten och skickar paketet ut genom den fysiska länken med tunneladressen påsatt. Bara en rutt som valts för just den källadressen uppfyller avsikten.

Mekanismen har två halvor: en routingtabell som bara tunnelns trafik bör använda, och en regel som skickar den matchande källan dit.

Bindning sätter en källadress och inget mer

Linux väljer ett utgående gränssnitt genom att slå upp destinationen i en routingtabell, efter att policyregler har fått en chans att omdirigera uppslaget. Regler kan välja på källadressen, en brandväggsmarkering, det inkommande gränssnittet, en UID eller till och med en port; var och en är ett annat sätt att säga den här trafiken i stället för allt. VPN-klientens konfiguration väljer tabellen som innehåller tunnelrutterna; regeln väljer vilken trafik som får konsultera den. Enbart bindning ger inget av dem.

Därför ser felet så märkligt ut. Programmet använder avgjort tunneladressen, tunneln är avgjort uppe, och trafiken lämnar avgjort fel gränssnitt. Varje påstående är sant, och tillsammans beskriver de ett system där ingenting band adressen till rutten.

Ge tunneln en egen tabell

wg-quick installerar rutter där profilen säger. Lägger du till Table = 40 under [Interface] flyttas de till tabell 40 i stället för huvudtabellen. Ta upp gränssnittet och bekräfta att de kom fram: ip -4 route ls table 40 bör visa tunnelns rutter, och ip -4 route get 10.66.127.142 visar hur kärnan just nu löser en av dem. Med rutterna i sin egen tabell fortsätter huvudtabellen att fungera för allt annat.

Gör samma sak för IPv6 i stället för att matcha ett brett prefix. ip -6 rule add from fd00::2/128 lookup 40 fäster en adress; fc00::/8 kan kollidera med andra gränssnitt på värden och ge en regel som matchar mer än avsett.

Lägg till källregeln och titta på räknarna

Koppla sedan ihop halvorna: ip -4 rule add from 10.66.127.142/32 lookup 40, med samma adress fäst vid WireGuard-gränssnittet. Lägg båda reglerna i PostUp så att en återanslutning återställer dem. Verifiera med en riktig begäran i stället för en inställning: ip route get 1.1.1.1 from 10.66.127.142 bör namnge tunnelenheten, och curl --interface wg0 ifconfig.me bör rapportera tunnelns adress i stället för hemadressen.

När det fortfarande misslyckas, läs ip -s rule. En regel som finns men aldrig har matchat visar nollräknare, och det skiljer en felaktig regel från ingen regel alls. Det enda kommandot sparar mycket gissande om programmet ignorerade sin gränssnittsinställning.

Det omvända fallet: håll SSH utanför tunneln

Det motsatta problemet är lika vanligt: wg-quick äger standardrutten och SSH-sessionen till servern dör mitt i. Dess regler ligger på ett lågt prioritetsnummer, så ett undantag måste utvärderas före dem. ip rule add dport 22 ipproto tcp table main priority 123 gör det på en nyare iproute2; där väljaren inte är tillgänglig, markera flödet i nftables och matcha markeringen i stället.

Kontrollera också svarsvägen. En SSH-session som etableras och sedan tystnar har oftast asymmetrisk routning, där en riktning går ut genom tunneln och den andra genom det fysiska gränssnittet. ip route get för serveradressen talar om åt vilket håll svaret skulle gå.

Notera tabellnumret, källregeln och undantaget i själva profilen. Alla tre hör till en enda design och kommer att redigeras tillsammans.