Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
Неожиданные DNS-запросы от Unifi AP, UniFi Network
 
Я смотрел pcap с трафиком к своему шлюзу и заметил, что Unifi AC AP выполняет DNS-запросы каждые 30 секунд. Хотя точка доступа настроена на использование DNS-серверов Google, странно то, что она запрашивает строку, которая соответствует её MAC-адресу. Смотрите приложенный скриншот из Wireshark. Есть идеи, зачем это нужно? Думаю, это, по крайней мере, тест на связь с DNS-сервером. Интересно, что такое поведение наблюдается и при включённой, и при выключенной опции «Enable connectivity monitor and wireless uplink» (Uplink Connectivity Monitor). С уважением, Дэйв.
 
Точки доступа всегда пытаются разрешить имя unifi, даже если IP-адрес задан через set-inform. Думаю, что коммутаторы и USG делают то же самое. Поэтому, на мой взгляд, хорошая практика — убедиться, что DNS-сервер, который обслуживает ваши устройства Unifi, содержит запись для unifi, указывающую на IP-адрес контроллера. Я забыл, какой именно протокол обнаружения на базе стандартов они используют для управления настройками и связью, но это часть этого стандарта.
 
Да, встроенный в USG DNS-ретранслятор автоматически создаёт запись unifi для вас. Если вы не используете DNS на USG, этого не произойдёт — нужно, чтобы DNS предоставлялся где-то ещё в вашей сети. По моему мнению, это стоит гораздо лучше подчеркнуть в документации контроллера Unifi. Очень мало роутеров, которые не могут добавить кастомную запись в свой DNS-ретранслятор — но меня бы не удивило, если бы такие всё же были. Ещё одна причина не использовать их 😀 Скорее всего, таких нет — я предполагаю, что они гарантируют автоматическое определение unifi вне зависимости от изменений в DNS-сервисах USG, ведь это важно для настройки и обслуживания устройств Unifi.
 
У меня есть USG и cloud key в моей локальной сети. Благодаря этому USG разрешает имя unifi на cloud key, предположительно потому, что контроллер так настроил. Я не знаю, как контроллер, который не находится в локальной сети, будет настраивать USG по поводу «unifi». Возможно, он может определить свой интернет-адрес и сделать то же самое. Если у вас нет USG, то контроллер в этом плане не поможет — вы наедине с собой. Насколько я знаю, у моего старого роутера такой функции не было. Кажется, я читал, что планируют добавить полноценную поддержку домена по умолчанию в DNS на USG. Если это действительно сделают, интересно, как это повлияет на разрешение имени «unifi»?
 
Устройства ищут контроллер в первую очередь для отправки статистики и статуса (есть и другие функции, см. ниже). Если вам это не важно, то и не критично. Но нужно понимать, что именно контроллер НЕ начинает общение с крайними устройствами — они сами «звонят домой» контроллеру, и только после установления соединения контроллер может отправлять им изменения конфигурации и прочее. Поэтому важно, чтобы ваши точки доступа, коммутаторы и USG могли найти контроллер — а основной способ это сделать — искать «unifi» в DNS. К сожалению, протокол общения устройств и контроллера нигде полностью не описан, по крайней мере, я не встречал такого. Всё вышеизложенное основано на многолетнем опыте работы с Unifi, наблюдениях за его поведением и комментариях разработчиков на форумах. Было бы здорово, если бы существовала технонотка или FAQ с подробным описанием взаимодействия этих компонентов — с этим я полностью согласен.

Некоторые функции, такие как band steering или блокировка клиентов, действительно требуют, чтобы контроллер работал. Это ещё один момент, который отчаянно нуждается в FAQ или технонотке (если, конечно, такая не появилась за последние пару месяцев — я с середины октября был не слишком активен). Годами ходило мнение: «контроллер нужен только для статистики или портала», но со временем выяснилось, что некоторые функции зависят от его работы. На мой взгляд, это очень важно, и это должно быть оформлено в виде таблицы в документации контроллера, где в начале было бы что-то вроде «Когда нужно держать контроллер запущенным» или что-то похожее.
 
Похоже, это происходит именно потому, что твой контроллер не работает постоянно. Поэтому AP пытается его найти. Возможно, если бы контроллер был включён и работал, AP бы не пыталась его искать. Но если DNS-запрос действительно пытается узнать IP-адрес твоего контроллера (вероятно, потому что ты делал set-inform с его IP), тогда я не понимаю, зачем он пытается разрешить его как DNS-имя.
 
Что мне непонятно — зачем мне это вообще нужно. Контроллер может найти usg и aclite и настроить/управлять ими. Зачем мне это делать в обратную сторону? Какую функцию это добавляет? Где это всё описано? Насколько я понимаю, контроллер нужен только для изменения конфигураций или сбора данных (каким-то другим способом, кроме snmp). Я ошибаюсь?
 
Если вы хотите, чтобы устройства находили контроллер (когда он запущен), то да, именно это и нужно сделать.
 
Я не понимаю твой ответ. Я запускаю контроллер (редко) на ноутбуке. Мой DNS-сервер — это Raspberry Pi с установленным pihole, который, по сути, представляет собой dnsmasq, блокирующий разрешение доменных имён рекламы для более чем 100 тысяч рекламных сайтов. Ты хочешь сказать, что мне нужно убедиться, что DNS моей внутренней сети разрешает неквалифицированное имя «unifi» и указывает на компьютер, на котором запущен контроллер, независимо от того, запущено ПО контроллера в данный момент или нет?
Страницы: 1
Читают тему (гостей: 1)