Префікс хоста в 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

Захоплення — це те, що вирішує суперечки про напрямок. Якщо вихідні пакети з'являються на тунельному інтерфейсі, а сервер нічого не пише в лог, дальній кінець їх відкидає, зазвичай тому, що ваше джерело поза його списком дозволених. Якщо не з'являється взагалі нічого, маршруту немає або він указує в інше місце.

Потім полагодьте вужчий кінець. Пункт у списку дозволених на боці сервера для адреси вашого клієнта і пункт на боці клієнта для цільової підмережі — звична форма, і вона залишає префікс інтерфейсу в спокої. Розширюйте префікс лише якщо план адресації справді хоче спільну підмережу на цьому з'єднанні, і робіть це як зміну плану, а не як крок налагодження.