Éin app gjennom WireGuard: binding er ikkje ruting

Innstillinga ser ut som ein brytar per applikasjon, så folk bind klienten til WireGuard-grensesnittet og ventar at berre den klienten brukar tunnelen. Det bindinga faktisk gjer, er å velje ei kjeldeadresse. Deretter slår kjernen opp ei rute til målet, finn den vanlege standardruta og sender pakken ut over den fysiske lenka med tunneladressa fest. Berre ei rute som er vald for nettopp den kjeldeadressa, oppfyller hensikta.

Mekanismen har to halvdelar: ein rutetabell som berre trafikken til tunnelen skal bruke, og ein regel som sender den samsvarande kjelda dit.

Binding set ei kjeldeadresse, ikkje noko meir

Linux vel eit utgåande grensesnitt ved å slå opp målet i ein rutetabell, etter at policyreglar har hatt høve til å omdirigere oppslaget. Reglar kan velje på kjeldeadressa, eit brannmurmerke, det innkomande grensesnittet, ein UID eller til og med ein port; kvar av dei er ein annan måte å seie denne trafikken i staden for alt. Konfigurasjonen til VPN-klienten vel tabellen som held tunnelrutene; regelen vel kva trafikk som får konsultere han. Binding åleine gir ingen av delane.

Difor ser feilen så merkeleg ut. Applikasjonen brukar avgjort tunneladressa, tunnelen er avgjort oppe, og trafikken forlèt avgjort feil grensesnitt. Kvart utsegn er sant, og saman skildrar dei eit system der ingenting batt adressa til ruta.

Gi tunnelen sin eigen tabell

wg-quick installerer ruter der profilen seier det. Legg du til Table = 40 under [Interface], flyttar dei til tabell 40 i staden for hovudtabellen. Ta grensesnittet opp og stadfest at dei kom fram: ip -4 route ls table 40 skal vise rutene til tunnelen, og ip -4 route get 10.66.127.142 viser korleis kjernen for tida løyser opp ei av dei. Med rutene i sin eigen tabell held hovudtabellen fram med å verke for alt anna.

Gjer det same for IPv6 i staden for å matche eit breitt prefiks. ip -6 rule add from fd00::2/128 lookup 40 festar éi adresse; fc00::/8 kan kollidere med andre grensesnitt på verten og gi ein regel som matchar meir enn tenkt.

Legg til kjelderegelen og følg med på teljarane

Kopla så saman halvdelane: ip -4 rule add from 10.66.127.142/32 lookup 40, med den same adressa fest til WireGuard-grensesnittet. Legg begge reglane i PostUp slik at ein gjentilkopling gjenopprettar dei. Stadfest med ein ekte førespurnad i staden for ei innstilling: ip route get 1.1.1.1 from 10.66.127.142 skal namngi tunneleininga, og curl --interface wg0 ifconfig.me skal rapportere adressa til tunnelen i staden for heimeadressa.

Når det framleis feilar, les ip -s rule. Ein regel som finst, men aldri har matcha, viser null teljarar, og det skil ein feil regel frå ingen regel i det heile. Den eine kommandoen sparar mykje gjetting på om applikasjonen ignorerte grensesnittinnstillinga si.

Det motsette tilfellet: hald SSH utanfor tunnelen

Det motsette problemet er like vanleg: wg-quick eig standardruta, og SSH-økta til tenaren døyr midt i økta. Reglane hans ligg på eit lågt prioritetsnummer, så eit unntak må vurderast tidlegare enn dei. ip rule add dport 22 ipproto tcp table main priority 123 gjer det på ein nyare iproute2; der veljaren ikkje er tilgjengeleg, merk flyten i nftables og match merket i staden.

Kontroller også svarvegen. Ei SSH-økt som blir etablert og deretter blir stille, har vanlegvis asymmetrisk ruting, med éi retning ut gjennom tunnelen og den andre gjennom det fysiske grensesnittet. ip route get for tenaradressa fortel kva veg svaret ville gå.

Noter tabellnummeret, kjelderegelen og unntaket i sjølve profilen. Alle tre høyrer til eitt design og vil bli redigerte saman.