Периодически отваливается VPN‐соединение через Wireguard

FLK · 22 августа

Только что, avn сказал:
На 4.2.3 можно будет попробовать client_id прописать.
interface Wireguard2 wireguard peer bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo= client-id send 1234567

Можно для менее просвещенных что это нам даст?)))

avn · 22 августа

Только что, FLK сказал:

Можно для менее просвещенных что это нам даст?)))

Стандартный WARP клиент client_id всегда отправляет. А мы нет...

FLK · 22 августа

1 минуту назад, avn сказал:

Стандартный WARP клиент client_id всегда отправляет. А мы нет...

Вытекает второй вопрос - где его взять?)

avn · 22 августа

3 минуты назад, FLK сказал:

Вытекает второй вопрос - где его взять?)

Так при генерации конфигурации его выдают.

Скрытый текст

curl -4s --interface $WGCFIF --connect-timeout 2 "https://api.cloudflareclient.com/v0a884/reg/$DEVICE_ID" -H "User-Agent: okhttp/3.12.1" -H "Authorization: Bearer $ACCESS_TOKEN"

Или использовать китайские генераторы, они давно отдают client_id

Изменено 22 августа пользователем avn

Konstantine352 · 23 августа

Может кто направить как вернуть в работу?

Пока удалось только подменой первого пакета на винде заставить работать. Как это сделать с кинетика?

FLK · 23 августа

4 часа назад, Konstantine352 сказал:

Может кто направить как вернуть в работу?

Пока удалось только подменой первого пакета на винде заставить работать. Как это сделать с кинетика?

Мы все надеемся пока на лучшее, возможно что-то и можно будет вскоре сделать с этим

Le ecureuil · 23 августа

5 часов назад, Konstantine352 сказал:

Может кто направить как вернуть в работу?

Пока удалось только подменой первого пакета на винде заставить работать. Как это сделать с кинетика?

Что значит "подмена первого пакета"?

Leshiyart · 23 августа

8 часов назад, Konstantine352 сказал:

Может кто направить как вернуть в работу?

Пока удалось только подменой первого пакета на винде заставить работать. Как это сделать с кинетика?

прочитать чендж лог 4.2 и посмотреть соседние ветки про вг

Konstantine352 · 24 августа

14 часа назад, Leshiyart сказал:

прочитать чендж лог 4.2 и посмотреть соседние ветки про вг

Если вы про это "Параметры advanced security configuration (ASC) для WireGuard теперь доступны в интерфейсе командной строки", то не получается. Параметры ASC брал из клиента на винде. Команда применяется, туннель не поднимается ( Тут обсуждали.

Konstantine352 · 24 августа

17 часов назад, Le ecureuil сказал:

Что значит "подмена первого пакета"?

Кидаешь "мусор" по udp порту для WG в сторону сервера и потом уже включаешь туннель.

vasek00 · 24 августа

6 часов назад, Konstantine352 сказал:

Кидаешь "мусор" по udp порту для WG в сторону сервера и потом уже включаешь туннель.

типа

Скрытый текст

~ # nping --udp --count 10 --data-length 16 --source-port 23123 --dest-port 500 162.ххх.ххх.ххх

Starting Nping 0.7.95 ( https://nmap.org/nping ) at 2024-08-23 08:04 MSK
SENT (0.0427s) UDP 10.25.16.163:23123 > 162.ххх.ххх.ххх:500 ttl=64 id=17721 iplen=44
SENT (1.0436s) UDP 10.25.16.163:23123 > 162.ххх.ххх.ххх:500 ttl=64 id=17721 iplen=44
...

Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 10 (440B) | Rcvd: 0 (0B) | Lost: 10 (100.00%)
Nping done: 1 IP address pinged in 10.10 seconds

stefbarinov · 24 августа

Keenetic giga (KN-1010) - WG server, ISP Beeline. К нему цепляется клиент Keenetic Speedster (KN-3010) ISP Ростелеком. Раньше на обоих был поднят Warp и устройства ходили через Warp согласно политикам или маршрутам. На данный момент на KN-1010 Warp не работает, а на KN-3010 - работает прекрасно. Не получается зарулить трафик с KN-1010 на KN-3010 ни маршрутами, ни политиками (ходить в инет с сервера через клиента). Пробовал все известные мне настройки. При чем шлюз Warp на KN-3010 пингуется с KN-1010. Хочется ходить в youtube c устройств за WG сервером через Warp WG-клиента (KN-3010)

Изменено 24 августа пользователем stefbarinov

Konstantine352 · 25 августа

17 часов назад, stefbarinov сказал:

Keenetic giga (KN-1010) - WG server, ISP Beeline. К нему цепляется клиент Keenetic Speedster (KN-3010) ISP Ростелеком. Раньше на обоих был поднят Warp и устройства ходили через Warp согласно политикам или маршрутам. На данный момент на KN-1010 Warp не работает, а на KN-3010 - работает прекрасно. Не получается зарулить трафик с KN-1010 на KN-3010 ни маршрутами, ни политиками (ходить в инет с сервера через клиента). Пробовал все известные мне настройки. При чем шлюз Warp на KN-3010 пингуется с KN-1010. Хочется ходить в youtube c устройств за WG сервером через Warp WG-клиента (KN-3010)

что бы 3010 начал ходить через wg на 1010 надо:

на 3010 добавить маршрут (пока 1 для теста)

на 1010 включить NAT на интерфейсе клиента, а именно дать команду "ip nat Wireguard1", где ip Wireguard1 - это интерфейс, который строит туннель до 3010. (номер интерфейса может отличаться)

Изменено 25 августа пользователем Konstantine352

Le ecureuil · 26 августа

В 24.08.2024 в 11:14, vasek00 сказал:

типа

Скрыть содержимое

~ # nping --udp --count 10 --data-length 16 --source-port 23123 --dest-port 500 162.ххх.ххх.ххх

Starting Nping 0.7.95 ( https://nmap.org/nping ) at 2024-08-23 08:04 MSK
SENT (0.0427s) UDP 10.25.16.163:23123 > 162.ххх.ххх.ххх:500 ttl=64 id=17721 iplen=44
SENT (1.0436s) UDP 10.25.16.163:23123 > 162.ххх.ххх.ххх:500 ttl=64 id=17721 iplen=44
...

Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 10 (440B) | Rcvd: 0 (0B) | Lost: 10 (100.00%)
Nping done: 1 IP address pinged in 10.10 seconds

Так в ASC параметр JC ровно это и означает - сколько пакетов мусора послать перед первым "нормальным" handshake initiation.

vasek00 · 26 августа

2 часа назад, Le ecureuil сказал:

Так в ASC параметр JC ровно это и означает - сколько пакетов мусора послать перед первым "нормальным" handshake initiation.

Согласен.

В интернете было такое решение с

nping --udp --count 10 --data-length 16

Mikhail_YAR · 27 августа

Всем привет!

Подскажите плз, откуда начать диагностику? Роутеры Ультра (Билайн) и Старт (РТК) пытаюсь соединить туннелем по этой схеме. Но туннель не поднимается. Т.е. вообще ничего не происходит. На обоих концах 0 байт отправлено, 0 байт принято. Не пойму где косяк искать. В системном журнале на роутерах ничего особенного. На блок от провайдера не похоже...

stefbarinov · 27 августа

1 час назад, Mikhail_YAR сказал:

откуда начать диагностику?

Белый адрес на сервере?

Mikhail_YAR · 27 августа

25 минут назад, stefbarinov сказал:

Белый адрес на сервере?

Да, IP белый. Единственное что, я не настраивал маршруты в сети за туннелем, но вроде бы для поднятия туннеля это и не нужно. Как минимум, хэндшейк-то должен проходить.

stefbarinov · 27 августа

1 час назад, Mikhail_YAR сказал:

пытаюсь соединить туннелем по этой схеме

Скрытый текст

12 минуты назад, Mikhail_YAR сказал:

Единственное что, я не настраивал маршруты

Наверное всё получится, когда все пункты инструкции будут выполнены

Изменено 27 августа пользователем stefbarinov

Mikhail_YAR · 27 августа

6 минут назад, stefbarinov сказал:

Наверное всё получится, когда все пункты инструкции будут выполнены

Ох уж эта лень. Спасибо, буду пробовать)

Uncertainty · 4 сентября

Апну тему. Есть схема
Keenetic Air в качестве "Сервера" с белым IP-адресом.

Keenetic Speedster в качестве "Клиента".

Родное приложение WireGuard в виде ещё одного "Клиента".

Все это находится в одном регионе и даже в одном городе. По сути - связал 2 домашних сети по гайду в базе знаний Кинетика.

Туннель поднял, работает, стал периодами отваливаться намертво. После отвала просто "вкл/выкл" не помогает. Помогает только установка порта клиента вручную, т.е. в конфиге изначально прописан порт не был. Приходится руками прописывать любой свободный порт и туннель поднимается. Работает вплоть до того, как кончается активность. Keep-alive прописан (15) на стороне клиента. Баг замечен только на "клиенте" кинетике, клиент-приложение работает корректно и без отвалов. Куда копать, есть у кого идеи?

Изменено 4 сентября пользователем Uncertainty

Леонид Харламов · 4 сентября

Тоже проблема похожая, периодически отваливается, пока 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

Какие могут быть тому причины?

Изменено 4 сентября пользователем Леонид Харламов

Uncertainty · 4 сентября

У меня на клиенте такое есть
Куда копать - не понимаю : (

Сейчас снова отвал случился, сменил порт на клиенте - туннель поднялся.

wireguard: Wireguard1: handshake for peer "SERVER" (685) (x.x.x.x.x:yyyyy) did not complete after 2164841720 seconds, retrying (try 5)

x13 · 4 сентября

В 24.08.2024 в 12:14, vasek00 сказал:

типа

Скрыть содержимое

~ # nping --udp --count 10 --data-length 16 --source-port 23123 --dest-port 500 162.ххх.ххх.ххх

Starting Nping 0.7.95 ( https://nmap.org/nping ) at 2024-08-23 08:04 MSK
SENT (0.0427s) UDP 10.25.16.163:23123 > 162.ххх.ххх.ххх:500 ttl=64 id=17721 iplen=44
SENT (1.0436s) UDP 10.25.16.163:23123 > 162.ххх.ххх.ххх:500 ttl=64 id=17721 iplen=44
...

Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 10 (440B) | Rcvd: 0 (0B) | Lost: 10 (100.00%)
Nping done: 1 IP address pinged in 10.10 seconds

А как установить Nping на кинетик?

vasek00 · 5 сентября

4 часа назад, x13 сказал:

А как установить Nping на кинетик?

OPKG

~ # opkg list | grep nping
nping - 7.95-1 - Network packet generation tool / ping utility
nping-ssl - 7.95-1 - Nping (with OpenSSL support)
~ #

cheburashkaDDNS · 9 сентября

@Uncertainty какая версия прошивки у вас установлена на данный момент? заметил такое же поведение у себя после перехода на 4.2 Beta 3.

Le ecureuil · 9 сентября

В 04.09.2024 в 18:52, Леонид Харламов сказал:

Какие могут быть тому причины?

РКН?

ad1er · 9 сентября

Outline более стабильный. Есть ли возможность как-то поставить outline на роутер?

Леонид Харламов · 9 сентября

11 час назад, Le ecureuil сказал:

РКН?

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

Mamay · 10 сентября

15 часов назад, ad1er сказал:

Outline более стабильный. Есть ли возможность как-то поставить outline на роутер?

Периодически отваливается VPN‐соединение через Wireguard

Рекомендуемые сообщения

Топ авторов темы

Популярные дни

Топ авторов темы

Популярные дни

Популярные посты

Le ecureuil

IxoID

Le ecureuil

Изображения в теме

Присоединяйтесь к обсуждению

Последние посетители 0 пользователей онлайн

Важная информация