makerus

Проблема решилась. Для тех, у кого возможно будет такая же проблема. В моем случае были объединены устройства Keenetic Viva (KN-1912 ) и OC 300 / ER-605v2. Так вот, проблема была на стороне OC 300 / ER-605v2. Заключалась она в том, что порт WG был указан через PF (Port Forwarding), то есть был за NAT'ом и при неопределенных условиях - прекращал принимать пакеты по этому порту в туннель WG или же некорректно их обрабатывал. Соответственно пакеты из туннеля WG со стороны Keenetic Viva (KN-1912) не могли найти получателя и слали tcp retransmission. Как только я убрал порт WG из PF на стороне OC 300 / ER-605v2 - все заработало корректно.

Анисимов Сергей, а ты используешь одно и тоже подключение (пир) для всех устройств или для каждого устройства свой пир?

Если верить захвату пакетов, то никакие пакеты в таком случае не дойдут до локальной сети из-вне. Если интересно почему - причина NAT. Если пытаться пробрасывать порты, то они пробрасываются через NAT по-сути. Если это внутренняя сеть - все ок. Если внешняя - то у этих портов будет изоляция, они не будут видеть другие подсети с этих портов, в том числе и подсеть wg. То есть проблема изначально в механизме NAT преобразований, который изолирует устройства от других соединений, определенным способом, для безопасности сети. Чтобы ее туда пустить - нужен NAT, соответственно какой-нибудь DMZ, а DMZ сделает так, что изолирует уже не порт, а целый IP от других сетей. Поэтому в данном случае NAT можно настраивать до посинения, сам механизм NAT не даст такую возможность. На внешнем придется отрубать как раз NAT целиком, что как бы делает одну "большую дыру" и не факт, что даже такой метод заработает. Единственным адекватным методом для проброски порта наружу из внутренней сети вижу - поднятие прокси. Как это сделать? Вот несколько вариантов. 1. Создать виртуальную машину - на ней, через iptables, настроить DNAT на порты, которые нужны (не забудьте добавить маскарадинг). 2. Установить на отдельном устройстве Fedora Server и Cockpit, включить дополнение Podman, загрузить образ: docker.io/jc21/nginx-proxy-manager:latest, запустить контейнер с этим образом (https://nginxproxymanager.com/guide/#features), открыть дополнительно порты в докер-контейнере, через которые будете прокидывать прокси. В самом приложении, которое запустится использовать раздел stream, который будет проксировать запросы tcp/udp. 3. Установить на отдельном устройстве чистый linux дистрибутив и настроить его в соответствии с п.1 4. Использовать свой ПК, с ПО позволяющее проксировать запросы. 5. Как советовал savizor ps. Прокси ДОЛЖЕН находится в подсети БЕЛОГО IP. То есть ПО, которое будет куда-то проксировать в локальную сеть должно иметь ту-же подсеть, что и белый IP. Если белый IP находится в подсети 192.168.35.0/24, как в примере автора, то и прокси должен подниматься в этой же подсети и соответственно иметь адрес из этой подсети, например: 192.168.35.15. Если это отдельное устройство, которое используется для прокси (мини-пк, raspberry pi итд), то оно должно быть физически подключено к маршрутизатору у которого белый IP, чтобы физически находится в той же подсети и иметь к ней прямой доступ. Других вариантов, кроме проксирования, к сожалению, к такой конфигурации сети - нет.

Добрый день коллеги, уже 3 день заметна проблема - отваливается wireguard интерфейс. Ситуация такая. Именно подключение Wireguard не отваливается, оно продолжает гореть зеленым индикатором, кроме этого, трафик также проходит со стороны отправляющий устройств, это можно проверить через меню "Диагностика -> Захват сетевых пакетов", выбрав нужный интерфейс. Вроде бы все хорошо, но обратный трафик - умирает. Можно было бы списать на некорректную маршрутизацию, но если перезапустить маршрутизатор - обратный трафик появляется и само соединение работает корректно. Стоит лишь нагрузить немного соединение (wireguard) трафиком, например несколькими одновременными подключениями - все, приплыли, весь трафик умирает на маршрутизаторе и не возвращается обратно (источникам пакетов). Под возвращением я подразумеваю ответ тому устройству, с которого был отправлен пакет, он до него не доходит. Смотрел в логи - ничего не происходит. Кроме перезагрузки помогает просто подождать -нное количество минут, или выключение и включение интерфейса через -нное количество минут, тогда обратный трафик появляется снова и конечные устройства снова начинают получать ответы. В чем может быть проблема, в какую сторону следует копать? Версия 4.0.7.