Рукостискання WireGuard проходить, але відповідь не повертається

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

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

Рукостискання доводить ключі, а не доставку

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

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

Одна внутрішня адреса — це весь тест

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

Далі подивіться на маршрут, який обирає клієнт. Конкретніший локальний маршрут може відправити пакет в інше місце ще до того, як WireGuard взагалі буде опитаний, і це трапляється щоразу, коли домашня LAN перетинається з віддаленим діапазоном.

ip route get 10.30.8.10
ip -4 addr show wg0
ip route show table all | grep -w wg0

Адреса, що розв'язується у фізичний інтерфейс, уже відповіла на питання. Тунель нічого не відкидає. Пакет так до нього й не потрапив.

Лічильники — це докази, а не вирок

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

wg show wg0 transfer
wg show wg0 latest-handshakes
ping -c 4 10.30.8.10
wg show wg0 transfer

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

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

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

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

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

Тримайте експеримент чесним

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

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

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