Én app gjennom WireGuard: binding er ikke ruting

Innstillingen ser ut som en bryter per applikasjon, så folk binder klienten til WireGuard-grensesnittet og forventer at bare den klienten bruker tunnelen. Det bindingen faktisk gjør, er å velge en kildeadresse. Deretter slår kjernen opp en rute til målet, finner den vanlige standardruten og sender pakken ut over den fysiske lenken med tunneladressen festet. Bare en rute som er valgt for nettopp den kildeadressen, oppfyller hensikten.

Mekanismen har to halvdeler: en rutetabell som bare tunnelens trafikk skal bruke, og en regel som sender den matchende kilden dit.

Binding setter en kildeadresse, ikke noe mer

Linux velger et utgående grensesnitt ved å slå opp målet i en rutetabell, etter at policyregler har hatt mulighet til å omdirigere oppslaget. Regler kan velge på kildeadressen, et brannmurmerke, det innkommende grensesnittet, en UID eller til og med en port; hver av dem er en annen måte å si denne trafikken i stedet for alt. VPN-klientens konfigurasjon velger tabellen som holder tunnelrutene; regelen velger hvilken trafikk som får konsultere den. Binding alene gir ingen av delene.

Derfor ser feilen så merkelig ut. Applikasjonen bruker avgjort tunneladressen, tunnelen er avgjort oppe, og trafikken forlater avgjort feil grensesnitt. Hvert utsagn er sant, og sammen beskriver de et system der ingenting bandt adressen til ruten.

Gi tunnelen sin egen tabell

wg-quick installerer ruter der profilen sier. Legger du til Table = 40 under [Interface], flyttes de til tabell 40 i stedet for hovedtabellen. Ta grensesnittet opp og bekreft at de kom fram: ip -4 route ls table 40 skal vise tunnelens ruter, og ip -4 route get 10.66.127.142 viser hvordan kjernen for øyeblikket løser opp en av dem. Med rutene i sin egen tabell fortsetter hovedtabellen å virke for alt annet.

Gjør det samme for IPv6 i stedet for å matche et bredt prefiks. ip -6 rule add from fd00::2/128 lookup 40 fester én adresse; fc00::/8 kan kollidere med andre grensesnitt på verten og gi en regel som matcher mer enn tiltenkt.

Legg til kilderegelen og følg med på tellerne

Koble så sammen halvdelene: ip -4 rule add from 10.66.127.142/32 lookup 40, med den samme adressen festet til WireGuard-grensesnittet. Legg begge reglene i PostUp slik at en gjentilkobling gjenoppretter dem. Verifiser med en ekte forespørsel i stedet for en innstilling: ip route get 1.1.1.1 from 10.66.127.142 skal navngi tunnelenheten, og curl --interface wg0 ifconfig.me skal rapportere tunnelens adresse i stedet for hjemmeadressen.

Når det fortsatt feiler, les ip -s rule. En regel som finnes, men aldri har matchet, viser null tellere, og det skiller en feil regel fra ingen regel i det hele tatt. Den ene kommandoen sparer mye gjetting på om applikasjonen ignorerte grensesnittinnstillingen sin.

Det motsatte tilfellet: hold SSH utenfor tunnelen

Det motsatte problemet er like vanlig: wg-quick eier standardruten, og SSH-økten til serveren dør midt i økten. Reglene dens ligger på et lavt prioritetsnummer, så et unntak må vurderes tidligere enn dem. ip rule add dport 22 ipproto tcp table main priority 123 gjør det på en nyere iproute2; der velgeren ikke er tilgjengelig, merk flyten i nftables og match merket i stedet.

Kontroller også svarveien. En SSH-økt som etableres og deretter blir stille, har vanligvis asymmetrisk ruting, med én retning ut gjennom tunnelen og den andre gjennom det fysiske grensesnittet. ip route get for serveradressen forteller hvilken vei svaret ville gå.

Noter tabellnummeret, kilderegelen og unntaket i selve profilen. Alle tre hører til ett design og vil bli redigert sammen.