Вузол WireGuard недоступний, а інший працює: контрольний список

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

Крок 1: Запишіть шлях, який має пройти пакет

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

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

Крок 2: Порівняйте AllowedIPs з обох боків, а не лише з одного

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

Читайте живий стан, а не файл, бо перезавантаження могло тихо не вдатися: sudo wg show wg0 allowed-ips. На сервері запис збійного вузла має містити адресу його тунелю, наприклад 10.90.0.3/32. На клієнті запис вузла-сервера має містити призначення, яке ви тестуєте, чи то адреса тунелю концентратора, чи віддалена підмережа. Діапазони, що перекриваються, роблять пошук неоднозначним і можуть вибрати вузол, який ви не мали на увазі, тому тримайте їх окремо.

Крок 3: Перевірте внутрішню адресу джерела

Клієнт, який маршрутизує 10.90.0.3 через wg0, але надсилає пакети зі своєї Wi-Fi адреси, буде відхилений одержувачем, бо джерело не збігається з AllowedIPs вузла. Підтвердьте, що саме вибирає ядро, за допомогою ip route get 10.90.0.3 from 10.90.0.2, і підтвердьте адресу, призначену інтерфейсу тунелю, за допомогою ip -brief addr show wg0.

На приймальному хості Linux фільтрація зворотного шляху — це другі ворота. Суворий rp_filter на інтерфейсі, який володіє зворотним маршрутом, може відкидати тунельний трафік, зворотний шлях якого не збігається з інтерфейсом, яким він прийшов. Перевірте чинне значення, перш ніж вимикати його; у багатьох топологіях правильне виправлення — маршрут, а не послаблений фільтр.

Крок 4: Перегляньте пересилання на концентраторі та зворотний шлях

Якщо концентратор має пересилати між вузлами, ядру потрібен net.ipv4.ip_forward=1, а міжмережевий екран має приймати пересланий потік: вхід на wg0, вихід на wg0, від адреси тунелю відправника до адреси одержувача. Часта несправність — правило входу, яке приймає UDP 51820, але правила пересилання немає], тож рукостискання вдається, а корисне навантаження гине. Перелічіть чинні правила за допомогою sudo nft list ruleset або еквівалента для вашого менеджера міжмережевого екрана.

Потім перевірте відповідь. Хост призначення має мати маршрут назад до відправника, або через концентратор, або через власний шлюз. Якщо концентратор також виконує NAT для підмережі тунелю, підтвердьте, що трансляція застосовується до пересланого потоку і що відповідь досягає концентратора до завершення стану. Односторонній збій, який виглядає як проблема з ключем, часто є саме цим зворотним маршрутом.

Нарешті, відокремте рукостискання від даних. Вузол, який завершує рукостискання, але застрягає на великих передачах, зазвичай має проблему MTU або MSS саме на цьому шляху, а не проблему AllowedIPs. Спочатку перевірте малим ping, потім повнорозмірним, і порівняйте обидва вузли.

Крок 5: Змініть одну річ і збережіть робочий вузол недоторканим

Зробіть єдину зміну на збійному шляху і повторно перевірте обидва вузли. Заміна AllowedIPs кожного вузла на 0.0.0.0/0 — найшвидший спосіб зламати вузол, який уже працював, бо це змінює рішення про маршрутизацію для всього трафіку на цьому інтерфейсі. Відредагуйте один запис, перезавантажте і прочитайте живий стан назад.

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