Isang app sa WireGuard: ang pag-bind ay hindi pag-routing

Mukhang switch para sa bawat app ang setting, kaya binibind ng mga tao ang client sa interface ng WireGuard at inaasahang ang client na iyon lang ang gagamit ng tunnel. Ang tunay na ginagawa ng pag-bind ay pumili ng source address. Pagkatapos ay hinahanap ng kernel ang ruta patungo sa destinasyon, natagpuan ang karaniwang default na ruta, at ipinapadala ang packet sa pisikal na link na may nakakabit na address ng tunnel. Tanging ruta na pinili para sa source address na iyon ang tumutupad sa layunin.

May dalawang hati ang mekanismong ito: isang talahanayan ng routing na dapat gamitin lamang ng trapiko ng tunnel, at isang panuntunang nagpapadala ng tugmang source doon.

Ang pag-bind ay nagtatakda ng source address, wala nang iba

Pinipili ng Linux ang palabas na interface sa pamamagitan ng paghahanap ng destinasyon sa talahanayan ng routing, matapos magkaroon ng pagkakataon ang mga panuntunan ng patakaran na ilihis ang paghahanap na iyon. Maaaring pumili ang mga panuntunan batay sa source address, marka ng firewall, papasok na interface, UID o maging port; bawat isa ay ibang paraan ng pagsasabi ng trapikong ito sa halip na lahat. Pinipili ng configuration ng client ng VPN ang talahanayang may mga ruta ng tunnel; pinipili ng panuntunan kung aling trapiko ang pinapayagang kumonsulta rito. Ang pag-bind lamang ay hindi nagbibigay ng alinman sa dalawa.

Kaya ganito kakataka ang pagpalya. Ginagamit ng app ang address ng tunnel, sigurado iyon, gumagana ang tunnel, sigurado iyon, at lumalabas ang trapiko sa maling interface, sigurado iyon. Totoo ang bawat pahayag, at magkasama nilang inilalarawan ang isang sistemang walang nag-ugnay ng address sa ruta.

Bigyan ang tunnel ng sarili nitong talahanayan

Inilalagay ng wg-quick ang mga ruta kung saan sinasabi ng profile. Kapag idinagdag ang Table = 40 sa ilalim ng [Interface], lumilipat ang mga ito sa talahanayan 40 sa halip na sa pangunahing talahanayan. Itaas ang interface at tiyakin na nakarating ang mga ito: dapat ipakita ng ip -4 route ls table 40 ang mga ruta ng tunnel, at ipinapakita ng ip -4 route get 10.66.127.142 kung paano nilulutas ng kernel ang isa sa mga ito ngayon. Kapag nasa sariling talahanayan ang mga ruta, patuloy na gumagana ang pangunahing talahanayan para sa lahat ng iba pa.

Gawin din ito para sa IPv6 sa halip na itugma ang malawak na prefix. Itinatakda ng ip -6 rule add from fd00::2/128 lookup 40 ang isang address; maaaring bumangga ang fc00::/8 sa ibang interface sa host at makabuo ng panuntunang tumutugma nang higit sa nilalayon.

Idagdag ang panuntunan ng source at tingnan ang mga counter

Pagkatapos, ikonekta ang dalawang hati: ip -4 rule add from 10.66.127.142/32 lookup 40, na nakakabit pa rin ang parehong address sa interface ng WireGuard. Ilagay ang dalawang panuntunan sa PostUp upang maibalik ang mga ito kapag muling kumonekta. I-verify sa tunay na kahilingan at hindi sa setting: dapat pangalanan ng ip route get 1.1.1.1 from 10.66.127.142 ang device ng tunnel, at dapat iulat ng curl --interface wg0 ifconfig.me ang address ng tunnel sa halip na ang address ng bahay.

Kapag nabigo pa rin, basahin ang ip -s rule. Ang panuntunang umiiral ngunit hindi kailanman tumugma ay nagpapakita ng zero na counter, at iyon ang nagtatangi ng maling panuntunan sa kawalan ng anumang panuntunan. Ang isang utos na iyon ay nakakatipid ng maraming hulaan tungkol sa kung binalewala ng app ang setting ng interface nito.

Ang kabaligtarang kaso: ilagay ang SSH sa labas ng tunnel

Ang kabaligtarang problema ay karaniwan din: pagmamay-ari ng wg-quick ang default na ruta at namamatay ang session ng SSH sa server sa kalagitnaan. Nasa mababang priority number ang mga panuntunan nito, kaya kailangang suriin ang eksepsiyon bago ang mga iyon. Ginagawa iyon ng ip rule add dport 22 ipproto tcp table main priority 123 sa bagong iproute2; kung saan walang selector, markahan ang flow sa nftables at itugma ang marka.

Tingnan din ang ruta ng tugon. Ang session ng SSH na naitatag at pagkatapos ay tumahimik ay karaniwang may asymmetric na routing, kung saan ang isang direksiyon ay lumalabas sa tunnel at ang isa naman sa pisikal na interface. Ang ip route get para sa address ng server ay magsasabi kung saan pupunta ang tugon.

Itala ang numero ng talahanayan, ang panuntunan ng source at ang eksepsiyon sa profile mismo. Ang tatlo ay kabilang sa isang disenyo at i-edit nang sabay.