Як побудувати тест WireGuard із двома пірами, що доводить один шлях

Один тунель, одна пара адрес, один дозволений ресурс. Мінімальна база WireGuard робить видимою кожну подальшу зміну переадресації, NAT або DNS.

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

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

Ключі, адреси та єдиний endpoint

Створіть пару ключів у кожній системі та переносьте між ними лише відкриті половини. wg genkey | tee privatekey | wg pubkey > publickey — це документована однорядкова команда, і вона залишає закритий ключ у файлі, який потім можна захистити. Виберіть адреси тунелю з діапазону, який не зустрічається в жодній іншій вашій конфігурації, наприклад 10.99.0.1/24 і 10.99.0.2/24. Запишіть, яка адреса належить якій машині, бо кожна подальша перевірка залежить від цієї відповідності.

Закриті ключі ніколи не подорожують. Якщо тесту потрібно скопіювати один на іншу сторону, тест уже пішов не так. Коли дві системи перебувають за NAT, принаймні одній потрібен доступний порт UDP, а інша несе Endpoint, що вказує на нього, і публічна адреса та порт мають бути у ваших нотатках, а не в припущеннях про 51820.

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

Поля, що належать wg, і ті, що ні

Основний набір полів малий: PrivateKey і ListenPort в Interface, PublicKey, AllowedIPs і Endpoint в Peer. Address і DNS належать wg-quick, а не самому wg, і ця різниця кусає в момент, коли та сама конфігурація переходить в інший інструмент.

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

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

Читати рукостискання, а не значок

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

Два збої передбачають різні розслідування. Повна відсутність рукостискання вказує на невідповідність ключів, неправильний Endpoint, заблокований UDP або міжмережевий екран, що відкидає саме рукостискання. Рукостискання, яке вдається, але дані нікуди не йдуть, вказує на AllowedIPs, службу, що не слухає адресу тунелю, або міжмережевий екран хоста, який приймає порт для LAN, але не для інтерфейсу тунелю. Це різні половини системи, і база розділяє їх, перш ніж ви почнете змінювати правила.

Довести одну дозволену службу, потім зворотний напрямок

Надішліть запит на адресу тунелю іншого піра до служби, яка має відповідати, і виберіть щось краще за ping. Відсутня відповідь ICMP може бути фільтрацією хоста, а не збоєм тунелю, тому тихий ping не доводить жодного напрямку. TCP-з'єднання з портом, який ви знаєте як відкритий, або запит, що повертає дані, дає відповідь, яку можна витлумачити.

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

Збереження бази як еталона

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

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

Схожі статті