Една апликација низ 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 за адресата на серверот ви кажува на која страна би одел одговорот.

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