Привет, Хабр!

В предыдущей статье рассказывалось, как предоставить техперсоналу доступ в интернет по паролю в любой точке ВУЗа, где есть локальная сеть.

А как же быть простым пользователям, которым пришла ссылка-приглашение на участие в онлайн вебинаре?

А сотням обучающимся в компьютерных классах, у которых ГРАНД-Смета не обновляется через прокси-сервер и обучаются по устаревшей базе смет?

А нескольким участникам онлайн вебинара в компьютерном классе?

И ещё очень много подобных случаев. Конкретно эти все ресурсы не работают через прокси-сервер.

Проблема усугубляется тем, что сегодня вебинары в моде и часто проводятся. Ну и софт чуть ли не ежедневно обновляется. Соответственно, техперсонал (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 и тогда сайт у пользователя корректно загружается. По такому методу работали пару лет.

В конце текста информация обо мне.

Со временем столкнулись с тем, что сайты, коряво работающие через прокси-сервер, всё чаще и чаще меняют 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 сайта (на рис.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 должны быть отключёнными (серые лампочки).

Отключаем ПК от порта 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.