Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Новинка
Распродажа
Новости
Доставка
Оплата
Загрузки
  • Прошивки
    • WinBox
    • RouterOS
    • Мобильные приложения MikroTik
    • Архив
  • RouterOS
  • Мобильные приложения MikroTik
  • Архив
Форум
Настройка
    info@mikrotik.moscow
    +7 495 320-55-52
    Заказать звонок
    Mikrotik.moscow
    Каталог
    • Акции
      Акции
    • Маршрутизаторы
      Маршрутизаторы
    • Коммутаторы
      Коммутаторы
    • Радиомосты и уличные точки доступа
      Радиомосты и уличные точки доступа
    • Wi-Fi для дома и офиса
      Wi-Fi для дома и офиса
    • LTE/5G
      LTE/5G
    • Powerline адаптеры
      Powerline адаптеры
    • IoT устройства
      IoT устройства
    • Оборудование 60 ГГц
      Оборудование 60 ГГц
    • Материнские платы RouterBOARD
      Материнские платы RouterBOARD
    • Корпуса
      Корпуса
    • Интерфейсы
      Интерфейсы
    • SFP/QSFP трансиверы
      SFP/QSFP трансиверы
    • Аксессуары
      Аксессуары
    • Антенны
      Антенны
    • Архив
      Архив
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Скачать WinBox Скачать Прошивки Форум > RouterOS Форум > SwOS Форум > Железо
    Mikrotik.moscow
    Каталог
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Mikrotik.moscow
    Телефоны
    +7 495 320-55-52
    Заказать звонок
    0
    0
    0
    Mikrotik.moscow
    • +7 495 320-55-52
      • Назад
      • Телефоны
      • +7 495 320-55-52
      • Заказать звонок
    • info@mikrotik.moscow
    • г. Москва, ул. Бакунинская, 84
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной


    • Кабинет
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    Форум
    RouterOS
    Сервер MikroTik Wireguard с удалёнными клиентами Road Warrior

    Сервер MikroTik Wireguard с удалёнными клиентами Road Warrior

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Сервер MikroTik Wireguard с удалёнными клиентами Road Warrior, RouterOS
     
    mducharme
    Guest
    #1
    0
    13.04.2021 23:47:00
    Этот документ — руководство по настройке Wireguard VPN на MikroTik для клиентов-«роуд воинов», таких как устройства на iOS. Требуется RouterOS версии 7.x. Wireguard представляет собой набор туннелей точка-точка, но при этом один и тот же IP может использоваться на стороне самой системы Wireguard.* В этом примере мы выделили отдельную подсеть Wireguard 192.168.66.0/24, которая отделена от нашей основной внутренней сети MikroTik. IP сервера Wireguard — 192.168.66.1/24, а клиенты — 192.168.66.2, 192.168.66.3 и так далее. В итоге получается такая схема точка-точка:

    192.168.66.1 (сам роутер-сервер Wireguard) <-----------> клиент Wireguard с IP 192.168.66.2  
    192.168.66.1 (сам роутер-сервер Wireguard) <-----------> клиент Wireguard с IP 192.168.66.3 и так далее.

    IP клиентов Wireguard назначаются статически и обычно это приватные IP, которые никак не связаны с их публичными IP, из которых они реально выходят в сеть. Сейчас нет динамического способа (например, DHCP) раздачи IP для клиентов Wireguard, поэтому такая схема может не подойти для очень крупных сетей RoadWarrior — каждый пользователь настраивается вручную.

    * Примечание: Технически роутеру Wireguard не обязательно иметь IP в этой подсети, но если его нет, нужно вручную настраивать статические маршруты, чтобы клиенты были доступны. Если сервер Wireguard имеет IP в этой подсети, MikroTik автоматически создаёт «динамический подключённый» маршрут, и это будет гораздо удобнее для большинства пользователей.

    Конфигурация сервера MikroTik Wireguard:  
    # При добавлении интерфейса wireguard автоматически сгенерируются приватный и публичный ключи  
    /interface wireguard  
    add listen-port=13231 mtu=1420 name=wireguard1  
     
    /interface wireguard peers  
    # первый клиент, добавленный здесь, только IPv4  
    add allowed-address=192.168.66.2/32 interface=wireguard1 public-key="replace-with-public-key-of-first-client"  
    # второй клиент — двойной стек, используется публичный IPv6 — замените 2001:db8:cafe:beef: на один из ваших префиксов /64  
    add allowed-address=192.168.66.3/32,2001:db8:cafe:beef::3/128 interface=wireguard1 public-key="replace-with-public-key-of-second-client-dual-stack"  
     
    /ip address  
    add address=192.168.66.1/24 interface=wireguard1 network=192.168.66.0  
     
    /ipv6 address  
    add address=2001:db8:cafe:beef::1/64 interface=wireguard1

    Пример конфигурации клиента Wireguard на iOS (выступает как «второй клиент» из примера выше):  
    Интерфейс: любое имя на ваш выбор  
    Публичный ключ: клиент сгенерирует автоматически — этот ключ нужно добавить на сервер вместо "replace-with-public-key-of-second-client-dual-stack"  
    Адреса: 192.168.66.3/24, 2001:db8:cafe:beef::3/64 (обратите внимание, маски подсетей отличаются от настроек на сервере)  
    DNS серверы: любые по желанию — если хотите использовать сервер Wireguard как DNS, укажите 192.168.66.1  
     
    Peer:  
    Публичный ключ — возьмите из интерфейса wireguard на Mikrotik и вставьте сюда  
    Endpoint — mydyndns.whatever:13231  
    Allowed IPs: 0.0.0.0/0, ::/0  

    Такая конфигурация отправит весь трафик клиента через Wireguard сервер на MikroTik. Если не хотите проксировать весь трафик (например, для разделённого туннеля), ограничьте Allowed IPs в настройках Peer только нужными подсетями, к которым должен идти доступ через туннель, вместо 0.0.0.0/0 и ::/0.

    Также нужно добавить правила в фаервол input для разрешения UDP трафика на порт 13231, чтобы туннель Wireguard вообще смог установиться:  
    /ip firewall filter add action=accept chain=input comment="Allow Wireguard" dst-port=13231 protocol=udp

    Трафик, который вы отправляете при подключении к Wireguard, будет иметь IP клиента Wireguard, в примере это 192.168.66.2 или 192.168.66.3. Значит, нужно убедиться, что фаервол MikroTik пропускает такой трафик и его NAT производится, если нужно. Если ваша конфигурация строится на дефолтных настройках MikroTik, можно просто добавить интерфейс Wireguard в список интерфейсов LAN — это решит и пропуск, и NAT в одном флаконе.
     
     
     
    intrepidsilence
    Guest
    #2
    0
    28.05.2021 17:18:00
    Не могли бы вы объяснить, как правильно добавить правило в фаервол, чтобы это работало? Я уже пробовал несколько вариантов, но безуспешно. Также, нужна ли статическая маршрутизация? WireGuard назначает клиенту IP-адрес как IP пира? Может ли он находиться в той же сети, что и подсеть DHCP, где работают все остальные устройства? Заранее спасибо!
     
     
     
    mducharme
    Guest
    #3
    0
    29.05.2021 02:17:00
    Четыре вопроса, четыре ответа:

    Тебе понадобится такое правило для файрвола:
    /ip firewall filter add action=accept chain=input comment="Allow Wireguard" dst-port=13231 protocol=udp

    Статический маршрут не нужен, нет.

    Нет, Wireguard не поддерживает динамическое назначение адресов для клиентов — всё статично и указывается на стороне клиента.

    Нет, это невозможно.
     
     
     
    saimens
    Guest
    #4
    0
    30.05.2021 09:56:00
    Спасибо @mducharme и @anav за вашу огромную поддержку. Я протестирую это в следующее воскресенье и сообщу вам результаты. С уважением, Саймон.
     
     
     
    anav
    Guest
    #5
    0
    29.05.2021 16:20:00
    Моя схема Wireguard с использованием Beta5.  
    A.  IOS-телефон подключается к серверу Wireguard на RBG.  
    B.  Внешний ПК за роутером MT RB4011 выступает клиентом Wireguard и подключается к другому серверу Wireguard на RBG.  
    C.  iPhone и внешний ПК связаны с разными интерфейсами WG на RBG (2 интерфейса WG, каждый с одним пэром, а не ОДИН интерфейс с двумя пэрами).  
    D.  Интерфейсам WireGuard не нужны подсети или IP-адреса.  

    Примечания: Оба устройства MT Wireguard (сервер и клиент) находятся за основным роутером. Подключение через IOS-смартфон используется для управления роутерами CCR1009, RBG и RB4011 через интерфейсы Wireguard. Подключения Wireguard с IOS-смартфона и внешнего ПК обеспечивают интернет через WAN-подключение CCR. Пропускная способность примерно 300 Мбит/с на загрузку и выгрузку при условии, что основные роутеры подключены к одной 1-гигабитной оптоволоконной сети (расстояние до 15 км). План — убрать RBG, когда Wireguard выйдет из бета-версии.  
    …
     
     
     
    saimens
    Guest
    #6
    0
    29.05.2021 16:43:00
    Привет! Спасибо за пример, очень ценю. К сожалению, у меня не получается воспроизвести ситуацию. Есть ли у тебя какие-нибудь подсказки, исходя из моей конфигурации? После активации клиента на macOS (то же самое и для iOS) он показывает «активирован», но я не могу пинговать Wireguard-сервер и не могу зайти в webfig (пробовал все IP-адреса). Ключи только для теста. Wireguard-сервер на Mikrotik hEX S, который подключен к провайдеру по оптоволокну. Wireguard-клиент на macOS. Заранее спасибо. Саймон.
     
     
     
    mducharme
    Guest
    #7
    0
    29.05.2021 18:12:00
    Ваш интерфейс wireguard для роадварьеров должен быть также в списке LAN интерфейсов — убедитесь, что вы это сделали.
     
     
     
    saimens
    Guest
    #8
    0
    29.05.2021 22:27:00
    Спасибо за быстрый ответ. Всё равно не работает. Есть ещё идеи? Я добавил следующую запись в раздел списка. Не уверен, что это именно то, что вы просили сделать. Я также пытался добавить это в бридж, но тоже не получилось. Поэтому удалил обратно. Жду вашего ответа. С уважением, Саймон
     
     
     
    mducharme
    Guest
    #9
    0
    29.05.2021 23:00:00
    Убедись, что правило «allow wireguard» находится выше правил блокировки (drop rules) в цепочке input, а точнее — как минимум выше финального правила «drop all» для входящих соединений. Судя по всему, у тебя оно в самом конце, а это уже слишком поздно. У меня же оно стоит сразу над правилом «drop invalid» в цепочке input, хотя, возможно, это не обязательно.
     
     
     
    anav
    Guest
    #10
    0
    30.05.2021 02:03:00
    Основные моменты по серверному маршрутизатору: Wireguard — это сервис на маршрутизаторе, и поэтому нужно разрешить изначальный незашифрованный трафик к маршрутизатору через INPUT CHAIN. Это подразумевает открытый порт прослушивания, протокол UDP и интерфейс (трафик, идущий) с WAN. Для "дорожного воина" (road warrior) нельзя сузить источник адреса дальше. Как уже говорилось, это правило должно применяться сразу после стандартных правил firewall в input chain (например, после разрешения ICMP ping), но перед любыми правилами drop и прочими.  

    Что происходит: клиентский трафик достигает интернета, затем серверный маршрутизатор и далее направляется на сервис wireguard. Если вести логирование этого правила, то в случае успеха вы получите примерно одну запись в логе. Тоннель будет согласован и установлен. После этого клиент сможет передавать трафик через туннель на интерфейс wireguard. Трафик будет маршрутизироваться через основную таблицу маршрутизации, которая уже настроена на серверном маршрутизаторе.  

    2. Убедитесь, что на серверном маршрутизаторе MT добавлен IP-маршрут, который направляет обратный трафик из интернета обратно через туннель wireguard к клиентскому устройству. Таким образом, адрес назначения — это подсеть LAN клиентского устройства или IP-адрес клиента, а шлюз — интерфейс wireguard.
     
     
     
    mducharme
    Guest
    #11
    0
    30.05.2021 02:23:00
    Это необходимо только в том случае, если такого маршрута ещё нет — например, если WireGuard работает не на том же устройстве. Если же он настроен на том же устройстве (как в большинстве случаев), то уже будет существовать подключённый маршрут © для возвратного трафика, и вручную добавлять дополнительный маршрут на MikroTik не нужно и даже вредно.
     
     
     
    anav
    Guest
    #12
    0
    30.05.2021 12:01:00
    Когда роутер сервера получает обратные пакеты из интернета для подсети или IP-адреса, которые роутеру неизвестны (устройства клиентов wg, использующие туннель), и не настроены на роутере, маршрут IP подсказывает роутеру: «Эй, эти пакеты отправляй на WG-интерфейс». Без таких маршрутов и для моего клиентского MT-устройства, и для связанного ПК, и для iPhone нет другого волшебного способа доставить им обратный трафик. Насколько я понимаю, конфигурация wireguard не создаёт IP-маршруты автоматически? Возможно, мой пример уникален, потому что я за другим MT-роутером? В этом случае вы можете увидеть, что мне приходится создавать IP-маршрут для обратного интернет-трафика на первом роутере CCR, специально для возврата трафика клиентских устройств (iPhone или внешний ПК) на LANIP/WANIP второго роутера wireguard-сервера. Потом я делаю аналогично на роутере сервера, чтобы вернуть пакеты обратно в туннель. Вы хотите сказать, что при использовании только одного роутера всё это происходит автоматически? У меня есть маскарадинг и SourceNAT на обоих роутерах, но этого недостаточно!
     
     
     
    mducharme
    Guest
    #13
    0
    30.05.2021 19:28:00
    Да, это происходит автоматически при использовании одного роутера. В вашем случае ситуация немного другая, потому что ваш Wireguard-сервер стоит за другим роутером. Например, если роутер с Wireguard-сервером напрямую подключён к интернету и имеет публичный IP в качестве основного шлюза, его IP может быть, скажем, 192.168.66.1/24. В результате у роутера есть связанный маршрут к интерфейсу Wireguard для подсети 192.168.66.0/24. Допустим, клиенту назначен IP 192.168.66.2/32. Клиент заходит на сайт, и так как allowed-ips на стороне клиента — это 0.0.0.0/0, он отправляет весь трафик через Wireguard на роутер. Роутер маскирует этот трафик (при условии, что интерфейс Wireguard включён в список LAN-интерфейсов) и отправляет его в интернет. Ответ, который возвращается, поступает обратно на роутер, который понимает, что пакет нужно вернуть клиенту с IP 192.168.66.2. Он проверяет свою таблицу маршрутизации, видит, что адрес 192.168.66.2 принадлежит подсети, к которой уже есть связанный маршрут через интерфейс Wireguard.
     
     
     
    anav
    Guest
    #14
    0
    30.05.2021 20:19:00
    Нет, я всё ещё не вижу этого и не согласен, но, похоже, ты упускаешь главный момент — я не назначаю IP или IP-адрес интерфейсу wireguard в своей схеме. Это просто интерфейс, и ничего больше. ИЗМЕНЕНИЕ: это возможный подход, но создание адреса wireguard — ЛУЧШИЙ вариант. Сэм наконец-то мне это вбил в голову.
     
     
     
    mducharme
    Guest
    #15
    0
    30.05.2021 20:59:00
    Хорошо, понял. В чём смысл не использовать IP-адрес на интерфейсе WireGuard? (Кроме экономии одного IP-адреса)
     
     
     
    anav
    Guest
    #16
    0
    30.05.2021 21:21:00
    Зачем вам нужен IP-адрес? Какую функцию добавление IP-адреса на WG выполняет? Сейчас с моего iPhone я могу управлять и настраивать любой роутер MT, подключенный к Wireguard. Я могу выходить в интернет через сервер WG с iPhone. Внешний компьютер, подключённый к серверу Wireguard, может выходить в интернет. Внешний компьютер, подключённый к серверу Wireguard, при необходимости может получить доступ к моим принтерам в другой VLAN...
     
     
     
    mducharme
    Guest
    #17
    0
    30.05.2021 22:20:00
    Я не совсем уверен, но это присутствует во всей документации и во всех руководствах по Wireguard, которые я находил для этого. Похоже, ты придумал свой собственный метод, который отличается от всех остальных руководств по Wireguard и отклоняется от того, что говорится в документации. Я бы предположил, что раз вся документация показывает именно такой способ, значит на то есть причина, и это не просто бесполезная практика. Хотя я не пробовал, я подозреваю, что в твоём варианте может не сработать ситуация, когда два клиента Wireguard подключаются к твоему серверу Wireguard, и при этом ты хочешь, чтобы они могли общаться между собой. Например, два iPhone, подключённых к серверу, могут не смочь пинговать друг друга, но при этом иметь доступ ко всему остальному. Это нормально работает, если у Wireguard-сервера есть IP-адрес и один интерфейс Wireguard с подсетью 192.168.66.1/24, а два клиента настроены на 192.168.66.2 и 192.168.66.3.
     
     
     
    anav
    Guest
    #18
    0
    31.05.2021 10:48:00
    Я не отвергаю твой подход, возможно, есть ситуации, где он полезен, просто я пока с такими не сталкивался. Из любопытства: ты просто назначаешь IP-адрес интерфейсу WireGuard или задаёшь подсеть, а потом раздаёшь клиентским устройствам IP из этой подсети? Когда ты говоришь, что можно соединить двоих клиентов напрямую, для чего это практически нужно? После того как у всех появляется интернет через сервер, они могут, например, использовать Discord или другие приложения для общения, так что интересно услышать реальные примеры, зачем это может понадобиться.

    Считаю, что устраивать тусовку на твоём сервере WireGuard — плохая идея, ха-ха. На самом деле, если они все в одной подсети, и это автоматически даёт подключённым клиентам возможность видеть друг друга, — это плохая безопасность, особенно если нет способов их заблокировать! Я подозреваю, что если два пира находятся на одном интерфейсе БЕЗ структуры IP-адресов, то они, скорее всего, не видят друг друга автоматически, но точно не уверен, потому что не тестировал.
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2026 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры