+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Уточнение по работе Wireguard peer responder

Уточнение по работе Wireguard peer responder, RouterOS

bp0

Guest

28.09.2024 13:40:00

Я заметил в примечаниях к версии 7.17beta2: *) wireguard — не инициировать рукопожатие, если пир настроен как респондер; Это здорово, но меня смущает формулировка в документации: (https://help.mikrotik.com/docs/display/ROS/WireGuard#WireGuard-Peers)

Похоже, в 7.17 произошла ещё не задокументированная смена названия «is-responder» на «responder», так что я буду использовать «responder». Я не понимаю, какой именно пир должен быть установлен как responder. Кажется, что роуминг-пир — это «инициатор», ведь именно он всегда знает адрес конечной точки сервера, верно? Значит, в записи пира на роуминговом устройстве сервера должно быть responder=yes? Тогда как это подсказывает серверу не логировать ошибки при попытках связаться с роуминговым устройством по последнему известному адресу? Может, responder=yes должен быть у сервера в отношении роумингового пира? Мне кажется, если это так, то смысл терминов теряется. Думаю, правильный вариант — второй, и термин responder на самом деле относится не к пиру, а к устройству, на котором настроена конфигурация, хотя находится в настройках пира. Было бы здорово, если бы это прояснили, хотя бы примером в документации. Если уж в 7.17 меняют название, может, стоит назвать это respond-only или как-то так.

Guscht

Guest

03.11.2024 22:48:00

Мне всё ещё непонятно, с какой стороны и в каком описании peer ставить responder=yes? Допустим, у меня есть центральный роутер со статическим IP, который должен выступать как сервер — «responder». И есть несколько «дальних бойцов» с динамическими IP, которые обязательно должны инициировать соединение. Нужно ли ставить responder=yes на «сервере» (роутере со статикой) и в описании peer для устройств «дальних бойцов» с динамическими IP? Или же ставить это на устройстве «дального бойца» и там же в описании peer для «сервера»? Документацию можно понять по-разному. И даже в лабораторных условиях, когда на обеих сторонах стоит responder=yes, туннель успешно устанавливается (v7.16.1).

mantouboji Guest	#3 0 04.11.2024 04:53:00 Да, роуминг должен быть отмечен как «ответчик».

marekm Guest	#4 0 04.11.2024 18:08:00 Ты уверен? Насколько я понимаю, всё наоборот — роуминг/клиент/дальний пользователь (возможно с динамическим IP и/или за NAT) выступает инициатором, а сервер (с публичным IP) — ответчиком, так?

anav

Guest

04.11.2024 18:49:00

В обычном WireGuard указывать responder не нужно. Этот термин должен использоваться только в BTH, если он оттуда вообще берётся. Согласно документации, все дополнительные поля, которые обычно не применяются… нужны для клиент-серверной конфигурации, когда настройки импортируются через QR-код для клиента — детали конфигурации на вкладке с QR-кодом появятся, как только будут заполнены соответствующие поля. Так как я не пользуюсь BTH и QR-кодами, эти термины для меня чужие.

Согласно документации: responder (yes | no; по умолчанию: no) → указывает, является ли пир инициатором подключения или только ответчиком. Его следует использовать на устройствах WireGuard, которые выступают в роли «серверов», к которым подключаются другие устройства-клиенты. В противном случае роутер будет постоянно пытаться подключиться к «endpoint-address» или «current-endpoint-address». На мой взгляд, это значит, что ответчик должен быть установлен на YES только в настройках разрешённых IP-адресов на клиентских устройствах при описании пир-сервер-роутера. Никогда нельзя использовать этот параметр на сервере, чтобы описать клиентские устройства. Иными словами, это логически совпадает с функцией persistent keep-alive.

marekm

Guest

04.11.2024 19:15:00

Возможно, это немного сбивает с толку, поэтому полезно было бы привести несколько примеров (с чёткой отметкой, кто есть кто). Я понимаю, что цель этой настройки — чтобы сервер не пытался бесконечно переподключиться к клиенту, который уже ушёл (отключился, сменил IP-адрес, находится за NAT и поэтому снаружи недоступен, то есть первым должен подключаться именно клиент).

anav

Guest

04.11.2024 19:21:00

Почему сервер продолжает пытаться связаться с клиентом, если его уже нет? Может быть какая-то попытка установить связь, чтобы, скажем, передать новый WANIP в обычном WireGuard, но в BTH управляющей сущностью является облачный релей WireGuard. Если обе стороны не общаются с релеем, соединение разрывается. Сервер не должен инициировать какой-либо трафик. Я не говорю, что ты не прав, просто не вижу другого объяснения.

mantouboji

Guest

05.11.2024 08:42:00

Как-то я поставил responder=no для одного из моих пиров (это iPhone, который иногда подключается к моему AX3). В логах AX3 появилось такое сообщение: 2024-11-05 16:28:36 wireguard, info wg3: [ZhY] xxxxxxxxxxxxxxxxxxxw=: Handshake for peer did not complete after 20 attempts, giving up. Затем я снова поставил responder=yes, и сообщение исчезло. Согласно официальной документации, я думаю, что этот iPhone в режиме роуминга всегда выступает инициатором подключения, поэтому его стоит помечать как responder.

anav Guest	#9 0 05.11.2024 11:59:00 Ну тогда, всё очень запутанно… в этом мы можем согласиться.

Sidewalker Guest	#10 0 28.05.2025 13:15:00 Короче: параметр «responder» скорее стоило назвать «Только отвечать» (или «Отвечать только этому пиру» или «Не инициировать соединение с этим пиром, только отвечать»). Его можно установить (а на самом деле изменить с дефолтного «Не только отвечать») в конфигурации пира (например, смартфона) в настройках устройства-сервера (скажем, роутера) [если конфигурация не совсем пир-к-пиру, а пир-к-серверу] [и для каждого пира надо настраивать отдельно, то есть включать «да» индивидуально для каждого пира, где это нужно] [и, насколько я знаю, можно поставить «да» не для всех пиров из списка]. bp0, не мог бы ты пометить тему как [РЕШЕНО], если последнее сообщение mantouboji (или это моё) решает загадку с MikroTik?

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры