Университет: как разрешить доступ к сайту по URL в любой точке сети
Привет, Хабр!
В предыдущей статье рассказывалось, как предоставить техперсоналу доступ в интернет по паролю в любой точке ВУЗа, где есть локальная сеть.
А как же быть простым пользователям, которым пришла ссылка-приглашение на участие в онлайн вебинаре?
А сотням обучающимся в компьютерных классах, у которых ГРАНД-Смета не обновляется через прокси-сервер и обучаются по устаревшей базе смет?
А нескольким участникам онлайн вебинара в компьютерном классе?
И ещё очень много подобных случаев. Конкретно эти все ресурсы не работают через прокси-сервер.
Проблема усугубляется тем, что сегодня вебинары в моде и часто проводятся. Ну и софт чуть ли не ежедневно обновляется. Соответственно, техперсонал (2 человека) физически в один день не успеет десяткам пользователям и обучающимся провести вебинары и обновить софт. Как быть?
Если не читали предыдущую статью, объясню как устроен выход в интернет в локальной сети для лучшего понимания происходящего.
Рис. 1 — Схема локальной сети.
В локальной сети (рис. 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 и тогда сайт у пользователя корректно загружается. По такому методу работали пару лет.
Мои предыдущие статьи:
В конце текста информация обо мне.
Со временем столкнулись с тем, что сайты, коряво работающие через прокси-сервер, всё чаще и чаще меняют 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, если они через прокси-сервер нормально не работали, обновления не выкачивались и т.д.
Рис. 2 — Обновлённая схема локальной сети после замены шлюза на ZYXEL USG Flex 100W.
На этом всё.
Дальше будут примеры настроек правил файрволла в шлюзе, разрешающего доступ к определённым сайтам по 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) без поддомена.
Рис. 3 — Добавление прямого URL сайта.
Далее добавим ещё профиль с URL с поддоменами по маске (рис. 4).
Рис. 4 — Добавление URL сайта по маске.
Если не добавить сайт по прямой ссылке (рис. 3) без поддоменов, то такой сайт открываться не будет, даже если есть профиль с URL с маской (рис. 4). Не игнорируйте этот момент.
Объединяем созданные профили с URL сайтов и добавляем в общую группу (рис. 5).
Рис. 5 — Создание группы адресов.
Переходим в файрволл (Безопасность > Политики) и там отключим политики (правила) №1 (LAN1_Outgoing) и №10 (WAN_to_Device).
Рис. 6 — Файрволл, отключение правил №1 и №10.
Политика №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).
Рис. 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 должны быть отключёнными (серые лампочки).
Рис. 8 — Окончательный перечень политик.
Если нужно разрешить ещё доступ к сайтам по 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).
Рис. 9 — Добавление URL в исключения.
После этих настроек ГРАНД-Смета наконец-то смогла успешно обновиться. Вебинары тоже заработали, звук и микрофон перестали отваливаться.
При использовании такого сценария, как в этой публикации, необходимо, чтобы у ПК в качестве ДНС-сервера был указан 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.
