Рукостискання WireGuard працює, а служба — ні

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

Зупиніться на першій, яка не виконується, і не додавайте правил для решти.

Рукостискання доводить лише тунель

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

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

Прочитайте слухач і маршрут

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

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

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

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

Застосовуйте правила для локального вводу, а не для пересилання

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

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

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

Розділяйте відмови за іменем, розміром та ідентичністю

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

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

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