Jedna aplikacija kroz WireGuard: vezanje nije usmjeravanje

Postavka izgleda kao prekidač po aplikaciji, pa ljudi vežu klijent za WireGuard sučelje i očekuju da samo taj klijent koristi tunel. Vezanje zapravo bira izvornu adresu. Jezgra zatim traži rutu za odredište, pronalazi uobičajenu zadanu rutu i šalje paket kroz fizičku vezu s pridodanom adresom tunela. Samo ruta odabrana za tu izvornu adresu ispunjava namjeru.

Mehanizam ima dvije polovine: tablicu usmjeravanja koju bi trebao koristiti samo promet tunela, i pravilo koje odgovarajući izvor šalje tamo.

Vezanje postavlja izvornu adresu i ništa više

Linux bira izlazno sučelje tražeći odredište u tablici usmjeravanja, nakon što su pravila politike imala priliku preusmjeriti to traženje. Pravila mogu birati po izvornoj adresi, oznaci vatrozida, ulaznom sučelju, UID-u ili čak portu; svako je drugi način da se kaže ovaj promet umjesto sav. Konfiguracija VPN klijenta bira tablicu koja drži rute tunela; pravilo bira kojem je prometu dopušteno da je konzultira. Samo vezanje ne daje ni jedno ni drugo.

Zato kvar izgleda tako čudno. Aplikacija zasigurno koristi adresu tunela, tunel zasigurno radi, a promet zasigurno izlazi kroz pogrešno sučelje. Svaka tvrdnja je istinita, a zajedno opisuju sustav u kojem ništa nije povezalo adresu s rutom.

Dajte tunelu vlastitu tablicu

wg-quick instalira rute gdje mu profil kaže. Dodavanje Table = 40 pod [Interface] premješta ih u tablicu 40 umjesto u glavnu tablicu. Podignite sučelje i potvrdite da su stigle: ip -4 route ls table 40 treba pokazati rute tunela, a ip -4 route get 10.66.127.142 pokazuje kako jezgra trenutačno razrješava jednu od njih. Kad su rute u vlastitoj tablici, glavna tablica nastavlja raditi za sve ostalo.

Učinite isto za IPv6 umjesto da uparujete široki prefiks. ip -6 rule add from fd00::2/128 lookup 40 prikiva jednu adresu; fc00::/8 može se sudariti s drugim sučeljima na hostu i proizvesti pravilo koje odgovara više nego što je namjeravano.

Dodajte pravilo izvora i gledajte brojače

Zatim spojite polovine: ip -4 rule add from 10.66.127.142/32 lookup 40, s tom istom adresom pridodanom WireGuard sučelju. Stavite oba pravila u PostUp da ih ponovno povezivanje vrati. Provjerite stvarnim zahtjevom, a ne postavkom: ip route get 1.1.1.1 from 10.66.127.142 treba imenovati uređaj tunela, a curl --interface wg0 ifconfig.me treba prijaviti adresu tunela umjesto kućne.

Kad i dalje ne uspije, pročitajte ip -s rule. Pravilo koje postoji ali nikad nije odgovaralo pokazuje nula brojače, što razlikuje pogrešno pravilo od nikakvog pravila. Ta jedna naredba štedi mnogo nagađanja o tome je li aplikacija zanemarila svoju postavku sučelja.

Obrnuti slučaj: držite SSH izvan tunela

Suprotan problem jednako je čest: wg-quick posjeduje zadanu rutu i SSH sesija prema poslužitelju umire usred sesije. Njegova pravila stoje na niskom prioritetnom broju, pa se izuzetak mora ocijeniti prije njih. ip rule add dport 22 ipproto tcp table main priority 123 to radi na novijem iproute2; gdje selektor nije dostupan, označite tok u nftables i umjesto toga uparite oznaku.

Provjerite i put odgovora. SSH sesija koja se uspostavi pa utihne obično ima asimetrično usmjeravanje, s jednim smjerom kroz tunel i drugim kroz fizičko sučelje. ip route get za adresu poslužitelja govori vam kojim putem bi odgovor otišao.

Zapišite broj tablice, pravilo izvora i izuzetak u sam profil. Sva tri pripadaju jednom dizajnu i mijenjat će se zajedno.