Привет, Хабр!
А как же быть простым пользователям, которым пришла ссылка-приглашение на участие в онлайн вебинаре?
А сотням обучающимся в компьютерных классах, у которых ГРАНД-Смета не обновляется через прокси-сервер и обучаются по устаревшей базе смет?
А нескольким участникам онлайн вебинара в компьютерном классе?
И ещё очень много подобных случаев. Конкретно эти все ресурсы не работают через прокси-сервер.
Проблема усугубляется тем, что сегодня вебинары в моде и часто проводятся. Ну и софт чуть ли не ежедневно обновляется. Соответственно, техперсонал (2 человека) физически в один день не успеет десяткам пользователям и обучающимся провести вебинары и обновить софт. Как быть?
Если не читали предыдущую статью, объясню как устроен выход в интернет в локальной сети для лучшего понимания происходящего.
В локальной сети (рис.1) доступ в интернет предоставляется по учётным записям через прокси-сервер, но некоторые сервисы и вебинары не работают через прокси-сервер или очень коряво и техперсонал использует резервный доступ в интернет без прокси-сервера через шлюз 192.168.1.10 с веб-аутентификацией, но строго по своей учётке. Учётку никому не раздаёт.
Резервный доступ выручает техперсонал, им удобно, капризные веб-страницы корректно загружаются. Операционки обновляет, выкачивает обновления и апдейты, вебинары хорошо работают, но это всё только под учётной записью техперсонала, так как резервный интернет предназначен только для техперсонала.
Пользователям и обучающимся не выдаётся, т.к. у них интернет через прокси-сервер и в интернет выходят после авторизации на прокси-сервере, прописанного в настройках браузера. В таком случае веб-трафик (порты 80,8080,443) ходит через прокси-сервер, а при использовании других портов трафик уходит на шлюз с IP 192.168.1.1 с функционалом NAT и межсетевого экрана (файрволл, брандмауэр).
Интернет через шлюз 192.168.1.1 запрещён, поэтому сервисы, использующие порты, отличные от 80, 8080, 443 не работают, в том числе и видео-аудио потоки вебинаров. Такой специфичный трафик необходимо разрешать разрешающими правилами файрволла на шлюзе.
Почему доступ в интернет запрещён через шлюз?
Если пользователи и студенты отключат прокси-сервер в браузере, то веб-трафик пойдёт к шлюзу. Ведь шлюз авторизацию не запрашивает и получается, что любой сможет к нему подключиться и выйдет в интернет, если интернет был бы разрешён на шлюзе. Именно по этой причине доступ в интернет через шлюз запрещён.
Чтобы сайты, криво отображающиеся через прокси-сервер, отображались корректно, добавляем URL сайта в исключения прокси-сервера (рис.9) и тогда они, минуя прокси-сервер, загружаются через шлюз 192.168.1.1.
Далее на шлюзе правилами файрволла разрешаем доступ до проблемного сайта по его IP и тогда сайт у пользователя корректно загружается. По такому методу работали пару лет.
Мои предыдущие статьи:
Настройка сервиса авторизации гостевой Wi-Fi сети
Делаем гостевую сеть Wi-Fi сеть в ВУЗе, часть 2. Функции для гостевой Wi-Fi сети
Как блокировал контент для взрослых
Сервис Гео-IP по версии Zyxel: зачем нужен, функциональность, как настроить?
Университет: как техперсоналу получить полный доступ в интернет в любой точке сети
В конце текста информация обо мне.
Со временем столкнулись с тем, что сайты, коряво работающие через прокси-сервер, всё чаще и чаще меняют IP. И поддомены сайта часто оказываются с другим IP, не таким, как у основного.
Например, сегодня у этого URL конкретный IP, а завтра админ сайта перезаключил договор с провайдером и получил другой пул IP. Соответственно, сайт получил новый IP. Но об этом узнаём по жалобам пользователей, что у них "полсайта" перестало работать с утра. Пока разберёшься, почему главный сайт совсем не загрузился после Ctrl+R, а во вкладках браузера ранее открытые поддомены чётко работают. Но потом всё банально оказывается - IP сменился только у главного сайта, а в разрешающих правилах файрволла шлюза указаны старые IP.
К примеру, опять эта же самая ГРАНД-Смета, у них в ЧаВо в каждом ответе только URL-адреса указываются. IP нигде не пишут. Ссылка первая, вторая и третья.
Ещё пример, поддомены URL-адресов серверов обновлений Линукс имеют множество IP. Узнать все их IP займёт много времени и возни. Проще прописать готовый URL-адрес с маской (например, *.ubuntu.com), чем выискивать множество IP, которые всё равно "завтра", "послезавтра" поменяются.
Смена IP у веб-ресурсов скорее всего в дальнейшем сохранится, значит логично в правилах файрволла разрешить доступ по URL (FQDN) к сайтам, но шлюз 192.168.1.1 (рис.1) не поддерживает URL-адреса (FQDN) в правилах файрволла. Не создаёт новое правило с разрешением доступа к адресу назначения по FQDN. Этот шлюз - отечественный аппаратный межсетевой экран, производитель и модель пропустим. Не критикуем, пусть дорабатывают. У них и так нет репутации.
Техподдержка приняла заявку на доработку функционала после убедительных живых примеров. Когда это сделают - неизвестно и смогут вообще доработать?
К большому счастью, у нас уже был шлюз Zyxel USG Flex 100W с поддержкой FQDN в правилах файрволла. Им заменили шлюз 192.168.1.1 (рис.2), не поддерживающий FQDN, в локальной сети. Настроили и всё заработало, как хотели. Теперь можно разрешить доступ к капризному вебинару, сайту или веб-узлу по FQDN и по IP, если они через прокси-сервер нормально не работали, обновления не выкачивались и т.д.
На этом всё.
Дальше будут примеры настроек правил файрволла в шлюзе, разрешающего доступ к определённым сайтам по URL-адресам (FQDN). Остальные сайты будут отброшены, всё равно к ним через прокси-сервер подключаются.
Сейчас приступаем к пошаговой настройке веб-аутентификации на Zyxel USG Flex 100W с SFP портом (версия прошивки 5.37(ABWC.0)) в дефолтном состоянии.
Дефолтное состояние (заводской конфиг, конфиг по умолчанию) шлюза можно получить после удерживания кнопки RESET до начала мигания лампочки SYS.
Кабель провайдера подсоединён к WAN порту (порт P2, не SFP) USG Flex 100W. Интернет от провайдера выдаётся автоматически, без настроек и в виде динамического IP. Поэтому в USG Flex никакие интернет настройки не производились. Получили динамический IP - интернет заработал. К локальной сети USG Flex пока не подключаем.
Подключаем ПК в порт "P3" на шлюзе USG Flex 100W, в адресной строке браузера набираем http://192.168.1.1, авторизуемся с дефолтным логином admin и паролем 1234.
Если это первое подключение к веб-интерфейсу шлюза,
то запустится мастер быстрой настройки в котором настраивается подключение к интернету и другие настройки. Этот процесс в статье пропускаю во избежание большого количества букв, сразу приступаем к настройке разрешения доступа к сайту по URL.
Первым делом добавляем прямой URL сайта (на рис.3) без поддомена.
Далее добавим ещё профиль с URL с поддоменами по маске (рис.4).
Если не добавить сайт по прямой ссылке (рис.3) без поддоменов, то такой сайт открываться не будет, даже если есть профиль с URL с маской (рис.4). Не игнорируйте этот момент.
Объединяем созданные профили с URL сайтов и добавляем в общую группу (рис.5).
Переходим в файрволл (Безопасность > Политики) и там отключим политики (правила) №1 (LAN1_Outgoing) и №10 (WAN_to_Device).
Политика №1 (LAN1_Outgoing) разрешала весь трафик из зоны LAN1 в зону WAN, по сути устройства зоны LAN1 подключались к устройствам в зоне WAN, то есть к веб-ресурсам в интернете. После деактивации политики №1 устройства в зоне LAN1 лишатся доступа в интернет (к зоне WAN). При условии, что у самой нижней политики Default" стоит действие "deny".
Политика №10 (WAN_to_Device) разрешает трафик из зоны WAN к шлюзу USG Flex 100W (зона ZyWALL) определённым сервисам (узнать можно подведением курсора мыши на профиль Default_Allow_WAN_To_ZyWALL в колонке Сервисы, политика №10. Или в КОНФИГУРАЦИЯ > Объекты > Сервисы > Группа сервисов > имя профиля "Default_Allow_WAN_To_ZyWALL"). Скриншот не привожу, т.к. в ранних версиях прошивок перечень сервисов отличается от сервисов в нынешней версии. Поэтому, если не используется доступ к шлюзу из интернета, то рекомендуется отключить политику №10 (рис.6) просто из целей соображения безопасности. К настройке URL эта политика никакого отношения не имеет. Просто перестраховываемся при настройке USG Flex 100W с нуля.
Добавляем новую политику (рис.7).
В новой политике разрешили устройствам зоны LAN1 к зоне WAN, к веб-ресурсам, присутствующие в профиле "Dostup_po_URL", созданного на рис.1,2,3. Остальные веб-ресурсы не будут работать благодаря нижнему правилу "Default" с действием "deny".
Для удобства и читаемости, или, просто соблюдая хороший тон, новая политика должна быть №1 и выше политики №2 или в самом верху (рис.8). Бывшая политика №1 (LAN1_Outgoing) стала №2. №10 (WAN_to_Device) стала №11. Политики №2 и №11 должны быть отключёнными (серые лампочки).
Если нужно разрешить ещё доступ к сайтам по IP,
необходимо создать отдельную политику как на рис.7, но с другой группой профилей, в котором будут только профили с IP веб-ресурсов. Профили с IP ресурсами так же создаются как на рис.1 и 2, но вместо FQDN выбирается HOST/RANGE/SUBNET и в группе как на рис.3 выбрать Address вместо FQDN.
Отключаем ПК от порта P3 на USG Flex 100W. Проверяем, что в локальной сети нет других шлюзов с IP 192.168.1.1 и подключаем локальную сеть в порт P3 на USG Flex 100W.
Далее, на ПК в настройках прокси-сервера добавляем в исключения URL, которые нужно загрузить через шлюз, а не через прокси-сервер (рис.9).
После этих настроек ГРАНД-Смета наконец-то смогла успешно обновиться. Вебинары тоже заработали, звук и микрофон перестали отваливаться.
При использовании такого сценария, как в этой публикации, необходимо, чтобы у ПК в качестве ДНС-сервера был указан 192.168.1.1, для того, чтобы в FQDN-кэше шлюза Zyxel USG Flex 100W создалась и хранилась запись DNS-имя+IP-адрес, только при этом условии FQDN корректно работает. Если в локальной сети используете DNS-сервер Windows, тогда в нём нужно настроить DNS пересылку на 192.168.1.1. Не игнорируйте этот момент.
На сегодня всё. Вы бы как сделали? Прошу в комментарии.
Об авторе:
Кто я? Меня зовут Александр. 17 лет профессионально занимаюсь СКС и сетевым оборудованием. Получил много опыта работы с сетевым оборудованием различных вендоров. Приветствую простоту и дружелюбность конфигурирования/мониторинга сетевого оборудования, ответственность вендора за качество выпускаемой продукции и готовность исправлять недостатки, чтобы не тормозили сдачу новых проектов в назначенные сроки. Меня можно встретить и лично пообщаться в Телеграме - @NSanchez13, так что, если будут вопросы, комментарии, мнения – милости прошу.
Полезные ссылки:
#разрешить доступ по имени, #разрешить доступ по ссылке, #разрешить доступ по FQDN, #разрешить доступ по URL, #разрешить по имени сайта, #разрешить по ссылке, #разрешить по FQDN, #разрешить по URL, #разрешить доступ к сайту по имени, #разрешить доступ к ссылке, #разрешить доступ к сайту по FQDN, #разрешить доступ к сайту по URL, #разрешить сайт по имени, #разрешить сайт по ссылке, #разрешить сайт по FQDN, #разрешить сайт по URL, #разрешить сайт, #разрешить ссылку, #разрешить FQDN, #разрешить URL.