Леонид Харламов

У себя пока сделал скрипт wg.sh в Entware: #!/bin/sh let port=46001+$(date +%d)*$(date +%H)+$(date +%M) ndmc -c "interface Wireguard0 wireguard listen-port $port" и запускаю его через crond каждые 15 минут. Если связь теряется, то в течении 15 минут порт меняется и соединение восстанавливается. Не идеально конечно, но лучше чем вручную нажимать на удалённом роутере.

Добавил скрипт S5crond для автозапуска в /opt/etc/init.d: #!/bin/sh SCRIPT=/opt/sbin/crond PIDFILE=/opt/var/run/crond.pid ARGS="-b" start() { if [ -f $PIDFILE ] && kill -0 $(cat $PIDFILE); then echo 'Service crond is already running' >&2 return 1 fi $SCRIPT $ARGS echo 'Started crond service' } stop() { if [ ! -f "$PIDFILE" ] || ! kill -0 $(cat "$PIDFILE"); then echo 'Service crond is not running' >&2 return 1 fi echo 'Stopping crond service...' kill -15 $(cat "$PIDFILE") && rm -f "$PIDFILE" } status() { if [ -f $PIDFILE ] && kill -0 $(cat $PIDFILE); then echo 'Service crond is running' else echo 'Service crond is stopped' fi } case "$1" in start) start ;; stop) stop ;; status) status ;; restart) stop start ;; *) echo "Usage: $0 {start|stop|restart|status}" esac

Как настроить автозапуск крона после перезагрузки?

Спасибо! То что нужно.

Как-то можно выполнять команды настройки Keenetic OS из консоли BusyBox?

Отлично, потестим. А версия 4.02 это версия чего именно? Сейчас установлена KeeneticOS 4.1.7

Поменять локальный порт у клиента. Ну да, задать любой любой из верхнего диапазона... interface Wireguard0 wireguard listen-port xxx**

Сегодня проблема повторилась, туннель сразу же поднялся после смены порта на клиенте. Как вариант с помощью скрипта может быть можно периодически менять порт на клиенте? При проблеме количество принятых пакетов 0, если эту ситуацию как-то отлавливать и также менять номер порта?

Может и так, но почему тогда при ручном отключении-включении пира на клиенте всё снова начинает работать?

Тоже проблема похожая, периодически отваливается, пока 2 раза за почти месяц, первый раз восстановилось только после сохранения настроек пира на клиенте, второй раз вроде как само переподключилось через длительное время. Два кинетика, сервер с белым ip, клиент через 4g модем с серым. В момент когда была проблема обратил внимание что на сервере менялся счетчик и отправленных и полученных пакетов, а на клиенте были только отправленные - доступ в интернет в это время был на обоих кинетиках. В логах следующее: Лог на сервере: [I] Sep 4 15:52:53 kernel: wireguard: Wireguard0: sending handshake response to peer "**client**" (9) (bb.bb.112.144:27386) [I] Sep 4 15:52:58 kernel: wireguard: Wireguard0: receiving handshake initiation from peer "**client**" (9) (bb.bb.112.144:27386) [I] Sep 4 15:52:58 kernel: wireguard: Wireguard0: sending handshake response to peer "**client**" (9) (bb.bb.112.144:27386) [I] Sep 4 15:53:03 kernel: wireguard: Wireguard0: receiving handshake initiation from peer "**client**" (9) (bb.bb.112.144:27386) [I] Sep 4 15:53:03 kernel: wireguard: Wireguard0: sending handshake response to peer "**client**" (9) (bb.bb.112.144:27386) [I] Sep 4 15:53:08 kernel: wireguard: Wireguard0: receiving handshake initiation from peer "**client**" (9) (bb.bb.112.144:27386) [I] Sep 4 15:53:08 kernel: wireguard: Wireguard0: sending handshake response to peer "**client**" (9) (bb.bb.112.144:27386) [I] Sep 4 15:53:14 kernel: wireguard: Wireguard0: receiving handshake initiation from peer "**client**" (9) (bb.bb.112.144:27386) [I] Sep 4 15:53:14 kernel: wireguard: Wireguard0: sending handshake response to peer "**client**" (9) (bb.bb.112.144:27386) [I] Sep 4 15:53:19 kernel: wireguard: Wireguard0: receiving handshake initiation from peer "**client**" (9) (bb.bb.112.144:27386) [I] Sep 4 15:53:19 kernel: wireguard: Wireguard0: sending handshake response to peer "**client**" (9) (bb.bb.112.144:27386) [I] Sep 4 15:53:24 kernel: wireguard: Wireguard0: receiving handshake initiation from peer "**client**" (9) (bb.bb.112.144:27386) [I] Sep 4 15:53:24 kernel: wireguard: Wireguard0: sending handshake response to peer "**client**" (9) (bb.bb.112.144:27386) [I] Sep 4 15:53:30 kernel: wireguard: Wireguard0: receiving handshake initiation from peer "**client**" (9) (bb.bb.112.144:27386) [I] Sep 4 15:53:30 kernel: wireguard: Wireguard0: sending handshake response to peer "**client**" (9) (bb.bb.112.144:27386) [I] Sep 4 15:53:34 ndm: Network::Interface::Base: "Wireguard0": "wireguard" changed "link" layer state "pending" to "running". Лог на клиенте: [I] Sep 4 15:50:08 kernel: wireguard: Wireguard0: handshake for peer "**server**" (12) (aa.aa.231.158:16632) did not complete after 1 seconds, retrying (try 5) [I] Sep 4 15:50:13 kernel: wireguard: Wireguard0: handshake for peer "**server**" (12) (aa.aa.231.158:16632) did not complete after 2166848092 seconds, retrying (try 5) [I] Sep 4 15:50:19 kernel: wireguard: Wireguard0: handshake for peer "**server**" (12) (aa.aa.231.158:16632) did not complete after 2164854852 seconds, retrying (try 5) [I] Sep 4 15:51:01 kernel: Core::Syslog: last message repeated 146 times. [I] Sep 4 15:51:06 kernel: wireguard: Wireguard0: handshake for peer "**server**" (12) (aa.aa.231.158:16632) did not complete after 2166848092 seconds, retrying (try 5) [I] Sep 4 15:51:12 kernel: wireguard: Wireguard0: handshake for peer "**server**" (12) (aa.aa.231.158:16632) did not complete after 2164854852 seconds, retrying (try 5) [I] Sep 4 15:51:27 kernel: Core::Syslog: last message repeated 148 times. [I] Sep 4 15:51:33 kernel: wireguard: Wireguard0: handshake for peer "**server**" (12) (aa.aa.231.158:16632) did not complete after 2164854852 attempts, giving up [I] Sep 4 15:51:48 kernel: wireguard: Wireguard0: handshake for peer "**server**" (12) (aa.aa.231.158:16632) did not complete after 2164854852 seconds, retrying (try 5) [I] Sep 4 15:51:53 kernel: wireguard: Wireguard0: handshake for peer "**server**" (12) (aa.aa.231.158:16632) did not complete after 2164854852 seconds, retrying (try 5) [I] Sep 4 15:53:07 kernel: Core::Syslog: last message repeated 161 times. [I] Sep 4 15:53:12 kernel: wireguard: Wireguard0: handshake for peer "**server**" (12) (aa.aa.231.158:16632) did not complete after 1 seconds, retrying (try 5) [I] Sep 4 15:53:17 kernel: wireguard: Wireguard0: handshake for peer "**server**" (12) (aa.aa.231.158:16632) did not complete after 2164854852 seconds, retrying (try 5) [I] Sep 4 15:53:23 kernel: wireguard: Wireguard0: handshake for peer "**server**" (12) (aa.aa.231.158:16632) did not complete after 2164854852 seconds, retrying (try 5) [I] Sep 4 15:53:28 ndm: Network::Interface::Base: "Wireguard0": "wireguard" changed "link" layer state "pending" to "running". did not complete after 2164854852 seconds - странное какое-то количество секунд... На сервере "Проверка активности" - пусто, на клиенте - 15 Какие могут быть тому причины?

Поменял IPsec VPN сеть-сеть на WireGuard: Viva сервер, Giga клиент и добавил на роутере Viva: interface Wireguard0 security-level private ip nat Wireguard0 NAT заработал

Это скрин с роутера Router, здесь адрес источника из подсети 192.168.41.0/24, значит NAT на роутере Viva не используется для этих пакетов, иначе адрес источника изменился на 172.16.1.54

Пробовал так: ip nat 192.168.41.0 255.255.255.0 - но чёто не вышло как хотелось бы, пакеты на роутер Router по прежнему приходили с адреса 192.168.41.136

Схема сети во вложении... С ноутбука 192.168.41.136 обращаемся на моноблок 192.168.74.21. Всё работает, трассировка следующая: Это работает при условии что на роутере Router прописан маршрут до 192.168.41.0 через 172.16.1.54. Как настроить SNAT на роутере Viva, чтобы пакеты приходящие из 192.168.41.0/24 в сторону 192.168.74.0/24 натились, и исходящий адрес подменялся на 172.16.1.54 ? В части L2TP VPN-соединения, Viva - клиент, Router - сервер.

Да, там речь идёт про VPN-сервер L2TP/IPsec - он при подключении к нему VPN клиентов тоже не создаёт видимых интерфейсов, но при прописывании маршрута через ip адрес полученный клиентом показывает интерфейс L2TPVPN, а IKEv2/IPsec почему-то так не делает и ставит красную точку в таблице маршрутизации напротив адреса назначения.... У L2TP/IPsec есть такая настройка как "доступ к сети" и там домашняя сеть выбирается, что ограничивает прохождение трафика в другие направления, поэтому такой вариант не подошёл.