Ena aplikacija skozi WireGuard: vezava ni usmerjanje

Nastavitev je videti kot stikalo za posamezno aplikacijo, zato ljudje vežejo odjemalca na vmesnik WireGuard in pričakujejo, da bo tunel uporabljal le ta odjemalec. Vezava v resnici izbere izvorni naslov. Jedro nato poišče pot do cilja, najde običajno privzeto pot in pošlje paket po fizični povezavi s priloženim naslovom tunela. Namen izpolni le pot, izbrana za ta izvorni naslov.

Mehanizem ima dve polovici: usmerjevalno tabelo, ki naj bi jo uporabljal le promet tunela, in pravilo, ki tja pošlje ustrezni izvor.

Vezava nastavi izvorni naslov in nič več

Linux izbere izhodni vmesnik tako, da poišče cilj v usmerjevalni tabeli, potem ko so imela pravila politike priložnost to iskanje preusmeriti. Pravila lahko izberejo po izvornem naslovu, oznaki požarnega zidu, vhodnem vmesniku, UID ali celo vratih; vsako je drug način, da rečemo ta promet namesto ves. Konfiguracija odjemalca VPN izbere tabelo, ki vsebuje poti tunela; pravilo izbere, kateri promet jo sme upoštevati. Sama vezava ne da niti enega niti drugega.

Zato je napaka videti tako nenavadna. Aplikacija zagotovo uporablja naslov tunela, tunel zagotovo deluje in promet zagotovo odhaja skozi napačen vmesnik. Vsaka trditev je resnična, skupaj pa opisujejo sistem, v katerem nič ni povezalo naslova s potjo.

Dajte tunelu lastno tabelo

wg-quick namesti poti tja, kamor mu pove profil. Dodajanje Table = 40 pod [Interface] jih premakne v tabelo 40 namesto v glavno tabelo. Dvignite vmesnik in potrdite, da so prispele: ip -4 route ls table 40 bi moralo pokazati poti tunela, ip -4 route get 10.66.127.142 pa pokaže, kako jedro trenutno razrešuje eno od njih. Ko so poti v svoji tabeli, glavna tabela še naprej deluje za vse ostalo.

Enako storite za IPv6, namesto da bi ujemali široko predpono. ip -6 rule add from fd00::2/128 lookup 40 pripne en naslov; fc00::/8 lahko trči z drugimi vmesniki na gostitelju in ustvari pravilo, ki se ujema z več, kot je bilo mišljeno.

Dodajte pravilo izvora in opazujte števce

Nato povežite obe polovici: ip -4 rule add from 10.66.127.142/32 lookup 40, z istim naslovom, pritrjenim na vmesnik WireGuard. Postavite obe pravili v PostUp, da ju ponovna povezava obnovi. Preverite z resnično zahtevo in ne z nastavitvijo: ip route get 1.1.1.1 from 10.66.127.142 bi moralo navesti napravo tunela, curl --interface wg0 ifconfig.me pa bi moralo poročati naslov tunela namesto domačega.

Ko še vedno ne uspe, preberite ip -s rule. Pravilo, ki obstaja, a se ni nikoli ujemalo, pokaže ničelne števce, in to loči napačno pravilo od tega, da pravila sploh ni. Ta en ukaz prihrani veliko ugibanja o tem, ali je aplikacija prezrla svojo nastavitev vmesnika.

Obrnjen primer: držite SSH zunaj tunela

Nasprotna težava je prav tako pogosta: wg-quick ima v lasti privzeto pot in SSH seja na strežnik umre na sredini. Njegova pravila sedijo na nizki prioritetni številki, zato je treba izjemo ovrednotiti prej kot ona. ip rule add dport 22 ipproto tcp table main priority 123 to naredi na novejšem iproute2; kjer izbirnik ni na voljo, označite tok v nftables in namesto tega ujemite oznako.

Preverite tudi pot odgovora. SSH seja, ki se vzpostavi in nato utihne, ima običajno asimetrično usmerjanje: ena smer odhaja skozi tunel, druga skozi fizični vmesnik. ip route get za naslov strežnika vam pove, kam bi šel odgovor.

Zapišite številko tabele, pravilo izvora in izjemo v sam profil. Vse tri pripadajo eni zasnovi in bodo urejene skupaj.