Једна апликација кроз WireGuard: везивање није рутирање

Поставка изгледа као прекидач по апликацији, па људи везују клијента за интерфејс WireGuard и очекују да само тај клијент користи тунел. Везивање заправо бира изворну адресу. Затим језгро тражи руту за одредиште, налази уобичајену подразумевану руту и шаље пакет кроз физичку везу са придодатом адресом тунела. Само рута изабрана за ту изворну адресу испуњава намеру.

Механизам има две половине: табелу рутирања коју би требало да користи само саобраћај тунела, и правило које одговарајући извор шаље тамо.

Везивање поставља изворну адресу и ништа више

Linux бира излазни интерфејс тражећи одредиште у табели рутирања, након што су правила политике имала прилику да то тражење преусмере. Правила могу бирати по изворној адреси, ознаци заштитног зида, долазном интерфејсу, UID-у или чак порту; свако је други начин да се каже овај саобраћај уместо сав. Конфигурација VPN клијента бира табелу која држи руте тунела; правило бира ком саобраћају је дозвољено да је консултује. Само везивање не даје ни једно ни друго.

Зато овај квар изгледа тако чудно. Апликација сигурно користи адресу тунела, тунел сигурно ради, а саобраћај сигурно излази кроз погрешан интерфејс. Свака тврдња је тачна, а заједно описују систем у ком ништа није повезало адресу са рутом.

Дајте тунелу сопствену табелу

wg-quick инсталира руте тамо где му профил каже. Додавање Table = 40 под [Interface] их премешта у табелу 40 уместо у главну табелу. Подигните интерфејс и потврдите да су стигле: ip -4 route ls table 40 треба да покаже руте тунела, а ip -4 route get 10.66.127.142 показује како језгро тренутно решава једну од њих. Када су руте у сопственој табели, главна табела наставља да ради за све остало.

Урадите исто за IPv6 уместо да упарујете широки префикс. ip -6 rule add from fd00::2/128 lookup 40 причвршћује једну адресу; fc00::/8 може се сударити са другим интерфејсима на хосту и произвести правило које одговара више него што је намеравано.

Додајте правило извора и гледајте бројаче

Затим спојите половине: ip -4 rule add from 10.66.127.142/32 lookup 40, са истом адресом придодатом интерфејсу WireGuard. Ставите оба правила у PostUp да их поновно повезивање врати. Проверите стварним захтевом, а не поставком: ip route get 1.1.1.1 from 10.66.127.142 треба да именује уређај тунела, а curl --interface wg0 ifconfig.me треба да пријави адресу тунела уместо кућне.

Када и даље не успева, прочитајте ip -s rule. Правило које постоји али се никада није поклопило показује нулте бројаче, и то разликује погрешно правило од тога да правила нема. Та једна команда штеди много нагађања о томе да ли је апликација игнорисала своју поставку интерфејса.

Обрнути случај: држите SSH изван тунела

Супротан проблем је једнако чест: wg-quick поседује подразумевану руту и SSH сесија ка серверу умире на средини. Његова правила стоје на ниском приоритетном броју, па изузетак мора бити оцењен пре њих. ip rule add dport 22 ipproto tcp table main priority 123 то ради на новијем iproute2; где селектор није доступан, означите ток у nftables и уместо тога упарите ознаку.

Проверите и пут одговора. SSH сесија која се успостави и затим утихне обично има асиметрично рутирање: један смер излази кроз тунел, а други кроз физички интерфејс. ip route get за адресу сервера говори вам којим путем би одговор отишао.

Запишите број табеле, правило извора и изузетак у сам профил. Сва три припадају једном дизајну и биће уређивана заједно.