Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
Фильтрация контента ломает локальное разрешение DNS с нашими AD-серверами., wifiman
 
Контроллеры домена на одной подсети, клиентские ПК — на другой. DHCP на UDM Pro, DNS провайдеры указывают на контроллеры домена. PTR записи добавляются в DNS с каждым клиентом, IP автоматически присваивается корректно. Контроллеры домена обрабатывают всё локальное разрешение имён, а форвардер указывает обратно на UDM для внешних ресолверов. Это работало годами без проблем. Наша AD домен — “corp.companyname.com”. Включение фильтрации контента на подсети клиентских ПК полностью ломает эту DNS настройку. Через пару секунд после включения начинается дичь. На моём ПК PDQ Inventory начал отмечать каждый ПК как активный (хотя несколько были выключены, ноутбуки на удалёнке и т.д.). Один за другим, все ПК сообщали о внешнем IP, который я не узнал. Все с одним и тем же. После нескольких минут "что за хрень происходит", я выяснил, что IP, который сообщался, соответствовал нашему провайдеру хостинга, который управляет доменом “companyname.com”. Внутри ничего не работало как надо: странные таймауты, мои CNAME записи для локальных сервисов разрешались до нашего веб-сайта с ответами 403 Forbidden, и разрешение имён практически полностью перестало работать. Выключение фильтрации контента вернуло всё обратно к нормальному состоянию. После нескольких поисков я нашёл несколько отчётов о подобных проблемах, датируемых тремя годами назад, например, вот этот: https://community.ui.com/questions/Unifi-Content-Filtering-breaks-AD-DNS/dee561ab-616e-498c-a719-a7f2c47c8732?page=1. Кажется, фильтрация контента перехватывает DNS запросы и заменяет их чем-то... Я не знаю чем. Он убирает суффикс и портит всё. У кого-нибудь в Ubiquiti тестируют функции перед выпуском? Кажется, есть несколько затяжных проблем, которые сохраняются в разных релизах, и это не маленькие, странные баги. Они серьёзно мешают функциональности.
 
Точно. Я осознал, что это больше хлопот, чем стоит. Использование 1.1.1.1 для семей (1.1.1.3) в качестве внешнего DNS-разрешителя – тоже неплохой вариант.
 
Не потому что они не пересекают WAN.
 
Автор поста указал, что DC и клиенты находятся в разных подсетях. Если UDM осуществляет маршрутизацию между этими подсетями, не является ли это причиной перехвата DNS-запросов к DC?
 
Понял – поэтому я и советовал отказаться от бесплатной функции DNS-перехвата Unifi с фильтрацией контента и перейти на Cleanbrowsing или Umbrella, используя его DNS-форвардеры MS. Не очень нравится, как UBNT реализовал бесплатный тарифный план с ограничением скорости Cleanbrowsing без индикатора ограничений при наведении курсора.
 
Ему нужно использовать Windows Server для DHCP и DNS, он в Active Directory.
 
Помни, Unifi автоматически применяет DNS-перехват и перенаправление на CleanBrowsing.org для фильтрации контента, поэтому не уверен, поможет ли установка DNS-переадресатора на UDMP в данном случае. Очевидно, это не нужно, если ты используешь встроенную функцию фильтрации контента на UDMP. Если удалить все DNS-переадресаторы и включить фильтрацию контента только на VLAN, где расположен твой DNS-сервер, это сработает. Конечно, пользователи будут жаловаться, что "это не работает", и будут страдать от ограничения скорости, но технически это будет работать. Я бы рекомендовал использовать встроенную реализацию DNS-перехвата Unifi с платным API-сервисом Cleanbrowsing.org только для домашних пользователей/сетей. НАСТОЯТЕЛЬНО рекомендую зайти на www.cleanbrowsing.org и подписаться на один из их небольших тарифов, чтобы начать — это очень выгодно, и вы получите МНОГО функций. После настройки отключите всю "фильтрацию контента" на сетевых устройствах Unifi, где вы её включили, а затем измените DNS-переадресатор на DNS-серверы CleanBrowsing согласно их инструкции. Мы являемся MSP для Cleanbrowsing, потому что я много раз проходил этот путь с и без этого для множества клиентов, от маленьких до очень больших. Надеюсь, это поможет, Майк.
 
@FrankNicklin То же самое думал. Не понимаю, почему служба DNS Windows не обрабатывает локальные запросы в первую очередь.
 
Не должно быть так. Основной DNS клиента — это AD-сервер, и на него не должно влиять фильтрация контента, если они находятся в одной сети или VLAN. Если нет, то да, фильтрация контента может мешать. Я всегда настраивал это так, как вы и @RobbieH показывали, и доступ клиентов к AD никогда не был проблемой. Если у вас были проблемы с фильтрацией контента, то что-то еще не так.
 
Очень интересно. Извини, но решения для тебя у меня нет. Я никогда не работал с фильтрацией контента на Unifi. Скриншот не нужен, я предполагаю, что у тебя он есть, раз работает без участия шлюза, но у тебя настроена ли зона прямого поиска для твоего внутреннего FQDN, верно? Опять же, я предполагаю, что да, раз работает без шлюза.
 
Вот это точно моя конфигурация. DNS-форвардер указывает на UDM для внешних запросов. Если бы я настроил внешний DNS-сервис фильтрации контента на своем WAN-порту, то всё бы работало, потому что любой запрос изнутри сети будет перенаправляться на UDM. Просто так получилось, что встроенные фильтры в UDM также фильтруют внутренний трафик, перехватывая все DNS-запросы (а не только те, которые должны разрешаться внешне).
 
То, что он написал выше, верно. Вы добавляете форвардер в Windows DNS, чтобы запросы внешних IP-адресов направлялись к выбранному вами сервису. Это выглядит вот так: У меня все вызовы DHCP и DNS направляются на мой Windows-сервер. Для DNS у меня форвардер, который указывает на мою коробку pfSense, а в этой коробке pfSense настроен NextDNS. У меня нет шлюза Unifi, поэтому я не могу это протестировать, но возможно, вы сможете добавить шлюз в свой форвардер так же, как я сделал это, и это "может" вернуть блокировку Unifi в игру. Если попробуете, сообщите нам, потому что мне нужен ответ, чтобы передать его, когда этот вопрос снова возникнет.
 
Я не рекомендую использовать встроенный "Content Filtering", так как Unifi использует бесплатный API для Cleanbrowsing.org. Эта бесплатная служба ограничена Cleanbrowsing по скорости, и, по моему мнению, Ubiquiti об этом не заявляет. Я знаю это не понаслышке, так как мы пострадали с одним крупным клиентом, и я в итоге выяснил, что делает Cleanbrownsing с бесплатным доступом. Cleanbrowsing очень недорогой и предоставит фильтрацию контента на основе профилей с огромным количеством категорий / контроля контента — чего нет в бесплатной версии. Также Unifi реализует бесплатную версию, используя DNS-перехват на UDMP, что не очень предсказуемый метод, особенно если у вас есть внутренние DNS-сервисы. Сейчас вы можете включить "Content Filtering" только для VLAN, где расположены ваши DNS-серверы —> это, по сути, будет работать как мы это делали, НО вы должны отключить фильтрацию контента на остальных VLAN, иначе вы будете получать ошибки перенаправления 404. Опять же, это скорее обходной путь, так как Unifi реализует DNS-перехват. Если бы вы использовали Cleanbrowsing или даже Umbrella, вы бы просто перешли к вашим MS DNS-серверам и добавили IP-адреса перенаправителей для DNS-серверов Cleanbrowsing / Umbrella, и тогда всё. Сеть – это просто сантехника в этот момент (вы бы не включали параметры фильтрации контента на Unifi в этот момент). Надеюсь, это поможет, и дайте мне знать, если вам нужна дополнительная информация.
 
Да, я как раз собирался это сказать, прочитав про фильтрацию контента в UDM. Похоже, лучше будет использовать сторонний сервис и настроить кастомный DNS-провайдер на уровне WAN. Фильтрация всего локально кажется излишней, сложной и гораздо более проблемной.
 
Спасибо за быстрый ответ. Я понимаю, как работает фильтрация контента, но похоже, я неверно предположил, что фильтрация будет производиться на самом краю сети, а не внутри. Все ПК получают IP-адрес от DHCP UDM, который также устанавливает DNS-серверы на DNS-серверы домен-контроллеров. Я думал, что фильтрация будет реализована путем замены (или перехвата) нашего внешнего DNS-провайдера, а не внутреннего. Хотя бы можно было бы добавить небольшое предупреждение, что "Это может не работать так, как ожидается, если используется свой DNS внутри сети".
 
Фильтрация контента перенаправляет DNS на cleanbrowsing.org, это сделано намеренно, если у вас включено. Вот что я делаю: основной DHCP от сервера AD с основным DNS, установленным на сервер AD для аутентификации пользователей. Затем в настройках DNS сервера, перенаправляю DNS на UDMPro, где можно включить фильтрацию контента, так как это теперь DNS шлюза, а не локальный DNS, влияющий на клиентские ПК.

Но есть одно большое "но": cleanbrowsing.org ненадежен. Пользователи сообщают о постоянных сбоях в интернете, но на самом деле это сбои разрешения DNS, которые для конечных пользователей выглядят как отключение интернета. cleanbrowsing.org также блокирует легитимные сайты, например, банковские, что уже приводило к серьезным проблемам у клиентов.

Эта проблема длится уже некоторое время, и честно говоря, я сейчас отключил эту функцию, потому что она больше хлопот доставляет, чем стоит. Если вам действительно нужна фильтрация контента, поищите платное решение с надежным DNS.
 
Вот как работает фильтрация контента. Она перехватывает DNS, чтобы фильтровать в соответствии с соответствующими списками доменов. То, что вы испытываете, ожидаемо. Я понимаю, что это не то, что вы хотите, но так работает. Не вините Ubiquiti в своем непонимании принципов работы функции. Вместо этого попробуйте спросить, как съесть и пирог, и пирог сохранить. Есть несколько способов обойти эту проблему. Если вы непременно хотите использовать фильтрацию контента, предоставляемую шлюзом, вам, возможно, не повезет. Вы можете попробовать создать на шлюзе DNS-переадрес домена, который указывает на ваши DC для вашего локального домена, и включить фильтрацию контента. Я не уверен, сработает ли это раньше фильтра контента или нет, поэтому, если вы попробуете, сообщите, что получилось. Другой метод — использовать свой собственный DNS-ловушку, такой как Pihole, NextDNS или AdGuard Home (даже АНБ использует инструменты для DNS-рекламной фильтрации, подобные этим). Отключите фильтрацию контента и установите ваши upstream-разрешители на вашем AD-сервере, чтобы они указывали на ваш DNS-фильтр (я использую Pihole). Альтернативно, вы можете перенаправить всех ваших клиентов на DNS-фильтр и настроить условную переадресацию (если поддерживается) для отправки запросов к локальным доменам на ваши DC. Подумайте об этом и решите, как хотите идти дальше. Снова, не уверен, сработает ли добавление переадресного домена к шлюзу в сочетании с фильтрацией контента, но если вы не хотите управлять своим собственным DNS-рекламным фильтром, я бы попробовал. В противном случае вам потребуется запустить пару ВМ для запуска Pihole или чего-то подобного.
Страницы: 1
Читают тему (гостей: 1)