Jedna aplikacija kroz WireGuard: vezivanje nije rutiranje

Postavka izgleda kao prekidač po aplikaciji, pa ljudi vežu klijent za WireGuard interfejs i očekuju da samo taj klijent koristi tunel. Vezivanje zapravo bira izvornu adresu. Kernel zatim traži rutu za odredište, nalazi običnu zadanu rutu i šalje paket kroz fizički link s pridodatom adresom tunela. Samo ruta odabrana za tu izvornu adresu ispunjava namjeru.

Mehanizam ima dvije polovine: tabelu rutiranja koju treba da koristi samo saobraćaj tunela, i pravilo koje odgovarajuću izvornu adresu šalje tamo.

Vezivanje postavlja izvornu adresu i ništa više

Linux bira izlazni interfejs tražeći odredište u tabeli rutiranja, nakon što su pravila politike imala priliku preusmjeriti to traženje. Pravila mogu birati po izvornoj adresi, oznaci firewall-a, dolaznom interfejsu, UID-u ili čak portu; svako je drugi način da se kaže ovaj saobraćaj umjesto sav. Konfiguracija VPN klijenta bira tabelu koja drži rute tunela; pravilo bira kojem je saobraćaju dopušteno da je konsultuje. Samo vezivanje ne daje ni jedno ni drugo.

Zato kvar izgleda tako čudno. Aplikacija sigurno koristi adresu tunela, tunel sigurno radi, a saobraćaj sigurno izlazi kroz pogrešan interfejs. Svaka tvrdnja je tačna, a zajedno opisuju sistem u kojem ništa nije povezalo adresu s rutom.

Dajte tunelu vlastitu tabelu

wg-quick instalira rute gdje mu profil kaže. Dodavanje Table = 40 pod [Interface] premješta ih u tabelu 40 umjesto u glavnu tabelu. Podignite interfejs 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 kernel trenutno razrješava jednu od njih. Kad su rute u vlastitoj tabeli, glavna tabela nastavlja raditi za sve ostalo.

Uradite 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 interfejsima 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 pridodatom WireGuard interfejsu. 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 ignorisala postavku interfejsa.

Obrnuti slučaj: držite SSH izvan tunela

Suprotan problem je jednako čest: wg-quick posjeduje zadanu rutu i SSH sesija prema serveru umre 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 rutiranje, s jednim smjerom kroz tunel i drugim kroz fizički interfejs. ip route get za adresu servera govori ti kojim putem bi odgovor otišao.

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