Привет, я настраиваю мост между роутером (750GL) и беспроводным AP (RB751U-2HnD). Я следую инструкции по BCP-мосту (http://wiki.mikrotik.com/wiki/Manual:BCP_bridging_(PPP_tunnel_bridging)). Затем я добавил DHCP-сервер на интерфейс моста на 750GL, который также работает как PPTP-сервер. Устройства подключаются, и связь между ними отлично работает с использованием статических IP-адресов. Проблема в том, что на стороне клиента PPTP предложения DHCP никогда не доходят до клиентов. Я подключаю компьютер к RB751U-2HnD, DHCP-сервер на 750GL предлагает аренду, а затем ничего не происходит. Кажется, что компьютер никогда не получает предложение аренды... Я уже сижу с этим около 7 часов и больше не знаю, что делать. DHCP отлично работает на физических интерфейсах 750GL. P.S. Мои навыки MikroTik на уровне новичка. Буду признателен за любую помощь. Я использую RouterOS 6.4.
Спасибо, Рудиос! Теперь мне просто нужно протестировать все остальные функции, которые мы используем на RouterOS 6.17, прежде чем мы обновимся с нашей надежной версии 6.5.
Привет, я понизил версии своих маршрутизаторов до 5.26, и та же настройка заработала нормально. Я провел анализ трафика, и похоже, что версия 6.xx RouterOS по какой-то причине не пересылает ответы DHCP через PPTP-соединения. Запросы доходят, но все ответы не покидают главный маршрутизатор через PPTP. Я сообщу об этой ошибке, и надеюсь, что её исправят.
Я провел еще несколько тестов. Я использовал RouterOS 6.5 и сталкивался с проблемами, о которых говорил Лазарь. Только что понизил версию до RouterOS 5.26, и все работает!!! Я также опубликую свои результаты в теме о версии 6.5, возможно, кто-то там знает решение.
Эти проблемы начались где-то в версии 6.4/5 и, как я думаю, решены в версии 6.12. Я еще не тестировал это на последней версии, но сделаю это как можно скорее.
Я только что очень тщательно протестировал это, и, похоже, оно не работает на версии 6.17. Рудиос, можешь это проверить и повторить свои тесты? Мне кажется совершенно очевидным, что это все еще неисправно. Вот моя простая схема из двух маршрутизаторов. Подробности в конце. Каждый маршрутизатор подключен через ether1 к моей рабочей локальной сети, соответственно с адресами 192.168.1.133 и .134. Я назову их «левый» и «правый». Оба имеют мост под названием bridge-tunnel, без портов. MAC-адрес администратора установлен на 02:AA:AA:AA:AA:AA на правом, а 02:BB:BB:BB:BB:BB на левом. Оба моста соединены через BCP, используя PPTP. Левому мосту статически назначен адрес 192.168.40.5/24. Правому мосту статически назначен адрес 192.168.40.1/24. DHCP-сервер создан на правом мосту с пулом 192.168.40.100-192.168.40.200. DHCP-клиент создан на левом мосту. Тестирование: 1) Ping с левого маршрутизатора на 192.168.40.1 2) Ping с правого маршрутизатора на 192.168.40.5 3) Проверка, получает ли DHCP-клиент на левом мосту IP-адрес от DHCP-сервера на правом мосту. Результаты: ROS 6.17. Тесты 1 и 2 проходят, тест 3 не проходит. ROS 5.26. Тесты 1, 2 и 3 всегда проходят. Конфигурация не изменялась между версиями ROS. Я протестировал 6.17, понизил версию до 5.24, протестировал, затем снова обновил до 6.17 и протестировал еще раз. Вот подробные конфигурации. На это уходит около 2 минут. Левый маршрутизатор: # jul/25/2014 15:32:08 by RouterOS 6.17 # software id = 4RFY-E9RX /interface bridge add admin-mac=02:BB:BB:BB:BB:BB auto-mac=no name=bridge-tunnel /ppp profile add bridge=bridge-tunnel name=profile-tunnel /interface pptp-client add add-default-route=no allow=pap,chap,mschap1,mschap2 connect-to= 192.168.1.133 dial-on-demand=no disabled=no keepalive-timeout=60 max-mru= 1450 max-mtu=1450 mrru=1600 name=pptp-tunnel password=tunneltest profile= profile-tunnel user=tt /ip address add address=192.168.40.5/24 interface=bridge-tunnel network=192.168.40.0 /ip dhcp-client add default-route-distance=0 dhcp-options=hostname,clientid disabled=no interface=ether1 add default-route-distance=0 dhcp-options=hostname,clientid disabled=no interface=bridge-tunnel use-peer-dns=no use-peer-ntp=no Правый маршрутизатор: # jan/02/1970 00:21:04 by RouterOS 6.17 # software id = 8J2K-5ZUR /interface bridge add admin-mac=02:AA:AA:AA:AA:AA auto-mac=no name=bridge-tunnel priority=0x4000 /ip pool add name=pool1 ranges=192.168.40.100-192.168.40.200 /ip dhcp-server add address-pool=pool1 authoritative=yes disabled=no interface=bridge-tunnel name=server1 /ppp profile add bridge=bridge-tunnel name=profile-tunnel /interface pptp-server server set default-profile=profile-tunnel enabled=yes mrru=1600 /ip address add address=192.168.40.1/24 interface=bridge-tunnel network=192.168.40.0 /ip dhcp-client add dhcp-options=hostname,clientid disabled=no interface=ether1 /ip dhcp-server network add address=192.168.40.0/24 gateway=192.168.40.1 /ppp secret add local-address=192.168.80.1 name=tt password=tunneltest profile= profile-tunnel remote-address=192.168.80.2
Что ж, ваш комментарий выше очень интересный. Я всегда думал, что локальные/удаленные адреса pptp необходимы для функционирования туннеля. Похоже, это действительно так, только если клиенту нужен локальный адрес для своих собственных маршрутов, чтобы достичь сервера. Я вижу, что это не требуется, если единственная функция туннеля - это BCP. Поскольку вы упомянули об оригинальном баге в теме "список багов", хотите сообщить им, что он все еще не совсем исправлен? Или мне это сделать? Это действительно баг или "не задокументированная особенность (т.е. не используйте локальные/удаленные IP-адреса, если туннель используется для BCP)"?
На версии 6.38.1 это не работает... И я не могу удалить адреса конечных точек L2TP туннеля, они назначаются независимо от настроек профиля/имени пользователя. Я использую EoIP, но мне действительно нужно, чтобы нативный BCP мостил DHCP.
У меня была такая же проблема, как и выше: DHCP-аренды предлагались клиентам на удалённой стороне BCP-соединения, но клиенты никогда не получали это предложение. В моем случае я добавлял BCP-туннели к существующему сайту. Я решил это, изменив назначение существующего IP-адреса для физического LAN-порта на главном сайте (в моем случае ether6) на BCP-мост вместо этого. Как только я это сделал и обновил соединения удаленного сайта, всё заработало. Надеюсь, это поможет кому-то с этой проблемой в будущем (или в прошлом!). Я пытался разобраться с этим в течение последнего месяца. Стив
Привет, твое мнение вполне разумно, по моему опросу, Сетевой Мост очень похож на функцию Общего Использования Интернета (ICS), но это не одно и то же. Когда мы используем Общий Доступ к Интернету (ICS), мы превращаем наш компьютер в роутер, который использует встроенный DHCP-сервер для назначения IP-адресов компьютерам, участвующим в ICS. Также он предлагает Преобразование Сетевых Адресов (NAT), позволяя нескольким устройствам подключаться к сети, используя хост ICS в качестве посредника. С другой стороны, Сетевой Мост не превращает хост-компьютер в роутер, и у вас не будет Преобразования Сетевых Адресов. Он просто предоставляет среду (мост), в которой другие устройства могут напрямую подключаться к сети и получать ту же схему IP-адресов, которую использует каждый другой компьютер, подключенный к сети.
В соответствии с обычной работой UDP инициатор туннеля выбирает доступный UDP-порт и отправляет номер порта 1701 на UDP-назначение. В ответе номер порта назначения совпадает с номером исходного порта, используемого в входящем UDP-заголовке. Исходный порт устанавливается на основе любого найденного свободного порта. После установления исходных и назначенных портов они должны оставаться неизменными на протяжении всего времени работы туннеля. Номера исходного и назначенного портов всегда устанавливаются на UDP-порт номер 1701.