WireGuard надсилає дані, але нічого не отримує назад: який бік?

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

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

Лічильники описують обсяг, а не напрямок несправності

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

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

Вибір партнера або зворотний шлях відповіді: два пояснення

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

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

Два з цих чотирьох рядків виправляються на клієнті, а два на сервері. Розуміння, у якій ви парі, — це більша частина роботи.

Де зникають відповіді

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

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

Перевірте один пункт призначення від початку до кінця

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

wg show wg0 latest-handshakes
wg show wg0 transfer
ip route get 10.60.9.5
sudo tcpdump -ni wg0 host 10.60.9.5

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

Якщо імена не працюють, а дозволена адреса працює, відповідь у DNS, а не в тунелі. Якщо застрягають лише великі передачі, дослідіть розмір пакета окремо.