WireGuard не показує останнього рукостискання: що перевірити першим

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

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

Простоюючому інтерфейсу нема чого повідомляти

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

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

Ініціюйте трафік, який peer має право переносити

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

ip route get 10.60.9.5
ping -c 3 -W 2 10.60.9.5
wg show wg0 latest-handshakes
wg show wg0 transfer

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

Порівняйте пару ключів і кінцеву точку

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

Кінцева точка потребує такої самої перевірки: ім'я хоста, адреса, порт UDP і родина, через яку до неї звертаються. Застаріла адреса або неправильний порт дають тишу замість повідомлення.

Стежте за зовнішнім шляхом UDP

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

ss -lunp | grep 51820
sudo tcpdump -ni eth0 udp port 51820
wg show wg0 endpoints
conntrack -L -p udp | grep 51820

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

Щойно з'явиться рукостискання, перевірте застосунок через тунель, бо завершений обмін доводить ідентичність і доступність, а не придатну пропускну здатність чи правильний DNS. Збережіть вивід стану до і після зміни, і різниця стане вашим доказом.