WireGuard отправляет данные, но ничего не получает обратно: какая сторона?
Растущий счётчик отправки — это направление, а не диагноз. Прежде чем что-то менять, определите, запрос так и не покинул туннель или ответ так и не вернулся.
Счётчики отправки, которые растут, пока счётчик приёма остаётся на нуле, описывают направление, а не диагноз. Та же картина возникает, когда партнёр так и не завершил рукопожатие, когда пункт назначения выбрал не того партнёра, когда у дальней стороны нет обратного маршрута и когда фильтр отбрасывает ответ на пути домой. Каждый из этих случаев исправляется в другом месте.
Сравнение, которое сокращает работу, — это запрос, так и не покинувший туннель, и ответ, так и не вернувшийся. Одна запись на правильном интерфейсе решает, что именно произошло.
Счётчики описывают объём, а не направление неисправности
Счётчики WireGuard записывают, что интерфейс передал партнёру и что получил от него. Они не говорят, какой пункт назначения, какой партнёр или какая половина обмена не сработала. Фоновый трафик делает итоги ещё менее информативными, поскольку часть байтов может быть сообщениями поддержания связи или посторонними потоками. Читайте их как признак того, что интерфейс активен, а затем перестаньте считать их доказательством.
Первый полезный факт — актуально ли рукопожатие. Без него для этого партнёра ничего не было зашифровано, и счётчику приёма нет причины двигаться.
Выбор партнёра или обратный путь ответа: два объяснения
Первое объяснение: пакет так и не дошёл до нужного партнёра, потому что маршрут указывал в другое место или разрешённые префиксы партнёра не покрывали пункт назначения. Второе: пакет дошёл, но ответ не смог вернуться, а это проблема маршрутизации на дальнем конце. Таблица разделяет их по тому, что вы увидите в каждой точке.
| Observation | Points to |
|---|---|
| No handshake while transmit climbs | Peer selection or endpoint |
| Handshake current, request visible on the server | Reply path or far-side route |
| Request never visible on the server | Allowed prefixes or local route |
| Both packets visible, nothing reaches the client | Return filter or translation |
Читайте таблицу сверху. Отсутствие рукопожатия отправляет вас к ключам, конечным точкам и внешнему пути, потому что больше пока нечего изучать. Актуальное рукопожатие с видимым на сервере запросом переносит проблему в обратном направлении, где решает собственная таблица маршрутов пункта назначения. Запрос, который никогда не появляется на сервере, — это проблема выбора, и разрешённые префиксы у обоих партнёров — первое, что нужно сравнить.
Две из этих четырёх строк исправляются на клиенте, а две на сервере. Понимание, в какой вы паре, — это большая часть работы.
Где исчезают ответы
Ответ покидает пункт назначения, достигает туннельного интерфейса сервера и шифруется для партнёра, разрешённые адреса которого совпадают с внутренним адресом клиента. Если это совпадение не срабатывает, ответ молча отбрасывается, что со стороны клиента выглядит в точности как сбой сети. Если ответ зашифрован, а собственный фильтр клиента его отвергает, симптом снова тот же. В обоих случаях нужна запись, а не счётчик.
Самая грубая форма этой ошибки — сервер, который пересылает пакеты за клиента, но не имеет маршрута обратно во внутренний диапазон клиента. Он принимает запрос, отправляет ответ в сторону своего шлюза по умолчанию, и туннель его не видит. Широкое правило трансляции, добавленное на сервере, скрывает эту неисправность вместо исправления маршрута.
Проверьте один пункт назначения от начала до конца
Выберите один пункт назначения внутри диапазона партнёра и проверьте его, пока рукопожатие явно актуально. Команды ниже читают состояние партнёра, выбранный маршрут и обе стороны обмена. Запускайте запись на интерфейсе, который действительно используют зашифрованные пакеты.
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, а не в туннеле. Если застревают только большие передачи, исследуйте размер пакета отдельно.