Wireguard внезапно прекращает обмен ключами — смена порта (только его) решает проблему на несколько недель.

Конфигурация сети огромная. Допустим, что wg-сервер находится в датацентре с статическим IP, а клиент — за CGNAT. Всё работает отлично до того момента, когда начинает появляться ошибка «Handshake for peer did not complete after 5 seconds, retrying (try 2)». Сервер слушает порт 13108, и всё нормально пока не появляется ошибка, после которой рукопожатие прекращается. Я вижу, что пакеты приходят на этот порт с правильного IP, но ошибка всё равно появляется. Тогда я делаю dst-nat с порта 23108 udp на целевой порт 13108. Как только я меняю порт у клиента на 23108, всё снова начинает работать... но спустя несколько дней проблема возникает и на порту 23108. Тогда я просто меняю обратно порт у клиента на 13108, и сразу же всё начинает работать и проходить рукопожатие. И так по кругу — клиент снова звонит и говорит, что VPN не работает. Такая ситуация возникает не у одного клиента, а примерно в 10 разных настройках. Некоторые я переключил обратно на l2tp, потому что эта история уже порядком меня раздражает. Я пытался отключать и включать оба пира и интерфейсы wg, чистить сетевые соединения на обеих сторонах — результата нет. В остальном этот проклятый wg работает как часы!

Какая версия RoS стоит на роутере? Это ошибка похожа на эту… http://forum.mikrotik.com/t/weird-wireguard-issue/176028/1

Ты уверен, что сеть между двумя пирингами WG действительно настолько прозрачна, как тебе хотелось бы? То есть, что единственное, что влияет на пакеты — это CG NAT на стороне «клиента»? Я могу представить себе какого-нибудь оператора, который по каким-то причинам разрывает все долгосрочные соединения: 1) просто потому что может; 2) потому что такие соединения кажутся им «подозрительными», ну, типа, убережём пользователей от взлома; 3) потому что правительственная организация приказала; и так далее. У одного провайдера в моей стране, который до сих пор раздаёт интернет по PPPoE, было, и есть, привычкой каждую ночь сбрасывать PPPoE-соединение, чтобы заставить клиента получить новый IP-адрес. Потому что статический IP — либо функция бизнес-услуги, либо предоставляется домашним клиентам за дополнительную плату…

Это называется постоянное поддержание соединения.

Gotsprings, это на роутере (клиентский пир для рукопожатия)??

Зачем вам, чтобы роутер MT (сервер для пира) следил за клиентским пиром, который находится за CGNAT???

Сначала я тоже думал, что проблемы у провайдера, но проверил входящий трафик на “сервере” wireguard и увидел, что трафик идёт на тот самый порт, и если отключить клиентский wireguard, он перестаёт идти. Разве что провайдер как-то модифицирует пакеты по пути до назначения, что было бы очень странно. Но да, я сталкиваюсь именно с этой проблемой: пока не сменишь порт, рукопожатия не происходит. Лишь в 1 из 10 случаев (или реже) перезапуск пира “решает” проблему.

Только что разбирался с похожей проблемой. Центральный RB5009 с несколькими WG-пирами, на AC3 в 250 км от него соединение WG внезапно упало несколько дней назад. Все остальные пиры на этом RB5009 продолжают работать. И RB5009, и AC3 работают на версии 7.15.1. Это соединение WG используется только для управления, от пользователей никаких сигналов о проблемах на этом объекте нет (иначе я бы знал раньше). При заходе на этот AC3 (там есть ещё один туннель с этого устройства через IPSEC в Azure, оттуда тоже могу зайти), никак не получается восстановить соединение WG, кроме как отключить порт прослушивания в настройках интерфейса (на удалённом пире ??) и включить его обратно (что само по себе бессмысленно, ведь для этой настройки соединение исходящее). И после этого трафик снова начинает идти... Наверное, можно было бы просто перезапустить устройство, но оно довольно нагружено, так что не могу делать это в рабочее время. Кто-нибудь создавал тикет в поддержку по этому поводу? Я собираюсь настроить дополнительный мониторинг и оповещения, чтобы быть в курсе такой проблемы на устройстве раньше.