4.1: резолвинг конечных точек в Wireguard

dimon27254 · December 29, 2023

Поздравляю всех с наступающим Новым годом!

Мне потребовалось связать два Кинетика с помощью Wireguard-туннеля.
В роли сервера выступает KN-3610 с доменом KeenDNS и динамическим белым IP-адресом. Клиентом является KN-3010, на котором в качестве конечной точки указан домен сервера.

На KN-3610 периодически меняется IP. Чтобы KN-3010 не терял связь в такой ситуации, создал профиль ping-check, в котором указан внутренний адрес сервера для постоянной проверки. Профиль назначен для Wireguard-интерфейса с параметром restart.

Когда сервер перестает отвечать на ping из-за смены внешнего IP, на клиенте автоматически перезапускается Wireguard-интерфейс. В таком случае происходит повторный резолвинг конечной точки, после чего соединение с сервером идет уже по новому IP-адресу.

На KeeneticOS 4.0 и более ранних версиях эта "схема" корректно отрабатывала. В 4.1 же обнаружил, что клиент после перезапуска интерфейса продолжает использовать "старый" IP-адрес конечной точки. Перезапуск интернет-соединения, ручной перезапуск интерфейса (в том числе, выключение на некоторое время и затем повторное включение) не исправляет ситуацию.
Туннель возможно вернуть "в строй", если изменить любую настройку в Wireguard-интерфейсе, или же полностью перезагрузить KN-3010.

Теперь конечная точка туннеля будет резолвиться системой однократно за весь период работы, или это баг? Было бы неплохо, чтобы резолвинг выполнялся при каждом запуске Wireguard-интерфейса, как раньше.

При наличии статического IP на сервере, разумеется, не было бы и проблемы, но перейти на статику нет возможности.

Скрытым сообщением прикрепил self-test с клиента на 4.0.7 и 4.1 Beta 2.

SySOPik · December 29, 2023

А создать keendns имя типа firma.keenetic.pro на сервере и прописать его в клиенте, вместо IP адреса не?

Edited December 29, 2023 by SySOPik

dimon27254 · December 29, 2023

8 минут назад, SySOPik сказал:

А создать keendns имя типа firma.keenetic.pro на сервере и прописать его в клиенте, вместо IP адреса не?

Именно так у меня и настроено:

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

Клиентом является KN-3010, на котором в качестве конечной точки указан домен сервера.

На сервере имеется домен вида *.keenetic.link, а на клиенте этот же домен прописан в конечной точке.

SySOPik · December 29, 2023

Тогда в чем проблема? На кинетике сервере меняется IP, keendns обновляется, клиент переподключится автоматически. Ну да несколько минут не будет связи, но то вполне адекватно.

dimon27254 · December 29, 2023

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

Тогда в чем проблема? На кинетике сервере меняется IP, keendns обновляется, клиент переподключится автоматически. Ну да несколько минут не будет связи, но то вполне адекватно.

Потеря связи на несколько минут вообще не проблема.

В моем случае без привязки профиля ping-check клиент продолжает "стучаться" на старый адрес, пока Wireguard-интерфейс не будет перезапущен. После перезапуска системой выполняется повторный резолвинг домена и подключение идет по новому IP. Так работает на KeeneticOS 4.0 и ниже.

На KeeneticOS 4.1 система резолвит домен однократно, при первом запуске интерфейса или после изменения его настроек. Далее, сколько угодно раз можно выключать-включать интерфейс, IP-адрес конечной точки остается от первого резолвинга, повторно эта операция не выполняется. В итоге, клиент никогда не "достучится" до сервера, т.к. IP остается старый и не обновляется

SySOPik · December 30, 2023

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

В моем случае без привязки профиля ping-check клиент продолжает "стучаться" на старый адрес, пока Wireguard-интерфейс не будет перезапущен.....

можно выключать-включать интерфейс, IP-адрес конечной точки остается от первого резолвинга, повторно эта операция не выполняется

Странно, у меня белый адрес на интерфейсе провайдера, Keendns нормально на него резолвит. В случае смены адреса на другой IP, через несколько минут Keendns опросит и подхватит другой адрес и уже резолвится на него. WG автоматически восстанавливает коннект и без пинг чека на внутрение адреса. В принципе все DynDNS так и работают.

Я так понял, в даном случае на Keendns висит старая IP, он не обновляет на новую? Потому WG стучится на xxxxx.keenetic.pro и попадает на старую IP? Надо в ТП узнавать, в чем проблема, смотреть настройки.

Edited December 30, 2023 by SySOPik

dimon27254 · December 30, 2023

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

Странно, у меня белый адрес на интерфейсе провайдера, Keendns нормально на него резолвит. В случае смены адреса на другой IP, через несколько минут Keendns опросит и подхватит другой адрес и уже резолвится на него. WG автоматически восстанавливает коннект и без пинг чека на внутрение адреса. В принципе все DynDNS так и работают.

Я так понял, в даном случае на Keendns висит старая IP, он не обновляет на новую? Потому WG стучится на xxxxx.keenetic.pro и попадает на старую IP? Надо в ТП узнавать, в чем проблема, смотреть настройки.

У вас трафик в туннеле идет непрерывно, т.е. имеется постоянная активность? Клиент имеет белый или серый адрес?

У меня активность туннеля большую часть времени поддерживается лишь с помощью keepalive-пакетов, которые клиент посылает серверу.

К работе KeenDNS вопросов нет - он корректно отрабатывает смену IP, т.к. уже через пару минут веб-интерфейс сервера становится снова доступен из интернета, а nslookup для домена показывает новый IP. Причем, эту проверку я провожу на устройстве, находящемся в локальной сети KN-3010. То есть, встроенный dns-proxy этого Кинетика уже знает новый IP и отдает его клиентам.

В 4.1 при первом запуске Wireguard или изменении его настроек, происходит резолвинг и определение IP-адреса конечной точки:

ndm: Wireguard::Interface: "Wireguard2": resolved peer "*" endpoint to "ip_сервера". 
ndm: Network::Interface::EndpointTracker: "Wireguard2": "*": remote endpoint is "ip_сервера". 
ndm: Network::Interface::EndpointTracker: "Wireguard2": "*": connecting via "PPPoE0" (PPPoE0). 
ndm: Network::Interface::EndpointTracker: "Wireguard2": "*": local endpoint is "внешний_ip_клиента".

При перезапуске Wireguard не появляется запись вида "resolved peer", продолжается использование ранее полученного IP без повторного резолвинга:

kernel: wireguard: Wireguard2: peer "*" (15) (старый_ip_сервера:порт) destroyed
ndm: Network::Interface::EndpointTracker: "Wireguard2": "*": remote endpoint is "старый_ip_сервера". 
ndm: Network::Interface::EndpointTracker: "Wireguard2": "*": connecting via "PPPoE0" (PPPoE0). 
ndm: Network::Interface::EndpointTracker: "Wireguard2": "*": local endpoint is "внешний_ip_клиента". 
kernel: wireguard: Wireguard2: peer "*" (16) created
kernel: wireguard: Wireguard2: handshake for peer "*" (16) (старый_ip_сервера:порт) did not complete after 2164841720 seconds, retrying (try 5)

Далее лог забивается записями о неудачных попытках завершения хэндшейка.

В 4.0 и более ранних резолвинг происходит при каждом запуске Wireguard:

kernel: wireguard: Wireguard2: peer "*" (11) (старый_ip_сервера:порт) destroyed
kernel: wireguard: Wireguard2: peer "*" (12) created
ndm: Wireguard::Interface: "Wireguard2": added a host route to peer "*" (новый_ip_сервера) via PPPoE0 (PPPoE0). 
ndm: Wireguard::Interface: "Wireguard2": peer "*" went offline, update configuration. 
kernel: wireguard: Wireguard2: handshake for peer "*" (12) (новый_ip_сервера:порт) did not complete after 5 seconds, retrying (try 2)

Затем туннель поднимается и все работает корректно.

Edited December 30, 2023 by dimon27254

SySOPik · December 30, 2023

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

У вас трафик в туннеле идет непрерывно, т.е. имеется постоянная активность? Клиент имеет белый или серый адрес?

В туннеле несколько клиентов. Трафик периодический. Обрывов туннеля нету. Клиенты и с белым и с серыми адресами.

11 минуту назад, dimon27254 сказал:

Далее лог забивается записями о неудачных попытках завершения хэндшейка.

Нужно смотреть настройки WG, скорей всего там где-то проблема. Мне не понятно: "ip_сервера" , "старый_ip_сервера", (новый_ip_сервера:порт) то внутренние адреса WG или внешние белые? Логи с клиента или сервера?

dimon27254 · December 30, 2023

48 минут назад, SySOPik сказал:

В туннеле несколько клиентов. Трафик периодический. Обрывов туннеля нету. Клиенты и с белым и с серыми адресами.

Не могли бы, пожалуйста, привести свои настройки сервера и одного из клиентов?

2 минуты назад, SySOPik сказал:

Нужно смотреть настройки WG, скорей всего там где-то проблема. Мне не понятно: "ip_сервера" , "старый_ip_сервера", (новый_ip_сервера:порт) то внутренние адреса WG или внешние белые? Логи с клиента или сервера?

ip_сервера - текущий внешний белый ip сервера,
новый_ip_сервера:порт - новый внешний ip сервера и порт,
старый_ip_сервера - старый внешний ip сервера.

Лог приводил с клиента.

Настройки довольно стандартные. Сервер:

interface Wireguard1
    description Server
    security-level public
    ip address 172.16.21.1 255.255.255.0
    ip mtu 1324
    ip access-group _WEBADMIN_Wireguard1 in
    ip tcp adjust-mss pmtu
    wireguard listen-port 54321
    wireguard peer публичный_ключ_клиента !client
        allow-ips 172.16.21.2 255.255.255.255
        allow-ips удаленная_подсеть_на_клиенте 255.255.255.0
        connect
    !
    up
!

Клиент:

interface Wireguard2
    description Client
    security-level public
    ip address 172.16.21.2 255.255.255.0
    ip mtu 1324
    ip access-group _WEBADMIN_Wireguard2 in
    ip tcp adjust-mss pmtu
    wireguard peer публичный_ключ_сервера !server
        endpoint *.keenetic.link:54321
        keepalive-interval 24
        allow-ips 172.16.21.1 255.255.255.255
        allow-ips удаленная_подсеть_на_сервере 255.255.255.0
        connect
    !
    up
!

Другой вариант - клиент с использованием ping-check:

ping-check profile WG
    host 172.16.21.1
    update-interval 30
    mode icmp
    max-fails 5
    timeout 5
!
interface Wireguard2
    description Client
    security-level public
    ip address 172.16.21.2 255.255.255.0
    ip mtu 1324
    ip access-group _WEBADMIN_Wireguard2 in
    ip tcp adjust-mss pmtu
    ping-check profile WG
    ping-check restart
    wireguard peer публичный_ключ_сервера !server
        endpoint *.keenetic.link:54321
        keepalive-interval 24
        allow-ips 172.16.21.1 255.255.255.255
        allow-ips удаленная_подсеть_на_сервере 255.255.255.0
        connect
    !
    up
!

удаленная_подсеть_на_клиенте - сегмент "домашняя сеть" на KN-3010,
удаленная_подсеть_на_сервере - сегмент "домашняя сеть" на KN-3610.

SySOPik · December 30, 2023

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

!
interface Wireguard0
description WG-Central
security-level public
ip address 172.16.1.1 255.255.255.0
ip mtu 1324
ip access-group _WEBADMIN_Wireguard0 in
ip tcp adjust-mss pmtu
wireguard listen-port 10001
wireguard peer xxxxxxxxxxxxxxxxxxxxxxxxx= !client
allow-ips 172.16.1.2 255.255.255.255
allow-ips 192.168.11.0 255.255.255.0
!
wireguard peer xxxxxxxxxxxxxxxxxxxxxxxxx= !client2
allow-ips 172.16.1.3 255.255.255.255
allow-ips 192.168.12.0 255.255.255.0
!
wireguard peer xxxxxxxxxxxxxxxxxxxxxxxxx= !client3
allow-ips 172.16.1.4 255.255.255.255
allow-ips 192.168.13.0 255.255.255.0

!
up

!
interface Wireguard0
description WG-Client
security-level public
ip address 172.16.1.2 255.255.255.0
ip mtu 1324
ip access-group _WEBADMIN_Wireguard0 in
ip tcp adjust-mss pmtu
wireguard peer xxxxxxxxxxxxxxxxxxxxxxxxxxx= !Central
endpoint firma.keenetic.pro:10001
keepalive-interval 30
allow-ips 172.16.1.1 255.255.255.255
allow-ips 10.10.10.0 255.255.255.0
!
up

dimon27254 · December 30, 2023

@SySOPik конфигурация, по сути, идентична моей. Какая версия KeeneticOS используется на клиентах?

SySOPik · December 30, 2023

4.0.7 на всем, 4.1 не использую, но я сомневаюсь что дело в "сломаном" WG в бете. У меня нет потерь связи даже без пингчека на внутренние адреса.

Edited December 30, 2023 by SySOPik

vasek00 · December 31, 2023

В 29.12.2023 в 17:36, dimon27254 сказал:

На KeeneticOS 4.0 и более ранних версиях эта "схема" корректно отрабатывала. В 4.1 же обнаружил, что клиент после перезапуска интерфейса продолжает использовать "старый" IP-адрес конечной точки. Перезапуск интернет-соединения, ручной перезапуск интерфейса (в том числе, выключение на некоторое время и затем повторное включение) не исправляет ситуацию.
Туннель возможно вернуть "в строй", если изменить любую настройку в Wireguard-интерфейсе, или же полностью перезагрузить KN-3010.

Теперь конечная точка туннеля будет резолвиться системой однократно за весь период работы, или это баг? Было бы неплохо, чтобы резолвинг выполнялся при каждом запуске Wireguard-интерфейса, как раньше.

Ранее для поднятия тоннеля WG (на клиенте) использовался стат маршрут ДО СЕРВЕРА, т.е. например

default dev ppp0  scope link 
162.159.193.9 dev ppp0  scope link

где 162.159.193.9 адрес сервера WG до которого будет туннель (т.е. если нет туннеля то и нет данного стат маршрута, вкл WG вновь создавала маршрут). При endpoint мнемоникой получаем сначала определение IP потом стат.маршрут.

Сейчас 4.1 этого стат маршрута нет, так как появилась привязка к интерфейсу "connect via ИНТЕРФЕЙС" - и тут чуток под другому, маршрут до сервера лежит теперь в созданной таблице маршрутизации в которой указан default и через какой ИНТЕРФЕЙС -> до него достучатся.

Поэтому думаю у вас (так же проверил на связке двух роутеров при указании endpoint) если "endpoint хххх.keenetic.pro:65101" то получаем

...
                "local": "ххх.ххх.ххх.ххх",   	********************
                "local-port": 65101,
                "via": "GigabitEthernet1",
                "remote": "2хх.ххх.ххх.ххх", 	********* определила endpoint
                "remote-port": 65101,
...

и данный "remote": "2хх.ххх.ххх.ххх" будет висеть до упора, reset interface не поможет, только пере сохранение настроек конф WG сменит "remote": "1хх.ххх.ххх.ххх"

Возможно разработчики обратят на это внимание - при reset интерфейсе переопределить endpoint.

GeodE · January 25

4.1 beta 3, подтверждаю проблему, сегодня с этим столкнулся - сменился ip на "сервере" и коннекта не было до тех пор, пока не пересохранил конфиг на "клиенте". Несмотря на то, что подключение идёт по домену ****.keenetic.name

dimon27254 · February 12

В 4.1 Beta 4 поведение сохраняется.

@hellonow @Le ecureuil

tkost · March 14

Та же проблема. 4.1.1 также, при смене айпи сервера кинетик продолжает стучаться по старому адресу. Домен не кинетик, так как сервер openwrt.

dimon27254 · March 20

@hellonow в 4.1.2 поведение аналогично.

Свежий self-test не требуется?

dimon27254 · March 20

@hellonow прикрепил.

hellonow · March 20

@dimon27254 включите пожалуйста debug режим на Wireguard интерфейсе, пример:

interface Wireguard0
debug
exit
system configuration save

Далее еще раз скачайте self-test файл в момент воспроизведения ситуации и прикрепите файл сюда.

Le ecureuil · March 27

Перерезолв поправлен, будет в новой 4.2 и 4.1.4.

dimon27254 · March 30

@Le ecureuil @hellonow подтверждаю исправление в 4.2 Alpha 2. Спасибо!

Sign In

4.1: резолвинг конечных точек в Wireguard

Question

Link to comment

Share on other sites

20 answers to this question

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Recently Browsing 0 members