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

Mikrotik PPTP/Proxy-ARP и DHCP

Mikrotik PPTP/Proxy-ARP и DHCP, RouterOS

qtm

Guest

07.02.2014 06:17:00

Всем привет! У нас возникла реально странная проблема. Ситуация такая:
1 x DHCP сервер (какой-то Windows) (диапазон 10.0.0.50-10.0.0.100)
1 x Mikrotik (DHCP выключен, стандартный диапазон 192.168.88.0/24) — это сеть, на которой работает VOIP оборудование.

Когда мы подключаемся по PPTP к Mikrotik и пытаемся получить доступ к VOIP устройствам в диапазоне 192.168.88.0/24, это работает только если включён Proxy-ARP, что вроде бы нормально.

Но вот проблема: при включённом Proxy-ARP DHCP сервер перестаёт раздавать новые IP-адреса в сети ПК 10.0.0.0/24, и через некоторое время сеть ПК становится крайне нестабильной.

Есть у кого идеи? Спасибо!
Will

klaparp Guest	#2 0 20.07.2014 19:56:00 У меня такая же проблема. Ты её решил? /HW

CblP

Guest

22.07.2014 05:55:00

Перехватите трафик, и вы увидите, что DHCP-сервер на самом деле нормально выдает адреса клиентам. Проблема в том, что mikrotik отвечает на ARP-запрос от клиента, когда тот проверяет, занят ли предлагаемый IP. Если отфильтровать эти ответы, всё будет работать нормально. У меня была такая же проблема пару дней назад, и именно мост отправлял эти ARP-ответы, так что мне пришлось использовать фильтр моста.

bajodel Guest	#4 0 22.07.2014 07:16:00 Извините, я не понял.

CblP

Guest

22.07.2014 10:44:00

Посмотри на этот снимок, он всё объясняет: https://yadi.sk/d/Va7dWJbmX6tzX В общем, DHCP работает нормально, потому что клиент получает предложение. Чтобы убедиться, что IP не занят, клиент посылает ARP-запрос на этот IP и в нормальной ситуации не получает ответа. Mikrotik отвечает на этот запрос своим MAC, и клиент «думает», что IP уже занят, поэтому снова запрашивает у DHCP-сервера новый адрес — и это происходит по кругу. Как видишь, это ломает работу DHCP. Такое происходит при любых настройках в свойствах моста: proxy-arp включён, выключен, reply-only — неважно. Возможно, это баг, а может, так и должно работать — я не до конца понял логику этой настройки. В любом случае, я просто отфильтровал этот ответ в фильтре моста — он продолжает генерироваться, но не уходит на порт DHCP-клиента, и у меня всё работает нормально.

bajodel

Guest

22.07.2014 15:16:00

Глядя на этот захват, я немного запутался:
Пакет-01) HostA [исходный IP 0.0.0.0 MAC 20:e5:64:f1:89:0a (motorola?)] -> широковещательный dhcp discover
Пакет-02) HostB [исходный 10.107.4.1 MAC 00:21:91:a0:83:0d (dlink?)] -> уникаст HostA dhcp offer
Пакет-03) HostA [исходный 0.0.0.0 MAC 20:e5:64:f1:89:0a (motorola?)] -> широковещательный dhcp request
Пакет-04) HostB [исходный 10.107.4.1 MAC 00:21:91:a0:83:0d (dlink?)] -> уникаст HostA dhcp ack
Пакет-05) HostA [исходный MAC 20:e5:64:f1:89:0a (motorola?)] -> широковещательный arp запрос (gratuitous)
Пакет-06) ..не относится..
Пакет-07) ..не относится..
Пакет-08) HostC [исходный MAC 02:5d:90:af:0d:9d (локально-администрируемый)] -> уникаст ответ gratuitous arp предупреждение (дублирование адреса)
Пакет-09) HostC [исходный MAC 02:5d:90:af:0d:9d (локально-администрируемый)] -> широковещательный запрос gratuitous arp предупреждение (дублирование адреса)
Пакет-10) HostA [исходный IP 0.0.0.0 MAC 20:e5:64:f1:89:0a (motorola?)] -> широковещательный dhcp Decline

Похоже, что предупреждение даёт HostC (некорректный MAC?), а не сам dhcp-сервер. MAC-адреса, судя по всему, изменены, иначе dhcp-сервер — не Mikrotik. Единственное, что я понял точно — это то, что я ничего в этом никогда не понимал.

CblP

Guest

22.07.2014 16:00:00

Проблема в пакете 8, который отправляется интерфейсом моста Mikrotik (хост C) всем, что к нему подключено, включая порт, к которому подключён хост A. DHCP-сервис действительно работает на хосте B и функционирует нормально. Хост C (tik) создаёт проблемы для хоста A.

rextended

Guest

22.07.2014 19:47:00

Думаю, проблема не в proxy arp. Проблема в отсутствии маршрута/шлюза/NAT на одной из сторон, но без просмотра реальной конфигурации я не могу ничего конкретного сказать. Например, если IP MikroTik — 192.168.88.1, VoIP — 192.168.88.77, а PPTP REMOTE IP — 10.10.10.10, просто ОТКЛЮЧИТЕ PROXY-ARP и добавьте одно правило NAT типа:
/ip firewall nat
add action=src-nat chain=srcnat dst-address=192.168.88.77 src-address=10.10.10.10 to-addresses=192.168.88.1
Но без точных деталей конфигурации это лишь гипотеза.

CblP

Guest

23.07.2014 04:04:00

Я почти уверен, что проблема автора вопроса — именно то, что я описал выше, потому что у него неполадки с DHCP в сети 10.x.x.x. Он не говорил, что хочет, чтобы сеть 10.x.x.x общалась с сетью 192.x.x.x, где было бы уместно предложение с NAT.

bajodel Guest	#10 0 23.07.2014 05:07:00 Ты знаешь, происходит ли эта проблема тоже, когда Mikrotik выступает в роли DHCP-сервера (на бридж-интерфейсе или всегда)? Есть ли уже открытый тикет в поддержку Mikrotik?

CblP

Guest

#11

23.07.2014 05:28:00

У меня нет настроения тестировать ту же конфигурацию с tik в роли DHCP, но, как мне кажется, это неважно, потому что проблема в том, как tik обрабатывает ARP-запросы. У меня есть два tiks: версия 6.12 и 6.15, и проблема возникает только на 6.15, так что, скорее всего, это баг, введённый недавно, который, возможно, исправят в 6.17. Но сейчас обновляться не собираюсь — правило «не трогай то, что работает». Если кто-то заинтересован воспроизвести проблему, дайте знать, когда появятся результаты.

bajodel Guest	#12 0 23.07.2014 08:11:00 Согласен! Ты уже очень помог, как только смогу, попробую протестировать в лабораторной среде. Здесь же сообщу о всех результатах.

DaveBrowning Guest	#13 0 13.02.2017 10:08:00 Не могли бы вы привести пример фильтра моста, который вы настроили?

CblP Guest	#14 0 03.03.2017 11:40:00 Я с тех пор избавился от своего маршрутизатора tik и теперь использую CHR + коммутатор, так что мой «мост» теперь находится на коммутаторе, а не на mikrotik. Из-за этого я не смогу воспроизвести точный сценарий без больших усилий, но, как мне кажется, дело было примерно в этом: /interface bridge filter add action=drop arp-gratuitous=yes arp-opcode=0x2 chain=output dst-mac-address= 01:02:03:04:05:06/FF:FF:FF:FF:FF:FF mac-protocol=arp out-bridge=bridge-local src-mac-address= 0A:0A:0A:0A:0A:0A/FF:FF:FF:FF:FF:FF где 01:02:03:04:05:06 — это пострадавший DHCP-клиент, а 0A:0A:0A:0A:0A:0A — mikrotik bridge. Не проверял, но идея должна быть понятна.

Читают тему

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