Информация
Настройка
Новости
Контакты
Новинка
Распродажа
Оплата
Доставка
Загрузки
  • Прошивки
    • WinBox
    • RouterOS
    • Мобильные приложения MikroTik
    • Архив
  • Changelogs
  • 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
    Трансляция и мультитрансляция через VPN (PPP)

    Трансляция и мультитрансляция через VPN (PPP)

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Трансляция и мультитрансляция через VPN (PPP), RouterOS
     
    MarcTik
    Guest
    #1
    0
    14.02.2015 11:17:00
    Я использую продукцию Mikrotik и сейчас работаю с RB750GL, обновлённым до версии 6.27. Ситуация такова: у меня есть локальная сеть (подсеть 10.1.101.0/24) на Ether2, которая успешно подключена и обменивается multicast и broadcast-пакетами между устройствами. Ether1 подключён к интернету (сеть Интернета — 192.168.88.0/24), где ПК хочет присоединиться к этой локальной сети через PPP-соединение (настройка Mikrotik как PPTP или L2TP-сервер — всё работает). Я создал «Bridge-Local» для локальной подсети (Ether2) и добавил его в PPP-профиль, который используется для PPP-соединения. VPN-соединение работает, IP-адреса настроены корректно, а proxy-ARP, включённый на интерфейсе «bridge-local», работает отлично.

    Однако этого недостаточно. Многие приложения и сервисы (Netbios, SIP, игры и др.) используют broadcast/multicast-пакеты (например, с Dest=255.255.255.255) при первоначальном запросе или в обычной работе для обнаружения и подключения к другим ПК в одной сети. VPN-соединение не переправляет/не маршрутизирует multicast/broadcast-пакеты с Ethernet-подсети на Ether2 к VPN-клиенту (и наоборот), хотя IP-адреса настроены правильно и устройства объединены в тот же мост «Bridge-Local».

    Я пробовал следующее:  

    - Настраивал BCP, но это не сработало, возможно, потому что он предназначен для VPN-соединений между двумя роутерами MikroTik, а не между ПК и роутером.  
    - Устанавливал пакет Multicast, но полагаю, что PIM и IGMP — это не то, что мне нужно.  

    Всё, что мне нужно — чтобы роутер Mikrotik переправлял multicast-пакеты, исходящие из подсети на Ether2, к VPN-клиенту и наоборот.

    Вкладка “Firewall → Connections”, например, показывает, что broadcast-пакеты от 10.1.101.100 имеют статус U — Unreplied от 10.1.101.2, 3, 4 и наоборот.

    Есть тема, обсуждающая эту проблему («UDP broadcast over VPN»), но там приводится решение только для роутер-к-роутеру.

    Буду признателен за любую помощь. Дополнительная информация во вложении.
     
     
     
    UNiXMIT
    Guest
    #2
    0
    22.01.2016 20:25:00
    Ты смог это как-то запустить? У меня такая же проблема. Спасибо.
     
     
     
    y64xkuo
    Guest
    #3
    0
    30.07.2016 19:30:00
    Та же проблема у меня. Как это можно решить?
     
     
     
    pe1chl
    Guest
    #4
    0
    30.07.2016 20:09:00
    Какие приложения до сих пор имеют эту проблему? (Я имею в виду требование использовать LAN-бродкаст 255.255.255.255). Я бы думал, что все приложения уже могут работать по интернету, где бродкаст вообще не используется… Может, стоит настроить само приложение иначе? (например, больше не использовать Netbios)
     
     
     
    y64xkuo
    Guest
    #5
    0
    30.07.2016 21:06:00
    В моём случае StarCraft нельзя играть через VPN, так как для подключения клиентов к игроку, который ведёт игру, используется широковещательная рассылка. Но если мы найдём решение этой проблемы, то и другие приложения, которые устроены аналогичным образом, тоже будут работать.
     
     
     
    idlemind
    Guest
    #6
    0
    16.06.2017 16:10:00
    Воскресну эту тему на случай, если ещё кто-то с вопросами здесь. Дело в том, что стандартный VPN с удалённым доступом поддерживает только уникаст-трафик. Теоретически IKEv2 может работать с мультикастом, что частично решит проблему. Но если вы отчаялись поиграть в SC с другом, можно настроить EoIP-туннель между двумя роутерами MikroTik. Немного мостирования — и вы с приятелем окажетесь в одной LAN с возможностью передачи и инкапсуляции широковещательных пакетов.

    MikroTik1 ↔ Интернет ↔ MikroTik2  
    MikroTik1 WAN IP: 10.1.1.2/30  
    MikroTik2 WAN IP: 10.1.1.6/30  
    MikroTik1 LAN IP: 192.168.1.0/24  
    MikroTik2 LAN IP: 192.168.1.0/24  
    Волшебная общая LAN для StarCraft: 172.16.1.0/24  

    Для MikroTik1:  
    /interface eoip add name=eoip-sc clamp-tcp-mss=yes remote-address=10.1.1.6 local-address=10.1.1.2  

    Для MikroTik2:  
    /interface eoip add name=eoip-sc clamp-tcp-mss=yes remote-address=10.1.1.2 local-address=10.1.1.6  

    На обоих MikroTik’ах создаём мост (чтобы отделить от обычных LAN и минимизировать нагрузку, которая может вызвать задержки):  
    /interface bridge add name=br-sc  
    /interface bridge port add bridge=br-sc interface=eoip-sc  

    Вот и всё, простая настройка программного моста между двумя удалёнными MikroTik, который поддержит любой IPv4 (или IPv6) трафик. Можно создать отдельный SSID специально для этого моста, либо добавить Ethernet-порт к мосту с каждой стороны и подключить к нему игровые компы для игры в SC. Ещё вариант — выделить VLAN для этого моста и передавать его по существующему Ethernet-соединению к вашей игровой машине.

    Дополнительное:  
    Возможно, захочется сделать сеть маршрутизируемой. Для этого интерфейсу моста нужно назначить IP с обеих сторон.  
    MikroTik1:  
    /ip address add interface=br-sc address=172.16.1.254/24  
    MikroTik2:  
    /ip address add interface=br-sc address=172.16.1.253/24  

    Может понадобиться общий IP для мостов в виде единого шлюза по умолчанию — тогда весь трафик пойдёт через текущий мастер.  
    MikroTik1:  
    /interface vrrp add name=vrrp-sc interface=br-sc preemption-mode=yes version=3 vrid=254 priority=220  
    MikroTik2:  
    /interface vrrp add name=vrrp-sc interface=br-sc preemption-mode=yes version=3 vrid=254 priority=210  

    На обоих:  
    /ip address add interface=vrrp-sc address=172.16.1.1/32  

    Можно настроить DHCP, чтобы раздавать адреса и настройки, и не заниматься этим вручную:  
    MikroTik1:  
    /ip pool add name=br-sc ranges=172.16.1.11-19  
    MikroTik2:  
    /ip pool add name=br-sc ranges=172.16.1.21-29  

    На обоих:  
    /ip dhcp-server add name=br-sc interface=br-sc address-pool=br-sc lease-time=180m  

    Вы сами решаете, нужен ли шлюз по умолчанию, либо не нужен вообще. Если реализуете VRRP — можете его распространять. Можно даже дать DHCP ответ с разным шлюзом с каждой стороны. В большинстве случаев локальный DHCP отвечает быстрее, чем через туннель EoIP, поэтому почти всегда вы получите адрес с правильным шлюзом от нужной стороны.

    Пример команды для обоих устройств (с использованием VRRP IP):  
    /ip dhcp-server network add address=172.16.1.0/24 gateway=172.16.1.1 dns-server=172.16.1.1  

    Заключение:  
    Стоит помнить, что GRE и NAT — не дружат, поэтому это лучше делать на WAN-интерфейсе. 1:1 NAT на устройство за фаерволом тоже возможен, но это уже усложняет дело. Альтернативой может стать глобальный уникаст через IPv6. Ещё важно учитывать MTU — не хочется, чтобы роутер фрагментировал пакеты и тормозил вашу игровую сессию больше, чем нужно. Лучше сразу выставить MTU на каждом ПК или на интерфейсе сети SC в районе 1400.

    Почти напоследок — можно создать несколько EoIP-туннелей между друзьями для более масштабных игр. Ещё можно сделать резервирование. Допустим, у вас 5 друзей (всего 6 человек) и вы все — заядлые гики, которые никак не хотят выходить из дома, чтобы поиграть. Можно сделать схему «звезда»: все подключаются к вашему MikroTik — норм. Можно также сделать одного из друзей тоже хабом. Тогда у каждого спока будет минимум 2 туннеля (к каждому из хабов), а у каждого хаба — по 5 туннелей (4 к спокам + 1 между хабами). Все туннели добавляются в мосты, а на мостах включается spanning-tree, чтобы избежать петель. Если один из хабов вдруг отключится (или интернет отрубили из-за всех этих бесконечных игр), то остальные смогут играть через резервный хаб.

    И последнее, на случай, если интересно. EoIP можно завернуть в IPSec для шифрования трафика, если это важно. Правда, там может появиться дополнительная задержка.
     
     
     
    UNiXMIT
    Guest
    #7
    0
    04.10.2017 09:12:00
    EoIP — это потрясающе, и я очень рекомендую. Работает безупречно. Спасибо.
     
     
     
    idlemind
    Guest
    #8
    0
    04.10.2017 14:08:00
    Отлично, ты использовал мой пример выше или нашёл EoIP до того, как я его опубликовал?
     
     
     
    UNiXMIT
    Guest
    #9
    0
    05.10.2017 14:21:00
    Я только что снова проверил это, и за это время мой друг посоветовал EoIP. Просто хотел вставить слово и сказать, как это здорово.
     
     
     
    berg
    Guest
    #10
    0
    19.10.2017 01:30:00
    Привет! Решил похожую проблему со Starcraft версии 1.16.1 и раньше: создал PPTP-сервер на Mikrotik в сети с сервером SC. Зашёл в IP-Firewall во вкладку Mangle. Создал новое правило Prerouting с такими параметрами: dst-addr=255.255.255.255; proto=udp, dst-port=6111, in-interface=pptp-in1, action=route, dst-address=192.168.88.3 (это мой ПК с сервером SC).

    [admin@MikroTik] /ip firewall mangle
    add action=route chain=prerouting dst-address=255.255.255.255 dst-port=6111 in-interface=pptp-server passthrough=yes protocol=udp route-dst=192.168.88.3  

    На другом конце ПК создаёт PPTP-подключение, ставит галочку «использовать шлюз по умолчанию с другой стороны» в свойствах протокола IPv4. Пытаешься поиграть.

    Описание: вижу пакеты на 255.255.255.255:6111 от друга, который подключился через PPTP к моему Mikrotik. SC использует широковещательный UDP-порт 6111 для поиска LAN-серверов. Я меняю эти пакеты (mangle) и жёстко направляю их на свой ПК (192.168.88.3). Сервер игры становится видим для моего друга.
     
     
     
    Sovandara
    Guest
    #11
    0
    27.10.2017 12:16:00
    Привет, я протестировал RB951 с версией ROS 6.40. Сделал EOIP VPN и связал EOIP-туннель с Ethernet-интерфейсом в мост. Затем попытался передать мультикаст-поток с одной стороны на другую, но ничего не сработало. Поискал на форумах — для этого нужно включить IGMP Snooping на мостовом интерфейсе. Похоже, RB951 эту функцию не поддерживает. Спасибо, Sovandara
     
     
     
    idlemind
    Guest
    #12
    0
    27.10.2017 12:36:00
    Мультикаст не требует IGMP snooping. Мост должен рассылать (транслировать) мультикаст-пакеты по всем портам, даже если эта функция не включена. На втором уровне (L2) MAC-адрес IPv4 мультикаста начинается с 01005e, и это подсказывает мосту, что нужно рассылать пакеты по всем портам (а если IGMP snooping включён — то только на подключённые порты). Если этого реально не происходит, стоит начать с жалобы в MikroTik — возможно, это баг. Отдельно: в версии 6.41rc IGMP snooping реализован и им можно управлять. Включение этой функции заставит мост работать на программном уровне на вашем железе, а учитывая, что производительность всё равно будет ограничена EoIP, это может быть не так уж плохо, если эта функция вам действительно нужна.
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2025 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры