Лічильник рукостискань оновлюється, інтерфейс зберігає свою адресу, а ping на інший бік нікуди не доходить. Таке поєднання бентежить людей, бо робоче рукостискання здається доказом готовності тунелю. Це не так: тунель може бути повністю узгоджений і все одно не мати жодного маршруту, який спрямовує трафік у нього, і це дві окремі задачі, які виконують дві окремі частини стану. Виправлення цілком залежить від того, якого з двох бракує, тому перший крок — це з’ясувати.

wg-quick виконує обидві без прохання. Вбудована підтримка WireGuard у NetworkManager також типово встановлює маршрути до пірів, що звужує коло підозрюваних до вимкненої опції, іншої таблиці маршрутизації або конфігурації, імпортованої через щось інше.

Підтвердьте тунель, перш ніж гнатися за маршрутом

wg show виводить інтерфейс, піра, кінцеву точку та вік останнього рукостискання, а ip addr show підтверджує наявність адреси. Нещодавнє рукостискання означає, що ключі, кінцева точка і шлях UDP працюють. Усе зламане сидить нижче за течією: маршрутизація, фільтрування або розв’язання імен.

Далі запитайте ядро, що воно зробить із реальним призначенням, а не гіпотетичним: ip route get 10.42.7.9. Відповідь називає вихідний інтерфейс і адресу джерела, яку ніс би пакет. Коли вона називає фізичний адаптер, пакет ніколи не потрапляє в тунель, хоч би як здорово виглядало рукостискання.

AllowedIPs — це фільтр і список маршрутів

Префікси в AllowedIPs виконують дві задачі. Вони вибирають, який пір несе вихідне призначення, і перевіряють адресу джерела вхідних пакетів, що і є межею маршрутизації за криптоключем. У wg-quick вони також керують автоматичним встановленням маршрутів, і саме ця додаткова поведінка пояснює, чому та сама конфігурація працює з термінала, а не з настільного клієнта.

У випадку, що стоїть за цією статтею, профіль було імпортовано через сторонній плагін, а не через вбудовану підтримку, і інтерфейс піднявся без префіксного маршруту. Перелік таблиці показує це одразу: ip route show містить лише підключений маршрут для адреси інтерфейсу і нічого для віддаленого діапазону.

Запитайте, чи маршрути до пірів узагалі ввімкнені

Прочитайте налаштування, перш ніж щось змінювати: nmcli -f wireguard.peer-routes,ipv4.route-table connection show work-wg. Коли peer-routes показує no, підтримуване виправлення — nmcli connection modify work-wg wireguard.peer-routes yes, а далі повторне підключення. Додавання статичного маршруту натомість працює до наступної активації і потім тихо зникає. Це зникнення і є підказкою: маршрут, який щоранку повертається як загадка, установлює не профіль.

Якщо опцію вже ввімкнено, перевірте за допомогою ip route show table all | grep 10, чи не живе префікс в іншій таблиці. Маршрут у таблиці, яка не є основною, не відсутній, він просто невидимий для пошуку, що заглядає лише в основну таблицю. Виправте політичну маршрутизацію, а не нагромаджуйте зверху дубльований запис.

Додайте префікс до з’єднання, а не до працюючої системи

У редакторі з’єднань сторінка WireGuard тримає піра та його AllowedIPs, а сторінка IPv4 — додаткові маршрути. Доданий там маршрут переживає повторні підключення, бо належить профілю. У командному рядку еквівалент — додати маршрут до з’єднання у формі з порожнім шлюзом, а потім опустити й підняти з’єднання, щоб зміна застосувалася.

Виберіть найвужчий префікс, що покриває потрібні вам хости. Копіювання прикладу /8 від постачальника може проковтнути локальні діапазони, що випадково лежать усередині, і спричинені збої виглядають як зламаний тунель, а не як занадто широкий маршрут.

Розділене тунелювання визначає список префіксів

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

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

Один власник таблиці маршрутів

wg-quick і NetworkManager обидва вважають, що володіють маршрутами інтерфейсу. Імпортуйте конфігурацію, написану для wg-quick, а потім запустіть ще й службу wg-quick, і ви отримаєте дубльовані або конфліктні записи, поведінка яких залежить від того, що запускалося останнім. Виберіть одного власника і приберіть іншого: якщо NetworkManager керує з’єднанням, вимкніть юніт wg-quick для цього інтерфейсу і ніколи не додавайте другий профіль для того самого пристрою.

Коли розділення має йти за фізичним адаптером, а не за призначенням, ви перейшли до політичної маршрутизації, а політична маршрутизація теж потребує одного автора. Перевірте, повторивши ip route get, а потім діставшись хоста всередині віддаленого префікса чимось, що виводить вибрану ним адресу джерела. Перевірте IPv6 і DNS окремо, якщо профіль несе щось із цього.

Схожі статті