Адна праграма праз 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 для адраса сервера падкажа, куды пойдзе адказ.

Запішыце нумар табліцы, правіла крыніцы і выключэнне ў сам профіль. Усе тры належаць да аднаго праекта і будуць рэдагавацца разам.