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

WINBOX 4 WIREGUARD — ПЕРЕСМОТРЕНО С НОВЫМ ВИДОМ

WINBOX 4 WIREGUARD — ПЕРЕСМОТРЕНО С НОВЫМ ВИДОМ, RouterOS

anav

Guest

20.03.2025 14:55:00

Когда я начал использовать Winbox4 и WireGuard, я понял, что программе предстоит большая работа! GUI, на мой взгляд, не особенно удобный, эффективный и интуитивно понятный. Всё сжато на одной странице, и приходится листать туда-сюда, чтобы найти нужную информацию для ввода, да и, конечно, в текущей реализации есть ошибки (например, с allowed IPs). Кроме того, кажется, что некоторые функции сделаны наполовину или вообще недоделаны (видимо, в разработке).

Например, на главной странице WireGuard есть функция импорта, но как понять, к какому интерфейсу это относится? Импортируется интерфейс WireGuard или пир? Если выбрать интерфейс, там нет функции импорта — а именно там она была бы полезна! Лично я пока не могу придумать нужду импортировать файлы прямо на роутере или устройстве MT, но, возможно, такие кейсы есть. Для меня это не приоритет. Ещё более странно, что при клике на интерфейс появляется функция экспорта. По сути, ты просто создаёшь имя файла и отправляешь его в меню FILES в Winbox. При этом нет возможности выбрать, какой именно пир экспортируется. Аналогично экспорту: как выбрать конкретного пира для выгрузки? Если MT всё ещё в разработке по этим моментам, сейчас самое время сесть и продумать: какие сценарии создания пиров самые распространённые и какая для этого нужна информация.

Вот как я себе это представляю. Единственное предположение — что сначала создан интерфейс WireGuard, а дальше всё логично следует из этого. Не стесняйтесь критиковать или дополнять — вместе сделаем лучше!

oskarsk Guest	#2 0 03.07.2025 04:10:00 Поделитесь своим мнением, сообщество. Кто-нибудь пользуется WireGuard и хотел бы что-то изменить или улучшить в интерфейсе пользователя?

anav

Guest

04.07.2025 17:53:00

Привет, Oskarsk! Помимо идеи добавить функцию/опцию «amnezia», вкратце… для любого, кто читает, эта ветка была создана, чтобы:
a. распознавать три основных типа подключений Wireguard
b. сделать конфигурацию максимально простой и удобной
c. автоматизировать процесс передачи конфигурации клиентам и так далее.

При попытке описать требования стало ясно, что три варианта настройки Wireguard включают:
- когда обе стороны генерируют приватные и публичные ключи (рутер MT и другие устройства — вручную)
- когда сторонний сервер предоставляет приватный ключ для обеих сторон (рутер MT — клиентское устройство)
- когда MT генерирует как приватные, так и публичные ключи для устройств (рутер MT — сервер, автоматическая настройка)

Нужно уметь определить любой экземпляр Wireguard в одном из этих трёх вариантов.

Отмечу, что это не заменяет BTH, который предназначен для другого случая — когда у роутера нет публичного IP, но всё равно хочется подключаться удалённо к локальным подсетям и/или настраивать свой роутер. Однако с использованием функционала, открытого в BTH (добавленного MT RoS), мы должны суметь создавать QR-коды или конфигурационные файлы с правильной информацией, особенно для СЛУЧАЯ 3!

Я не эксперт по интерфейсам, но мой первый вариант, по отзывам MT, был слишком сложным, поэтому последнее решение ориентировано в основном на одностраничную настройку, которую видит админ. Главное для простоты конфигурации Wireguard — максимально продумать логику.

Очевидно, что первый шаг — администратор создаёт Wireguard-интерфейс. Именно здесь, помимо названия, админ указывает MT, будет ли приватный ключ автоматически сгенерирован роутером MT (охватывает случай 1 и 3) или вводится вручную со стороны третьего устройства/провайдера (случай 2).

Другие опции интерфейса:
- По желанию можно указать IP-адрес и подсеть Wireguard здесь, чтобы не переключаться на /IP address.
- По умолчанию «Responder» ставится в «SELECTED», если выбрана авто-генерация (вероятно, MT — сервер), и это автоматически применяется ко всем клиентским пирами (нельзя изменить у пиров).
- Есть выбор ротации src-port (когда MT — клиент, чтобы избежать известных проблем — сбросы handshake).

Логика продолжается при добавлении нового пира. Первым шагом выбирается ИНТЕРФЕЙС (через выпадающее меню). Потом админ выбирает доступные опции. Если выбрана авто-генерация ключей, доступны как ручные, так и автоматические пиры. Если выбран ручной ввод ключа — доступен список Пиров от третьих сторон.

Самое интересное и новое — это автоматические пиры. Заимствуя из BTH, мы хотим облегчить администратору задачу предоставления уникальных приватно-публичных ключей для каждого устройства. Все они получат общий публичный ключ, сгенерированный роутером MT для одного Wireguard-интерфейса.

После заполнения обязательных данных для первого пира, для последующих (порт конечной точки, адрес и keep alive по умолчанию копируются с первого) стоит отметить, что роутер MT СЧИТЫВАЕТ IP-адрес интерфейса и по умолчанию выдаёт следующий последовательный IP для следующего пира-клиента.

Продолжая заимствовать идеи из BTH, мы используем возможности роутера генерировать и временно хранить QR-коды и конфигурационные файлы для отправки клиентам, таким образом получаем надёжную и гибкую функцию ЭКСПОРТА.

++++++++++++++++++++++

Итоговые мысли. Импорт пока не проработан подробно, но по крайней мере должны работать:
a. любой стандартный конфиг/QR-код, когда роутер MT — клиент в сети Wireguard для Handshake
b. конфиг/QR-код, сгенерированный другим роутером MT (получатель автоматической отправки)

Не стесняйтесь указывать на ошибки, пропуски или возможные улучшения.

И наконец, я прошу сотрудников MT внедрить доступный linux-код для поддержки Wireguard на вторичных WAN-соединениях. Это решается свойством (fwmark), которое есть в стандартной структуре Wireguard в Linux. Это свойство помечает все пакеты, исходящие от wg при создании. Благодаря этому можно применить соответствующие настройки конфигурации, чтобы входящий трафик WG на wan2 уходил обратно по wan2.

Мы столкнулись с этим в RoS, так как большинство не знает, что интерфейс Wireguard не назначает и не выбирает исходящий IP, как другие протоколы.

anav

Guest

07.05.2025 16:25:00

Благодаря более глубокому пониманию функции Responder, теперь мне понятно, что MT правильно разместил её так, чтобы она была связана с каждым пиром отдельно, а не со всем интерфейсом, как я думал раньше. Тем не менее, я решил оставить галочку RESPONDER на странице интерфейса, поскольку, скорее всего, в 99% случаев администратор выберет устройство MT, выступающее в роли сервера, чтобы активировать только режим Responder.

Одним из немногих исключений, когда не хочется давать возможности «дозваниваться» до «другого» пира (то есть инициировать соединение), является ситуация с MESH, и в этом случае галочку ставить не надо. Поэтому я предлагаю автоматически добавлять галочку Responder ко всем пирами, добавляемым к интерфейсу, чтобы при необходимости администратор мог её снять для отдельных пиров (хотя такое бывает редко).

Что касается умного программирования: галочка Responder должна быть неактивна (серой) при использовании ключей, сгенерированных третьими сторонами для этого интерфейса (то есть при ручном вводе ключей). В то же время галочка Responder должна ставиться автоматически, если ключ для устройства MT генерируется автоматически для данного интерфейса.

Кроме того, после лучшего понимания проблемы с пробросом портов (pinholes), UDP-трафиком и межсетевыми экранами, стало ясно, что сброс соединения WireGuard — единственный выход, а самый простой способ сделать это — сменить src-port у клиентского пира при рукопожатии. Роутер должен уметь отслеживать/определять, есть ли ответы на initial handshakes, и в случае их отсутствия предпринимать соответствующие действия. При условии, что администратор хочет, чтобы роутер это делал.

Для этой функции в обновлённой схеме добавлена дополнительная галочка. По умолчанию она отключена.

anav Guest	#5 0 07.05.2025 17:09:00 … …

lurker888

Guest

05.07.2025 05:08:00

Самое большое странность, которую я вижу в текущем интерфейсе — это то, что параметры типа «client-», которые используются только для конфигурации клиента и генерации QR-кода, на первый взгляд смешаны с обычными и важными параметрами локальной стороны пиринга WireGuard. Мне кажется, что возможность генерировать конфиги прямо в интерфейсе — это классно, но параметры, применяемые только для этого, должны быть как-то чётко отделены: линией, заголовком или отдельной вкладкой. Ещё важно прямо в интерфейсе дать понять, что знание приватного ключа другой стороны не требуется, а для тех, кто заботится о безопасности, даже наоборот — это нежелательно.

Должен это отметить. По-настоящему полезным улучшением было бы добавление поддержки VRF или понимания таблицы маршрутизации, как это сделано в других сервисах. (Без патча ядра это, конечно, требует использования fwmark.) В этой области прогресс у многих других сервисов заметен, особенно мне нравится, как это реализовано в OpenVPN. Конечно, есть свои приоритеты, и я, например, считаю, что исправление Ethernet MAC у Ecotec для новой серии hEX определённо было важнее всего этого.

anav Guest	#7 0 05.07.2025 13:17:00 Согласен, очень запутанно при помощи видеть весь этот «шум» в настройках клиента на MT-роутере, особенно в параметрах пиров, и если нужно, нужно сделать этот момент более понятным и менее сбивающим с толку.

Читают тему

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