Një aplikacion përmes WireGuard: lidhja nuk është rrugëzim

Cilësimi duket si një çelës për çdo aplikacion, prandaj njerëzit e lidhin klientin me ndërfaqen WireGuard dhe presin që vetëm ai klient të përdorë tunelin. Ajo që bën në të vërtetë lidhja është të zgjedhë një adresë burimore. Më pas kerneli kërkon një rrugë për destinacionin, gjen rrugën normale të paracaktuar dhe e dërgon paketën përmes lidhjes fizike me adresën e tunelit të bashkangjitur. Vetëm një rrugë e zgjedhur për atë adresë burimore e plotëson qëllimin.

Mekanizmi ka dy gjysma: një tabelë rrugëzimi që duhet ta përdorë vetëm trafiku i tunelit, dhe një rregull që dërgon atje burimin përkatës.

Lidhja cakton një adresë burimore dhe asgjë më shumë

Linux zgjedh një ndërfaqe dalëse duke kërkuar destinacionin në një tabelë rrugëzimi, pasi rregullat e politikave kanë pasur mundësinë ta ridrejtojnë atë kërkim. Rregullat mund të zgjedhin sipas adresës burimore, një shenje muri zjarri, ndërfaqes hyrëse, një UID ose edhe një porti; secila është një mënyrë tjetër për të thënë ky trafik në vend të gjithëve. Konfigurimi i klientit VPN zgjedh tabelën që mban rrugët e tunelit; rregulli zgjedh cili trafik lejohet ta konsultojë atë. Vetëm lidhja nuk ofron asnjërën.

Prandaj ky dështim duket kaq i çuditshëm. Aplikacioni pa dyshim përdor adresën e tunelit, tuneli pa dyshim është lart, dhe trafiku pa dyshim po del përmes ndërfaqes së gabuar. Çdo pohim është i vërtetë, dhe bashkë përshkruajnë një sistem ku asgjë nuk e lidhi adresën me rrugën.

Jepini tunelit tabelën e vet

wg-quick instalon rrugët atje ku i thotë profili. Shtimi i Table = 40 nën [Interface] i zhvendos ato në tabelën 40 në vend të tabelës kryesore. Ngrini ndërfaqen dhe konfirmoni që arritën: ip -4 route ls table 40 duhet të tregojë rrugët e tunelit, dhe ip -4 route get 10.66.127.142 tregon si kerneli zgjidh tani njërën prej tyre. Kur rrugët janë në tabelën e tyre, tabela kryesore vazhdon të punojë për gjithçka tjetër.

Bëni të njëjtën gjë për IPv6 në vend që të përputhni një prefiks të gjerë. ip -6 rule add from fd00::2/128 lookup 40 fikson një adresë; fc00::/8 mund të përplaset me ndërfaqe të tjera në host dhe të prodhojë një rregull që përputhet me më shumë sesa synohej.

Shtoni rregullin e burimit dhe shikoni numëruesit

Pastaj lidhni gjysmat: ip -4 rule add from 10.66.127.142/32 lookup 40, me të njëjtën adresë të bashkangjitur ndërfaqes WireGuard. Vendosni të dy rregullat në PostUp që një rilidhje t'i rivendosë ato. Verifikoni me një kërkesë të vërtetë dhe jo me një cilësim: ip route get 1.1.1.1 from 10.66.127.142 duhet të përmendë pajisjen e tunelit, dhe curl --interface wg0 ifconfig.me duhet të raportojë adresën e tunelit në vend të asaj të shtëpisë.

Kur ende dështon, lexoni ip -s rule. Një rregull që ekziston por nuk është përputhur kurrë tregon numërues zero, dhe kjo e dallon një rregull të gabuar nga mungesa e rregullit. Ai komandë i vetëm kursen shumë hamendësime rreth asaj nëse aplikacioni injoroi cilësimin e ndërfaqes.

Rasti i kundërt: mbajeni SSH jashtë tunelit

Problemi i kundërt është po aq i zakonshëm: wg-quick zotëron rrugën e paracaktuar dhe sesioni SSH drejt serverit vdes në mes. Rregullat e tij qëndrojnë në një numër prioriteti të ulët, prandaj një përjashtim duhet vlerësuar përpara tyre. ip rule add dport 22 ipproto tcp table main priority 123 e bën këtë në një iproute2 të ri; aty ku përzgjedhësi nuk është i disponueshëm, shënoni rrjedhën në nftables dhe përputhni shenjën.

Kontrolloni edhe rrugën e përgjigjes. Një sesion SSH që vendoset dhe pastaj hesht zakonisht ka rrugëzim asimetrik: një drejtim del përmes tunelit dhe tjetri përmes ndërfaqes fizike. ip route get për adresën e serverit ju tregon nga cila anë do të shkonte përgjigjja.

Shënoni numrin e tabelës, rregullin e burimit dhe përjashtimin në vetë profilin. Të treja i përkasin një dizajni dhe do të redaktohen së bashku.