Unu aplikaĵo tra WireGuard: ligado ne estas enkursigado
Ligi aplikaĵon al wg0 nur elektas ĝian fontan adreson. La kerno ankoraŭ bezonas tabelon kun la tunelaj itineroj kaj regulon, kiu sendas tiun fonton tien.
La agordo aspektas kiel ŝaltilo por ĉiu aplikaĵo, do homoj ligas la klienton al la WireGuard-interfaco kaj atendas, ke nur tiu kliento uzu la tunelon. Kion la ligado fakte faras, estas elekti fontan adreson. Poste la kerno serĉas itineron al la celo, trovas la ordinaran defaŭltan itineron kaj sendas la paketon eksteren tra la fizika ligo kun la tunela adreso aldonita. Nur itinero elektita por tiu fonta adreso plenumas la intencon.
La mekanismo havas du duonojn: enkursigan tabelon, kiun nur la trafiko de la tunelo uzu, kaj regulon, kiu sendas la kongruan fonton tien.
Ligado elektas fontan adreson, nenion pli
Linux elektas eliran interfacon serĉante la celon en enkursiga tabelo, post kiam politikaj reguloj havis ŝancon redirekti tiun serĉon. Reguloj povas elekti laŭ la fonta adreso, fajroŝirma marko, la envenanta interfaco, UID aŭ eĉ pordo; ĉiu estas alia maniero diri ĉi tiu trafiko anstataŭ la tuta. La agordo de la VPN-kliento elektas la tabelon, kiu tenas la tunelajn itinerojn; la regulo elektas, kiu trafiko rajtas konsulti ĝin. La ligado sola donas nek unu nek la alian.
Tial la malsukceso aspektas tiel stranga. La aplikaĵo sendube uzas la tunelan adreson, la tunelo sendube estas aktiva, kaj la trafiko sendube eliras tra la malĝusta interfaco. Ĉiu aserto veras, kaj kune ili priskribas sistemon, en kiu nenio ligis la adreson al la itinero.
Donu al la tunelo sian propran tabelon
wg-quick instalas itinerojn kie ajn la profilo diras. Aldoni Table = 40 sub [Interface] movas ilin al tabelo 40 anstataŭ la ĉefa tabelo. Aktivigu la interfacon kaj konfirmu, ke ili alvenis: ip -4 route ls table 40 devus montri la itinerojn de la tunelo, kaj ip -4 route get 10.66.127.142 montras, kiel la kerno nun solvas unu el ili. Kun la itineroj en sia propra tabelo, la ĉefa tabelo daŭre funkcias por ĉio alia.
Faru same por IPv6 anstataŭ kongruigi larĝan prefikson. ip -6 rule add from fd00::2/128 lookup 40 fiksas unu adreson; fc00::/8 povas kolizii kun aliaj interfacoj en la gastiganto kaj produkti regulon, kiu kongruas pli ol intencite.
Aldonu la fontan regulon kaj observu la nombrilojn
Poste kunigu la duonojn: ip -4 rule add from 10.66.127.142/32 lookup 40, kun la sama adreso alligita al la WireGuard-interfaco. Metu ambaŭ regulojn en PostUp, por ke rekonekto restarigu ilin. Kontrolu per reala peto anstataŭ per agordo: ip route get 1.1.1.1 from 10.66.127.142 devus nomi la tunelan aparaton, kaj curl --interface wg0 ifconfig.me devus raporti la adreson de la tunelo anstataŭ la hejman.
Kiam ĝi ankoraŭ malsukcesas, legu ip -s rule. Regulo, kiu ekzistas sed neniam kongruis, montras nulajn nombrilojn, kaj tio distingas malĝustan regulon de tute nenia regulo. Tiu sola komando ŝparas multan konjektadon pri tio, ĉu la aplikaĵo ignoris sian interfacan agordon.
La inversa kazo: tenu SSH ekster la tunelo
La kontraŭa problemo estas same ofta: wg-quick posedas la defaŭltan itineron kaj la SSH-sesio al la servilo mortas meze de la sesio. Ĝiaj reguloj sidas ĉe malalta prioritata numero, do escepto devas esti taksata pli frue ol ili. ip rule add dport 22 ipproto tcp table main priority 123 faras tion en lastatempa iproute2; kie la selektilo ne haveblas, marku la fluon en nftables kaj kongruigu la markon anstataŭe.
Kontrolu ankaŭ la respondan vojon. SSH-sesio, kiu establiĝas kaj poste silentas, kutime havas nesimetrian enkursigadon, kun unu direkto eliranta tra la tunelo kaj la alia tra la fizika interfaco. ip route get por la servila adreso diras al vi, kien la respondo irus.
Notu la tabelan numeron, la fontan regulon kaj la escepton en la profilo mem. Ĉiuj tri apartenas al unu dezajno kaj estos redaktataj kune.