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

[dimon27254]

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

Мне потребовалось связать два Кинетика с помощью 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]

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

Изменено 29 декабря, 2023 пользователем SySOPik

[dimon27254]

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

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

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

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

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

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

[SySOPik]

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

[dimon27254]

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

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

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

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

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

[SySOPik]

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

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

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

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

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

Изменено 30 декабря, 2023 пользователем SySOPik

[dimon27254]

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)

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

Изменено 30 декабря, 2023 пользователем dimon27254

[SySOPik]

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

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

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

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

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

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

[dimon27254]

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]

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

!
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]

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

[SySOPik]

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

Изменено 30 декабря, 2023 пользователем SySOPik

[vasek00]

В 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]

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

[dimon27254]

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

@hellonow @Le ecureuil

[tkost]

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

[dimon27254]

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

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

[dimon27254]

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

[hellonow]

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

 

interface Wireguard0
debug
exit
system configuration save

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

[Le ecureuil]

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

[dimon27254]

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