Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
AP-шки не транслируют, если нет маршрута по умолчанию., wifiman
 
У меня дома очень много устройств, около 200 на текущий момент, примерно половина проводных, половина по Wi-Fi. Я использовал сеть 192.168.100.1/24 с pfSense. Сегодня вечером я должен получить еще 120 умных ламп Philips Wiz. Это заставит меня использовать хотя бы /23. В предвкушении этого, вчера вечером я переключился на 192.168.100.1/22 в pfSense. Я перезагрузил все точки доступа. Все работало отлично, как я и ожидал. Все проводные и беспроводные устройства работали нормально, хотя я еще не использовал расширенное пространство IP-адресов. Затем мой муж вернулся домой и спросил меня, сможем ли мы управлять освещением, если у провайдера пропадет интернет. Вопрос был особенно актуальным, потому что у провайдера сегодня вечером плановое обслуживание. Я с гордостью ответил, что это будет работать нормально, нужно просто заставить смартфон оставаться подключенным к Wi-Fi даже без интернета. Я отключил интерфейс WAN в pfSense и продемонстрировал управление освещением без облака для нескольких уже настроенных ламп Philips Wiz. Это работало как и ожидалось несколько минут. Затем мой телефон S22 Ultra отключился от Wi-Fi. В настройках Wi-Fi ни одна из моих SSID не вещалась. На ноутбуке Windows была та же ситуация. Затем они начали вещать снова, ненадолго. И так далее. Я был довольно удивлен, так как в прошлом успешно оставался подключен к Home Assistant во время сбоев интернета - реальных, а не смоделированных. Я попытался максимально упростить сеть, уменьшив количество точек доступа с 6 до одной. Я сбросил ее к заводским настройкам. Я откатил ее от бета-прошивки 6.7.10 до производственной 6.6.78. Я пересоздал SSID. Ничего из того, что я делал, не могло создать конфигурацию, которая позволила бы телефонам или ноутбуку оставаться подключенными к Wi-Fi. Наконец, я откатил конфигурацию pfSense обратно к исходному /24 и снова перезагрузил точки доступа. Тогда все заработало отлично, даже когда провайдера не было в сети. Кажется, что мои устройства Wi-Fi могут работать независимо от облака, если я использую /24, но не /22. Та же проблема с /23. Что может вызывать эту проблему? Нужно ли внести какие-либо изменения в конфигурацию контроллера в Unifi где-то? Или это ошибка? Стоит отметить, что конфигурация сети довольно плоская. Нет VLAN. Все коммутаторы не управляемые (и были сброшены вручную, когда требовались изменения конфигурации роутера). Я использую 6 точек доступа в конфигурации mesh (2 проводные, 4 беспроводные), но я не думаю, что mesh является фактором здесь, так как это работает отлично с /24, и даже одна точка доступа не работает с конфигурациями /22 и /23. Я приложил файл поддержки сети.
 
Почти логично, что pfSense не устанавливает маршрут по умолчанию, ведь куда ему тогда направлять пакеты? Два варианта: установить маршрут, принять и отбросить пакеты, или не устанавливать маршрут и не тратить ресурсы на ненужный сетевой трафик. Они выбрали второй вариант. Ни один из вариантов не идеален. ИМХО, pfSense стоит предупреждать об этой ситуации при отключении интерфейса WAN. Вместо этого появляется только общее предупреждение: "Не забудьте отрегулировать диапазон DHCP-сервера, если это необходимо после применения." которое показывается каждый раз при изменении интерфейса. Ни слова о том, что, возможно, потребуется изменить и маршруты.

Не понимаю, зачем Unifi AP перестают транслировать, когда отсутствует маршрут по умолчанию. Может быть, есть какая-то техническая причина, но звучит как ошибка, так как большинство других устройств могут работать и без маршрута по умолчанию.
 
Ого, это действительно интересно. Я использую pfSense уже много лет, и, кажется, никогда не пытался повторить твой сценарий, поэтому раньше такого не видел. Никогда не думал, что DHCP может не выдавать шлюз по умолчанию, если WAN отключен.
 
Я выяснил причину. Когда отключаешь интерфейс WAN в pfSense, клиенты получают IP-адрес и маску сети по DHCP, но не получают маршрут по умолчанию. Эта имитация сбоя провайдера отличается от реального сбоя провайдера. Я ещё раз провёл тест: оставил интерфейс WAN включённым в pfSense, но отключил модем, и в этом случае клиенты получают маршрут по умолчанию. Отсутствие маршрута по умолчанию вполне приемлемо для моих проводных клиентов Windows и проводных Raspberry Pi. Они по-прежнему могут успешно использоваться в проводной локальной сети, например, для разрешения локальных имён хостов из DNS-сервера pfSense, для доступа к контроллеру Unifi и так далее. К сожалению, отсутствие маршрута по умолчанию не подходит для точек доступа Unifi. Это привело к ситуации, в которой я оказался. Мне кажется, что они по крайней мере должны транслировать свой SSID и позволять локальным беспроводным клиентам подключаться и работать в локальной подсети. Очевидно, что отсутствие маршрута по умолчанию в DHCP-сервере было не намеренным. Мне следовало имитировать сбой провайдера, используя умную розетку Z-Wave, подключённую к модему, а не отключая интерфейс WAN в конфигурации роутера pfSense. Я даже не вспомнил, что настраивал эту умную розетку. Слишком много устройств между IP, Yolink, Z-Wave. Home Assistant в настоящее время перечисляет 339 устройств, и общее число вырастет до 460 сегодня и, вероятно, превысит 500 к концу недели.
 
Ну вот, я сбросил все к заводским настройкам. U6-Lite поставил в домашнем офисе, проводное подключение, и заново его адаптировал. Выключил мешинг на AP6. Отключил интернет в pfSense. Он использует только /24. Перезагрузил pfSense, все неконтролируемые коммутаторы и U6-Lite. Всё та же проблема. Телефон не видит ни один SSID. Контроллер показывает примерно 50 IoT-устройств, подключенных к 2,4 ГГц. Похоже, мешинг вообще не при чём, как я и предполагал.
 
Я все еще могу сбросить к заводским настройкам 4 или 5 из 6 устройств, и проверить их с 1-2 подключенными AP, питающимися от сети, но с выключенной mesh-сетью, просто чтобы исключить, что дело в mesh-соединении. Заметил, что у контроллера есть опция "Отключить" AP, которой я никогда не пользовался. Попробовал это на AP в mesh-сети. Но это все равно не позволило отключить mesh на AP, подключенных по сети. Кажется, сброс к заводским настройкам – единственный выход.
 
Ну, придется забыть про APs в контроллере, а потом отключить меширование. Но в твоем случае меширование нужно.
 
Понял. Контроллер раньше позволял отключать меш даже при наличии downlink AP, но теперь не позволяет. Наверное, чтобы меш не ломался, но в данном случае это жуткая морока. Сейчас делаю сброс к заводским настройкам, вздыхаю.
 
В твоём случае не получится, я имею в виду, что тест был некорректным, потому что ты выключил APs в мешевом режиме, но мешинг оставался включённым.
 
И как бы ты посоветовал это сделать? 4 из 6 точек доступа работают в комнатах без Ethernet. Они не могут функционировать без mesh. Единственный способ, который я знаю, чтобы "отключить mesh" — это аккуратно удалять эти работающие в mesh точки доступа из контроллера в правильной последовательности, что приведет к их сбросу к заводским настройкам. И потом отключить mesh и на 2 проводных точках доступа тоже. Есть ли какой-нибудь более простой способ?
 
Сетка будет продолжать влиять на эту проблему, если вы полностью отключите меширование в контроллере. Простого выключения точек доступа (APs) будет недостаточно, чтобы изменить поведение.
 
Нет, у меня 6 точек доступа, которые нужно покрыть на всю мою квартиру. 2 из них проводные — AP1 и AP2. Есть 3 mesh-цепочки, организованные следующим образом: AP1 -> AP4 -> AP5, AP1 -> AP6, AP2 -> AP3. Все они NanoHD, за исключением AP6, который U6-Lite. Я выключил все точки доступа, кроме AP1, чтобы исключить влияние mesh-сети в проблеме, но оно всё равно происходило. Похоже, это проблема при загрузке. Когда я восстановил WAN-соединение в моём роутере, проблема не исчезла. Точки доступа всё равно не транслировали, пока я вручную не зашёл в контроллер и не заставил их перезагрузиться. Тогда всё решилось. Похоже, точки доступа начинают вести себя странно при загрузке без Интернета.
 
Выключи монитор подключения, если он тебе не нужен. Возможно, я неправильно тебя понял, но кажется, у тебя только одна точка доступа, и 5 не используются.
 
Я переключил монитор подключения на пользовательский IP-адрес 192.168.100.1, который является LAN IP для pfSense. Та же проблема. Я вернулся к /24, выключил Интернет и перезагрузил всё. На этот раз точки доступа не транслировали, по крайней мере, об этом сообщали телефоны и ноутбук. Странно, но контроллер показывал, что около 50 IoT Wifi устройств онлайн, подключены к 2.4 GHz SSID. Но телефоны не видели ни моей 5 GHz, ни 2.4 GHz сети. Это другое поведение, чем то, что я видел вчера. Похоже, что проблема может быть не связана с пространством LAN IP-адресов, а скорее только с тем, что у провайдера нет связи. К сожалению, я не продвинулся в разгадке того, почему это происходит. Мой следующий шаг - поменять проводной NanoHD в офисе с бесшовным U6-Lite в гараже, и посмотреть, изменится ли поведение.
 
Спасибо. Интерфейс контроллера показывает, что это только для mesh AP. Я тестировал конфигурацию только с одним проводным AP, а 5 AP были выключены, но проблема все равно проявлялась. Я не пробовал задавать IP-адрес вручную, но попробую.
 
По-моему, я помню, что "Connectivity Monitor" отвечал за отключение AP, если те не могли связаться с шлюзом. Кажется, это было для беспроводных каналов связи, но у меня были проблемы с ним когда-то, когда провайдер отключался. Память подводит, но, возможно, это имеет отношение к делу.
Страницы: 1
Читают тему (гостей: 1)