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

Проблема с DHCP relay

Проблема с DHCP relay, RouterOS

sjoram

Guest

03.01.2017 20:06:00

У меня проблема с DHCP relay на некоторых VLAN. На одном всё работает нормально, а на других — нет. DHCP сервер — 10.0.0.5/16, установлен на HP коммутаторе с VLAN интерфейсом в RB750. Другие локальные VLAN на этом же коммутаторе используют DHCP relay через RB750 без проблем. У меня есть IPSec VPN к RB750GL, который тоже запускает DHCP relay обратно к DHCP серверу 10.0.0.5. DHCP relay для 10.5.0.0/16 работает нормально. А для 10.6.0.0/16 (и некоторых других) не работает.

Я смотрел через Wireshark на клиентской машине, которая делает DHCP запросы, и на DHCP сервере и вижу следующее: клиент отправляет повторяющиеся DHCP Discover пакеты, ответа нет. В логах RB750GL отображаются запросы, принятые DHCP relay агентом. DHCP сервер видит входящие DHCP Discover пакеты и возвращает DHCP Offer пакеты, адресованные IP релейного агента на RB750GL — 10.6.0.254. Но у RB750GL relay agent количество ответов равно 0.

Насколько я понимаю, никаких правил firewall (фильтров), которые блокируют трафик, нет. Раньше у меня было правило src 10.0.0.0/8 dst 10.0.0.0/8 dst port 67-68 для разрешения, но я заметил, что ошибочно указал TCP вместо UDP. Исправил это, но результата нет.

Есть идеи, где ещё можно поискать источник проблемы?

sjoram

Guest

24.03.2018 17:40:00

Хорошо, я разобрался со всеми своими NAT-правилами и подтвердил, что проблема кроется в srcnat-правиле, которое «исправляет» исходный IP для трафика, проходящего через IPSec-туннель. Поток трафика такой: DHCP-сервер (10.0.0.5/16) ↔ коммутатор ↔ маршрутизатор A ↔ IPSec ↔ маршрутизатор B ↔ коммутатор ↔ DHCP-клиент (должен быть 10.6.0.0/16).

У меня на «Router B» есть правило:
Источник: публичный IP интерфейса PPPoE-клиента
Назначение: 10.0.0.0/8
src-nat на 10.5.0.254

Это значит, что любой трафик, приходящий на другой конец IPSec-туннеля, всегда виден как 10.5.0.254, даже если исходный IP из подсети 10.6.0.0/16. Таким образом, DHCP Relay-пакеты, которые должны идти через 10.6.0.254, фактически идут с адреса 10.5.0.254, и ответный трафик от DHCP-сервера с назначением 10.6.0.254 просто отбрасывается или игнорируется.

Единственная подсеть/VLAN, где DHCP Relay на Router B работает нормально — это 10.5.0.0/16, так как она покрывается этим src-nat-правилом.

На Router A такого правила нет. Прошло много времени с тех пор, как я настраивал IPSec и Firewall/NAT, поэтому точная причина, зачем это правило есть на Router B, ускользает из памяти. Но в предыдущих постах упоминались ссылки на другие форумы и статьи вики, где обсуждалась похожая проблема.

Какие-нибудь идеи, как это исправить? Возможно, можно сделать src-nat-правило по-другому, и я что-то упускаю? Или придётся смириться с тем, что будет работать не идеально?

sjoram

Guest

25.03.2018 09:51:00

Когда я отключаю правило от источника (PPPoE Public IP) к назначению 10.0.0.0/8, и при этом добавляю правило passthrough, я вижу, что счетчики для источника с публичным IP к назначению 10.0.0.0/8 растут при отправке DHCP-запросов. Значит, роутер B пересылает DHCP relay-пакеты с исходящим адресом публичного IP, из-за чего они никогда не обрабатываются политикой IPSec, а публичный интернет, понятно дело, не может маршрутизировать 10.0.0.0/8.

sjoram

Guest

05.03.2018 15:32:00

Возрождаю старую тему, ребята. Извиняюсь, последнее время это было не в приоритете, поэтому не возвращался к этому. Я не пробовал убрать исходный адрес на DHCP relay, но не думаю, что это может вызвать проблему. Причина правил srcnat — как указано здесь https://wiki.mikrotik.com/wiki/Manual:IP/IPsec#NAT_and_Fasttrack_Bypass. Что я не совсем понимаю, так это почему один VLAN/подсеть работает без проблем, а с другими возникают неполадки…

sjoram

Guest

11.03.2017 13:19:00

Я только что снова потратил время на это, так как до сих пор не смог решить проблему. С клиентской машины, которая отправляет DHCP-запросы, в Wireshark показываются только пакеты DHCP Discover. DHCP-сервер видит пакеты DHCP Discover и отправляет DHCP Offer в ответ. Однако пакет DHCP Discover, похоже, приходит с неправильного исходного IP-адреса, хотя в деталях BOOTP в пакете указан правильный IP-адрес реле-агента. То есть: исходный IP адрес DHCP Discover — 10.5.0.254, адрес назначения — 10.0.0.5, IP-адрес реле-агента BOOTP — 10.6.0.254.

Удалённый RB750GL настроен с 10.6.0.254 как локальным адресом в DHCP relay, и я не вижу в своих правилах NAT ничего, что могло бы вызвать появление неправильного IP-адреса. DHCP relay работает отлично для подсети 10.5.0.0/16 с DHCP-сервером 10.0.0.5. Но DHCP relay для подсетей 10.6.0.0/16, 10.7.0.0/16 и 10.8.0.0/16 с этим же сервером не работает.

Я ещё не перепроверял 10.7.0.0/16 и 10.8.0.0/16, но предполагаю, что там такая же проблема, как и с 10.6.0.0/16 — discover-пакеты исходят с неправильного адреса 10.5.0.254. Могу только предположить, что так как пакеты приходят с адреса 10.5.0.254, а возвращаются на 10.6.0.254, их сбрасывает удалённый RouterOS из-за несоответствия IP?

Есть какие-то идеи? Я удалял и заново создавал эту запись DHCP relay — результата нет.

dgnevans Guest	#6 0 12.03.2017 18:27:00 Можешь показать конфигурацию для VLAN-ов и локальный IP, применённый к интерфейсу VLAN, а также настройки DHCP relay?

horhay Guest	#7 0 27.05.2017 13:43:00 Попробуйте установить «Админ. MAC-адрес» такой же, как и «MAC-адрес» на мосту. Также убедитесь, что STP на мосту отключён.

sjoram

Guest

06.06.2017 15:14:00

/interface vlan add interface=ether2-master-local name=VLAN5 vlan-id=5
add interface=ether2-master-local name=VLAN10 vlan-id=10
add interface=ether2-master-local name=VLAN20 vlan-id=20
add interface=ether2-master-local name=VLAN40 vlan-id=40
add interface=ether2-master-local name=VLAN60 vlan-id=60
add interface=ether2-master-local name=VLAN80 vlan-id=80

/ip address add address=192.168.88.1/24 comment="default configuration" interface=ether2-master-local network=192.168.88.0
add address=10.5.0.254/16 interface=VLAN10 network=10.5.0.0
add address=10.6.0.254/16 interface=VLAN20 network=10.6.0.0
add address=10.7.0.254/16 interface=VLAN40 network=10.7.0.0
add address=10.8.0.254/16 interface=VLAN60 network=10.8.0.0
add address=10.9.0.254/16 interface=VLAN80 network=10.9.0.0
add address=192.168.5.1/30 interface=VLAN5 network=192.168.5.0
add address=192.168.2.100/24 interface=ether1-gateway network=192.168.2.0

/ip dhcp-relay add dhcp-server=10.0.0.5 disabled=no interface=VLAN40 local-address=10.7.0.254 name=VLAN40
add dhcp-server=10.0.0.5 disabled=no interface=VLAN60 local-address=10.8.0.254 name=VLAN60
add dhcp-server=10.0.0.5 disabled=no interface=VLAN80 local-address=10.9.0.254 name=VLAN80
add dhcp-server=10.0.0.5 disabled=no interface=VLAN20 local-address=10.6.0.254 name=VLAN20
add dhcp-server=10.0.0.5 disabled=no interface=VLAN10 local-address=10.5.0.254 name=VLAN10

Также есть правило srcnat для назначения 10.x.0.0/16 на 10.0.0.0/16, потому что без этого, по какой-то причине, весь трафик через IPSec туннель появляется на другой стороне с исходящим IP-адресом WAN!

Правил NAT, которые объясняли бы, почему DHCP-пакет, который должен идти от 10.6.0.254, появляется на удаленном конце с источником 10.5.0.254, у меня нет.

Я не использую мост.

sjoram Guest	#9 0 04.08.2017 12:32:00 bump Есть мысли, кто-нибудь? Это баг или я что-то пропустил в настройках?

dgnevans Guest	#10 0 06.09.2017 12:26:00 По моему опыту, нет необходимости добавлять local-address= в dhcp relay. Всё отлично работает и без этого. У меня похожая настройка для всех VLAN. Во-вторых, не вижу причины для упомянутого правила srcnat. Что вы пытаетесь этим добиться?

Читают тему

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