AllowedIPs — це список маршрутизації, а не правило брандмауера

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

Одне поле, два читачі: вибір вихідного та перевірка джерела

На клієнті префікси вирішують, які призначення йдуть до цього партнера, а які залишаються в звичайній мережі. Тому запис для 0.0.0.0/0 охоплює кожне призначення IPv4, і тому імпорт профілю повного тунелю надсилає звичайний перегляд через віддалену машину. Вузькі записи роблять навпаки: маршрутизують лише перелічені мережі, а все інше залишають на місці. Розділ про маршрутизацію криптоключів у документації WireGuard викладає обидва завдання в одному місці: вибір вихідного партнера та перевірку вхідного джерела.

На сервері те саме поле описує, які адреси джерела може використовувати кожен партнер. Це криптографічна перевірка, а не фільтр пакетів: пакет, внутрішнє джерело якого не збігається зі списком партнера, відкидається всередині WireGuard ще до того, як його побачить будь-який брандмауер хоста. Обидва завдання поділяють один список, і саме тому список, скопійований з іншого місця, поводиться неправильно там, де ви цього не врахували.

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

[Peer]
# split tunnel: only these networks
AllowedIPs = 10.77.0.0/24, 192.168.30.0/24

[Peer]
# full tunnel: everything, both families
AllowedIPs = 0.0.0.0/0, ::/0

Обидві форми самодостатні, і це альтернативи, а не кроки. Перша надсилає через тунель лише ті дві мережі; друга надсилає кожне призначення, а запис ::/0 додає IPv6 до стандартного IPv4. Який би ви не обрали, ці префікси — усе рішення про маршрутизацію для цього партнера, щойно wg-quick почне встановлювати маршрути.

Хабу потрібен інший список

Хаб перелічує адресу тунелю кожного клієнта як префікс хоста, плюс будь-яку мережу, що справді стоїть за цим клієнтом. Копіювання широкого списку клієнта на кожного партнера хаба повідомляє хабу, що багато партнерів можуть використовувати ті самі адреси як джерело, а це не план адрес. Поле Endpoint належить зовсім іншому рівню: воно називає зовнішню адресу та порт партнера, ніколи не призначення всередині тунелю.

[Peer]
# laptop: tunnel address 10.77.0.2, office LAN behind it
AllowedIPs = 10.77.0.2/32, 192.168.30.0/24

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

Пропуск встановлення маршрутів залишає розрив

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

Базовий інструмент wg поводиться інакше: він налаштовує інтерфейс і ніколи не торкається маршрутів, тому налаштування, побудоване безпосередньо на ньому, потребує власних команд маршрутів. Інструкції, написані для одного інструмента, можуть виглядати неправильно, коли їх виконують з іншим. Успішний ping — теж слабкий доказ, бо він перевіряє один шлях, а не кожен потрібний шлях застосунку.

DNS і IPv6 вирішуються окремо

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

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