Префикс на хост в WireGuard: защо един адрес работи, а останалите не

Тунелът е вдигнат, handshake се случва на всеки две минути и точно един адрес от другата страна отговаря. Пинговете към тунелния адрес на пиъра работят; нищо зад него не работи. Някой прочита конфигурацията на интерфейса, вижда префикс на хост и заключава, че маската е грешна. Разширяването до /24 оправя пинга за известно време и след това чупи нещо друго. Префиксът никога не е бил причината, а липсващият маршрут не е този, който маската контролира.

Какво всъщност създава префиксът на интерфейса

В Linux присвояването на адрес на интерфейс създава свързан маршрут за този префикс. Ако присвоите префикс на хост, свързаният маршрут покрива един адрес. Ако присвоите /24, той покрива 256 и всеки от тях вече се смята за достижим през тази връзка.

ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1

Префиксът на хост е напълно нормален избор за тунел точка-точка, защото от другата страна има точно един пиър. Третата команда е тази, която отговаря на въпроса на потребителя: казва кой интерфейс ядрото би използвало за тази дестинация и няма да покаже нищо полезно, ако не съвпада нито един маршрут.

Това е цялото обяснение на симптома. Един адрес отговаря, защото за него има свързан маршрут, или защото списъкът с разрешени на пиъра случайно го включва. Всичко останало няма маршрут и се изхвърля, преди WireGuard изобщо да е замесен. Тунелът е здрав през цялото време, затова броячът на handshake продължава да изглежда успокояващо.

AllowedIPs са две правила под едно име

Списъкът с разрешени за всеки пиър в WireGuard върши две работи наведнъж, а синтаксисът на конфигурацията ги прави да изглеждат като една. На входа разрешава кои изходни адреси пиърът може да представи. На изхода избира към кой пиър да отиде пакетът, като намира най-конкретното съвпадение.

Нито една от тези работи не е маршрутизация. Ядрото все още трябва да реши, че пакетът принадлежи на тунелния интерфейс, преди WireGuard да го погледне, и това решение идва от таблицата за маршрутизация. Запис на пиър с широк списък с разрешени сам по себе си не инсталира маршрут.

Затова конфигурацията може да изглежда пълна, а да се държи асиметрично. Клиентът изпраща към другата страна, защото има маршрут, а отговорите никога не пристигат, защото списъкът с разрешени на другата страна не разрешава източника на клиента или защото другата страна няма обратен път. Двете посоки са отделни решения с отделни режими на отказ. Да запишете кое от тях тествате е половината от диагнозата.

Откъде идва маршрутът

Ако използвате wg-quick, маршрутите се генерират за вас от списъка с разрешени на всеки пиър, освен ако не сте задали Table = off и не сте поели контрола сами. Това е поведението, което инструментът документира, и това е причината конфигурация без изрични директиви за маршрути да работи въпреки това.

sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0

Сравнете списъка с разрешени с маршрутите, които действително съществуват. Пиър, който разрешава цяла подмрежа, но е създал само маршрут на хост, означава, че помощникът никога не се е изпълнявал, или че управлявате интерфейса директно с wg и ip, и в този случай нищо не генерира маршрути за вас.

Когато го управлявате на ръка, маршрутът е един ред и формата му е изрична: дестинацията през интерфейса, без шлюз, защото връзката е точка-точка. Добавянето му не е заобиколно решение за лош префикс; това е липсващата половина от дизайн, който съзнателно е поел маршрутизацията.

По-широк префикс не добавя записа на пиъра

Изкушаващото решение е адресът да се смени на /24, за да покрие свързаният маршрут локалната мрежа на сървъра. Изглежда, че работи, и причината да изглежда така е, че свързаният маршрут вече съвпада, а не че WireGuard е научил нещо ново.

Това, което също направихте, е да предявите целия диапазон като пряко достижим през тази връзка, включително адреси, които принадлежат на други пиъри или на локална мрежа, която всъщност е зад сървъра. Трафикът към тези адреси сега влиза в тунела и дали ще излезе от другата страна зависи от маршрутизацията и списъците с разрешени на самия сървър.

Криптографската страна не е засегната в нито един случай. WireGuard все още се нуждае от запис в списъка с разрешени, който покрива дестинацията, за да избере пиър, а другата страна все още се нуждае от запис, който покрива вашия източник, за да го приеме. По-широк префикс на интерфейса не може да осигури нито едно от двете.

Потвърдете двете посоки, преди да промените нещо

Разгледайте двата края поотделно и запишете какво казва всеки. На клиента маршрутът и записът на пиъра; на сървъра огледалната картина плюс собствения му обратен път:

ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10

Заснемането е това, което решава споровете за посоката. Ако изходящите пакети се появят на тунелния интерфейс, а сървърът не записва нищо, далечният край ги отхвърля, обикновено защото вашият източник е извън неговия списък с разрешени. Ако не се появи абсолютно нищо, маршрутът липсва или сочи другаде.

След това поправете по-тесния край. Запис в списъка с разрешени от страна на сървъра за адреса на вашия клиент и запис от страна на клиента за целевата подмрежа е нормалната форма и оставя префикса на интерфейса на мира. Разширявайте префикса само ако планът за адресиране наистина иска споделена подмрежа на тази връзка, и го правете като промяна на плана, а не като стъпка за отстраняване на грешки.