Мобильные устройства не могут получить IP-адрес от DHCP-сервера (Windows Server 2012r2)

Мобильные устройства не могут получить IP-адрес от DHCP-сервера (Windows Server 2012r2), UniFi Network

ARMeyer

Guest

18.05.2020 19:47:00

Моя проблема, возможно, не связана с UniFi, но начиная с прошлого четверга (14 мая), после крупного сбоя у нашего провайдера Spectrum Networks, ни одно мобильное устройство (iPhone, Android и как минимум один ноутбук с Windows, присоединённый к домену) не может получить IP от нашего DHCP-сервера (Server 2012r2). Судя по истории трафика, всё работало нормально ещё в среду. Единственное, что я поменял — обновил прошивки нашего USG, AP-Pro и AP-AC-Lite, а также программу UniFi до последних версий. Обновления прошивок и даты их установки такие:
USG – с 4.4.44.5213844 до 4.4.51.5287926 (1:05 утра 13.05.20) – логи показывают, что телефоны передавали и принимали данные.
AP-Pro – с 4.0.54.10625 до 4.3.13.11253 (11.05.20)
AP-AC-Lite – с 4.0.54.10625 до 4.3.13.11253 (11.05.20)
UniFi Controller обновился с версии 5.10.26 до 5.12.66 12.05.20 и затем до 5.12.72 14.05.20, когда я понял, что что-то не так.

На DHCP-сервере я ничего не менял. Добавил свой телефон с фиксированным IP — пингуется, но сетью (принтеры, интернет) пользоваться не может.

У нас простая Wi-Fi сеть с 2 сетями: одна административная, другая — гостевая. Обе не должны, но при этом не дают устройствам выйти в интернет.

Два ноутбука на Windows подключаются к сети без проблем, один же нет. У устройств, которые не подключаются, адреса 169.254.x.x, и они отображаются в UniFi Controller как клиенты с присвоенными ими IP. В настройках сети DHCP стоит в положении «none».

Я перезагружал систему (USG и точки доступа), перезапускал DHCP на сервере, выключал всё и включал заново, пробовал подключать каждую точку доступа отдельно. Настройки в контроллере не менял. Честно говоря, я совсем растерялся — не понимаю, как решить проблему.

Спасибо,
Аарон

jonathangroves Guest	#2 05.06.2020 19:03:00 Ну, гостевая сеть теперь не работает на точке доступа с версией 4.0.42. Значит, проблема либо в USG, либо, скорее всего, в Cloud Key. Предвидится долгие выходные...

jonathangroves

Guest

05.06.2020 17:46:00

Забыл добавить — когда половина точек доступа не работала, это касалось ТОЛЬКО гостевой сети (Guest SSID). Есть ещё скрытая сеть «Office» с защитой WPA. На неё не распространяется гостевой доступ, и она находится в другой VLAN. Эта сеть работала нормально (можно было войти в интернет) на всех точках доступа.

jonathangroves

Guest

05.06.2020 17:38:00

Обновление: Вчера съездил на объект, и примерно половина AP вообще не работали... Я мог подключиться и получить валидный IP на гостевой сети, но трафик не проходил. Если подключался с нового устройства — такая же история, и оно даже не пыталось перенаправить на страницу портала через Cloud Key. По одному менял настройки в контроллере, чтобы проверить, что изменится. Добавил IP Cloud Key в Pre-Authorization Access в разделе Guest Control — и вдруг устройства начали выходить в интернет, а неавторизованные перенаправлялись на страницу портала.

Однако сегодня понял, что добавил этот IP в Post-Authorization Restriction. Тут вообще непонятно, почему это сработало, или может просто после "RE-Provision" всем AP обновились настройки. Учтите, что эти AP находятся в той же подсети, что и Cloud Key.

Похоже, отключение "Block LAN to WLAN..." решило проблему с DHCP. Но при этом на Dashboard всё равно появляются таймауты и ошибки DHCP. Раньше такого не замечал, даже после последних обновлений.

В одном из форумов видел, что у некоторых не показывался гостевой портал, и они говорят, что даунгрейд AP решил проблему. Сегодня утром откатил одну из основных точек до версии 4.0.42, чтобы проверить. Если баги появятся снова, а на старой версии AP будет всё хорошо — это точно докажет, что в новом софте большие косяки.

jonathangroves

Guest

04.06.2020 13:32:00

@ARMeyer Да, если бы это было только в моём офисе — было бы не так плохо, с этим я могу справиться. Но когда кемпинг продаёт ваучеры своим клиентам, они ожидают, что всё будет работать без сбоев. В итоге я весь выходной был под стрессом и рвал на себе волосы... За последние 3 года, что мы там были (в этом кемпинге), всё работало довольно хорошо, с редкими мелкими проблемами, но ничего серьёзного, как сейчас. Понимаю, что система не может быть на 100% безупречной, но когда никто вообще не может получить IP — это серьёзно. Что меня больше всего злит, так это почти полное молчание со стороны UBNT. Судя по другим постам, эта проблема тянется уже несколько месяцев после выхода версии контроллера 5.12.66.

@alynn Спасибо за дополнительную информацию. Если у вас в системе есть Security Gateway от UBNT (как у меня), и вы включаете «Block LAN to WLAN...», то MAC-адрес Security Gateway автоматически добавляется в список исключённых устройств. При отладке я проверил, что этот MAC совпадал с MAC моего шлюза (и действительно совпал). Вчера днём я выключил «Block LAN to WLAN...» в контроллере. Сегодня поеду на объект посмотреть, решит ли это проблему. Позже отпишусь, как вернусь. Спасибо вам обоим за ответы!

alynn

Guest

04.06.2020 03:38:00

DHCP-серверы, соответствующие стандарту, должны отвечать DHCP-клиентам широковещательной рассылкой только в том случае, если клиент установил флаг broadcast в своих запросах. Такие устройства, которые не могут принимать uniсast, сейчас крайне редки (середина 90-х и раньше), и тем более редко встречаются с поддержкой беспроводной связи. Так что практически все беспроводные устройства с момента появления 802.11b поддерживают unicаst-ответы.

Однако я замечаю, что до сих пор существует много программного обеспечения для DHCP-серверов, которое не соответствует стандартам и просто отправляет широковещательные ответы вне зависимости от настроек.

Поэтому обязательно нужно добавить MAC-адрес ethernet-порта вашего DHCP-сервера (чаще всего это интернет-шлюз) в список устройств, исключённых из блокировки LAN-to-WLAN multicast и broadcast, чтобы эти пакеты не блокировались точками доступа.

ARMeyer

Guest

03.06.2020 21:09:00

Вау! Это жёсткая ситуация! Я благодарен, что у меня небольшой офис, и у меня единственного есть устройства, которые постоянно зависят от Wi-Fi, хотя у нескольких ещё есть ноутбуки, и я действительно пытался решить проблему, пока им не пришлось подключаться. Твоё описание проблемы помогает мне понять, что произошло. Я включил опцию «Block LAN...» прямо перед обновлением контроллера до версии 5.12.66 и в этот короткий период проблемы не было. После обновления проблема началась, я заметил это на следующее утро. С тех пор, как обновился до 5.12.72 (где проблема всё ещё была), я больше не обновлял и не включал эту настройку, и у меня пока никаких проблем не возникало.

jonathangroves Guest	#8 03.06.2020 19:55:00 Я всегда держал включённой функцию «Block LAN to WLAN Multicast and Broadcast Data» для гостевой сети, и проблем не было. Но после обновления UniFi Controller с версии 5.10.25 до 5.12.66 29.04.20 с DHCP начались перебои. А на следующем загруженном уикенде (около 400 человек) система совсем встала: никто не мог получить IP в гостевой сети. Потом я начал терять управление всеми 20 AP (потому что они получают DHCP на VLAN управления). Представьте, какой кошмар, когда контроллер не может управлять точками доступа и коммутаторами! 31.05.20 (естественно, в праздник) обновился с 5.12.66 на 5.12.72, потому что почти никто не мог получить IP. И, похоже, это немного помогло с проблемами DHCP... В последнее время всё равно поступают жалобы на периодические проблемы с DHCP: например, устройство подключается, но не получает адрес. Но если отключить и снова включить Wi-Fi на устройстве или переключиться на другую точку доступа, IP в итоге появляется. Вот такой бардак! Клиенты недовольны, а у меня нет конкретного решения. Спасибо за совет выключить «Block LAN to WLAN Multicast and Broadcast Data» — попробую. Меня уже достали баги UBNT, и мне очень хочется попробовать точками доступа cnPilot от Cambium. Моя конфигурация: USG 3P - 4.4.51.5287926 (отвечает за DHCP) 4 - UniFi 8 POE-150W - 4.3.13.11253 20 - UniFi AP-AC-Mesh-Pro - 4.3.13.11253 VLAN 1 (Native) - Corporate = управление для коммутаторов и точек доступа VLAN 10 - Guest = гостевой SSID

Читают тему (гостей: 1)