Ошибки подключения туннеля: нет handshake, рвётся соединение, не открываются сайты

Как проверить, был ли handshake

Handshake — это первичное согласование ключей между клиентом и сервером, после которого начинается обмен зашифрованным трафиком. Пока его нет, туннель существует только как конфигурация, но фактически не работает: пакеты в него уходят, но ответа никто не даёт. Проверить наличие handshake можно через интерфейс роутера или консольную команду, которая покажет время последнего успешного согласования для каждого пира.

На OpenWrt и роутерах с LuCI это делается командой `wg show`, которая выводит поле latest handshake в секундах или минутах с момента события. Если это поле отсутствует или показывает время в часах, соединение не работает и данные не идут. На Keenetic аналогичную информацию можно увидеть в веб-интерфейсе в разделе туннеля AmneziaWG, где статус подключения либо активен, либо помечен как ожидание. На MikroTik в RouterOS есть отдельная колонка last-handshake в разделе WireGuard Peers.

Важно проверять handshake сразу после перезапуска интерфейса и спустя минуту-две: у AmneziaWG первое согласование иногда занимает больше времени из-за обфускации трафика, которая добавляет к пакетам дополнительный слой мусорных данных. Если через две-три минуты handshake так и не появился, переходите к следующему разделу с диагностикой конкретных причин.

1. 1Выполните `wg show` на роутере с OpenWrt или зайдите в статус туннеля на Keenetic/MikroTik
2. 2Найдите поле latest handshake для нужного пира
3. 3Если значение больше двух-трёх минут или отсутствует — handshake не состоялся
4. 4Перезапустите интерфейс и повторите проверку через 60–90 секунд

Нет handshake: пять основных причин

Если handshake не появляется вообще, в девяти случаях из десяти причина в одной из пяти вещей: неверный endpoint, закрытый порт, несовпадающие ключи, проблема с системным временем или блокировка со стороны CGNAT у провайдера. Разбирать их стоит по порядку от самой частой к самой редкой, потому что проверка каждой занимает буквально минуту.

Endpoint — это адрес и порт сервера в конфигурации клиента. Опечатка в IP-адресе, домене или порту полностью исключает возможность согласования, и никакой ошибки при этом роутер может не показать: пакеты просто уходят в пустоту. Проверьте, что домен резолвится в правильный IP, а порт совпадает с портом, который слушает сервер AmneziaWG.

Закрытый порт на файрволе сервера или на промежуточном оборудовании — вторая по частоте причина. Порт UDP, на котором работает AmneziaWG, должен быть открыт как на сервере, так и на роутере или NAT-устройстве между клиентом и сервером. Проверить доступность порта можно простым UDP-сканером или временным TCP-тестом на соседний открытый порт, если UDP тестировать нечем напрямую.

Несовпадение ключей — публичный ключ сервера в конфиге клиента должен точно совпадать с приватным ключом сервера, и наоборот. При копировании конфигурации вручную легко перепутать местами публичный и приватный ключ или обрезать символ при копировании. Системное время также критично: если на роутере сбито время и разница с сервером больше нескольких минут, согласование может не проходить из-за проверки временных меток. Наконец, CGNAT у мобильных и части проводных провайдеров блокирует входящие соединения на стороне клиента, поэтому если ваш роутер выступает в роли сервера, а не клиента, потребуется проброс через промежуточный VPS.

1. 1Сверьте endpoint (домен/IP и порт) в конфиге с реальным адресом сервера
2. 2Проверьте, что UDP-порт открыт на сервере и не блокируется провайдером
3. 3Сверьте публичный ключ сервера и приватный ключ клиента посимвольно
4. 4Проверьте системное время на роутере (NTP должен быть синхронизирован)
5. 5Если роутер работает как сервер за CGNAT — используйте промежуточный VPS с публичным IP

# Проверка доступности UDP-порта сервера с роутера (OpenWrt)
nc -u -v -z -w3 vpn.example.com 51820

# Проверка синхронизации времени
ntpd -q -p pool.ntp.org 2>&1 | tail -n5

Handshake есть, но сайты не открываются

Это второй по частоте сценарий: соединение согласовано, latest handshake обновляется, но интернет через туннель не работает. Причина почти всегда в маршрутизации, а не в самом шифровании — раз ключи согласовались, криптография отработала правильно. Дальше нужно проверять AllowedIPs, таблицу маршрутов на роутере, правила файрвола и корректность DNS.

AllowedIPs в конфигурации пира определяет, какой трафик вообще должен идти через туннель. Если там указано не 0.0.0.0/0, а более узкая подсеть, весь остальной трафик пойдёт в обход туннеля напрямую, и с точки зрения пользователя это будет выглядеть как «туннель не работает», хотя формально он работает — просто не для нужного трафика. Проверьте также, что на сервере в его AllowedIPs для этого пира прописана подсеть, из которой клиент реально отправляет пакеты.

Если с AllowedIPs всё в порядке, следующий шаг — таблица маршрутов. На роутере должен появиться маршрут по умолчанию либо более специфичный маршрут через интерфейс AmneziaWG. Отсутствие такого маршрута означает, что интерфейс поднят, но операционная система роутера не знает, что через него нужно что-то отправлять. Отдельно стоит проверить файрвол: часто forwarding-цепочка между интерфейсом туннеля и LAN-зоной либо не создана автоматически, либо блокируется правилом по умолчанию.

Последняя типичная причина — DNS. Если DNS-запросы уходят не через туннель или резолвятся в адреса, недоступные из туннеля, браузер будет показывать ошибку, даже если сам туннель полностью исправен. Пропишите DNS-сервер, доступный внутри туннеля, или используйте публичный DNS, к которому есть доступ через тот же маршрут, что и весь остальной трафик.

1. 1Проверьте AllowedIPs на клиенте и на сервере для конкретного пира
2. 2Убедитесь, что в таблице маршрутов роутера есть маршрут через интерфейс awg0/wg0
3. 3Проверьте forwarding-правила файрвола между зоной туннеля и LAN
4. 4Пропишите рабочий DNS-сервер, доступный из туннеля
5. 5Проверьте MTU интерфейса — заниженный MTU может фрагментировать пакеты и обрывать HTTPS

# Проверка таблицы маршрутов (OpenWrt/Linux)
ip route show table all | grep awg0

# Проверка форвардинга и NAT на MikroTik
/ip firewall filter print where chain=forward
/ip firewall nat print where chain=srcnat

Туннель периодически рвётся

Если соединение работает, но раз в несколько минут или часов пропадает и восстанавливается само, ищите причину в трёх местах: persistent keepalive, смене внешнего IP-адреса на одной из сторон и нагрузке на процессор роутера. Такое поведение особенно характерно для мобильного интернета и динамических IP у домашних провайдеров.

Persistent keepalive — это интервал в секундах, с которым клиент отправляет пустой пакет для поддержания NAT-сессии открытой. Если он не задан или задан слишком большим, NAT на промежуточном оборудовании закрывает сессию после периода неактивности, и следующий пакет уже не проходит, пока не случится новое согласование. Рекомендуемое значение — 25 секунд для соединений через мобильные сети и NAT с агрессивным таймаутом.

Смена внешнего IP-адреса на стороне клиента или сервера обрывает существующую сессию, потому что WireGuard и AmneziaWG привязывают сессию к конкретному сокету. Обычно протокол сам переустанавливает соединение при следующем handshake, но если это происходит слишком часто — раз в несколько минут, — стоит проверить настройки DHCP-lease у провайдера или наличие балансировки нагрузки между несколькими WAN-каналами на роутере.

Нагрузка на процессор — менее очевидная причина, но она реальна для бюджетных роутеров, где обфускация AmneziaWG требует больше вычислительных ресурсов, чем классический WireGuard. Если во время просмотра видео или скачивания файлов туннель рвётся, а в состоянии покоя работает стабильно, посмотрите загрузку CPU в веб-интерфейсе роутера в момент проблемы.

1. 1Установите PersistentKeepalive = 25 в конфигурации клиента
2. 2Проверьте историю смены внешнего IP на обеих сторонах (логи DHCP/PPPoE)
3. 3Отслеживайте загрузку CPU роутера при высокой нагрузке на туннель
4. 4На слабом железе снизьте битность шифрования или уменьшите число одновременных потоков

Чтение логов на разных прошивках

Формат диагностических сообщений сильно различается между платформами, и без знания, где смотреть, легко потратить время впустую. На OpenWrt логи демона можно посмотреть через `logread`, а более подробную отладку интерфейса — включив временный debug-режим модуля ядра WireGuard. На Keenetic диагностическая информация выводится в веб-интерфейсе в разделе журнала системы, где события туннеля помечены отдельным тегом.

На MikroTik основной источник — системный лог, доступный в разделе Log консоли RouterOS, куда можно добавить фильтр по топику wireguard, если он поддерживается версией прошивки. Стоит помнить, что в RouterOS до версии 7.x поддержка WireGuard была экспериментальной и часть диагностических сообщений там попросту отсутствует.

Общее правило для всех платформ: сначала смотрите на факт наличия handshake, затем на счётчики переданных и полученных байт для конкретного пира. Если счётчик transfer постоянно растёт в обе стороны, но пользователь всё равно жалуется на отсутствие интернета, проблема гарантированно на уровне маршрутизации или DNS, а не в самом туннеле.

# OpenWrt: последние записи системного лога, отфильтрованные по awg
logread | grep -i awg | tail -n 40

# MikroTik: лог с фильтром по топику
/log print where topics~"wireguard"

Краткий чек-лист диагностики

Если вы только начинаете разбор проблемы и не хотите читать все разделы подряд, используйте этот чек-лист как отправную точку. Пройдите его сверху вниз, и в 90% случаев причина найдётся уже на втором-третьем пункте.

Чек-лист не заменяет полную диагностику, но экономит время на очевидных ошибках вроде опечатки в ключе или закрытого порта. После прохождения списка, если проблема не решена, возвращайтесь к соответствующему разделу статьи для более глубокого разбора.

1. 1Handshake есть? Если нет — проверьте endpoint, порт, ключи, время, CGNAT
2. 2AllowedIPs покрывает нужный трафик на обеих сторонах?
3. 3Есть маршрут через интерфейс туннеля в таблице маршрутов роутера?
4. 4Файрвол разрешает forwarding между зоной туннеля и LAN?
5. 5DNS настроен и доступен из туннеля?
6. 6PersistentKeepalive выставлен, если клиент за NAT или на мобильной сети?