Viena lietotne caur WireGuard: piesaiste nav maršrutēšana

Iestatījums izskatās kā slēdzis katrai lietotnei, tāpēc cilvēki piesaista klientu WireGuard saskarnei un sagaida, ka tuneli izmantos tikai šis klients. Piesaiste patiesībā izvēlas avota adresi. Pēc tam kodols meklē maršrutu uz galamērķi, atrod parasto noklusējuma maršrutu un nosūta paketi pa fizisko savienojumu ar piesaistītu tuneļa adresi. Tikai šai avota adresei izvēlēts maršruts piepilda nodomu.

Mehānismam ir divas puses: maršrutēšanas tabula, ko drīkst izmantot tikai tuneļa plūsma, un noteikums, kas atbilstošo avotu turp aizsūta.

Piesaiste nosaka avota adresi un neko vairāk

Linux izvēlas izejas saskarni, meklējot galamērķi maršrutēšanas tabulā, pēc tam kad politikas noteikumi ir ieguvuši iespēju šo meklēšanu novirzīt citur. Noteikumi var izvēlēties pēc avota adreses, ugunsmūra atzīmes, ienākošās saskarnes, UID vai pat porta; katrs ir cits veids, kā pateikt šī plūsma, nevis visa. VPN klienta konfigurācija izvēlas tabulu, kurā ir tuneļa maršruti; noteikums izvēlas, kurai plūsmai ir atļauts tajā ieskatīties. Vien piesaiste nedod ne vienu, ne otru.

Tāpēc šī kļūme izskatās tik dīvaini. Lietotne noteikti izmanto tuneļa adresi, tunelis noteikti ir aktīvs, un plūsma noteikti iziet pa nepareizo saskarni. Katrs apgalvojums ir patiess, un kopā tie apraksta sistēmu, kurā nekas nesaistīja adresi ar maršrutu.

Dodiet tunelim savu tabulu

wg-quick instalē maršrutus tur, kur to norāda profils. Pievienojot Table = 40 zem [Interface], tie pārceļas uz tabulu 40, nevis galveno tabulu. Paceliet saskarni un pārliecinieties, ka tie ir ieradušies: ip -4 route ls table 40 jāparāda tuneļa maršruti, un ip -4 route get 10.66.127.142 parāda, kā kodols pašlaik atrisina vienu no tiem. Kad maršruti ir savā tabulā, galvenā tabula turpina darboties visam pārējam.

Dariet to pašu IPv6 gadījumā, nevis saskaņojiet platu prefiksu. ip -6 rule add from fd00::2/128 lookup 40 piesprauž vienu adresi; fc00::/8 var sadurties ar citām saskarnēm uz resursdatora un radīt noteikumu, kas atbilst vairāk, nekā paredzēts.

Pievienojiet avota noteikumu un vērojiet skaitītājus

Pēc tam savienojiet abas puses: ip -4 rule add from 10.66.127.142/32 lookup 40, ar to pašu adresi, kas piesaistīta WireGuard saskarnei. Ievietojiet abus noteikumus PostUp, lai atkārtots savienojums tos atjaunotu. Pārbaudiet ar īstu pieprasījumu, nevis iestatījumu: ip route get 1.1.1.1 from 10.66.127.142 jānosauc tuneļa ierīce, un curl --interface wg0 ifconfig.me jāziņo tuneļa adrese, nevis mājas adrese.

Kad tas joprojām neizdodas, izlasiet ip -s rule. Noteikums, kas pastāv, bet nekad nav sakritis, rāda nulles skaitītājus, un tas atšķir nepareizu noteikumu no tā, ka noteikuma vispār nav. Šī viena komanda ietaupa daudz minējumu par to, vai lietotne ignorēja savu saskarnes iestatījumu.

Pretējais gadījums: turiet SSH ārpus tuneļa

Pretējā problēma ir tikpat izplatīta: wg-quick pārvalda noklusējuma maršrutu, un SSH sesija uz serveri nomirst sesijas vidū. Tā noteikumi atrodas zemā prioritātes numurā, tāpēc izņēmums jāizvērtē pirms tiem. ip rule add dport 22 ipproto tcp table main priority 123 to dara jaunākā iproute2; kur selektors nav pieejams, atzīmējiet plūsmu nftables un saskaņojiet atzīmi.

Pārbaudiet arī atbildes ceļu. SSH sesijai, kas izveidojas un pēc tam apklust, parasti ir asimetriska maršrutēšana: viens virziens iziet pa tuneli, otrs pa fizisko saskarni. ip route get servera adresei parāda, uz kuru pusi dotos atbilde.

Pierakstiet tabulas numuru, avota noteikumu un izņēmumu pašā profilā. Visi trīs pieder vienam projektam un tiks rediģēti kopā.