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

Написать статью подтолкнул комплекс проблем.

Проблема №1. В настоящее время перед первым использованием свежеустановленную ОС, программу, прошивку устройства настоятельно рекомендуется обновить или активировать в интернете, в большинстве случаев эти рекомендации невозможно проигнорировать, устройство попросту не заработает, пока не обновишь/активируешь.

Проблема №2. Большинство устройств и софта требуют стабильный, быстрый интернет с минимальным пингом и задержками, без прокси и ограничений. При использовании прокси некоторый софт (пример 1, пример 2) не может обновиться. Ему нужен интернет без прокси и обязательно шустрый или софт исчерпает таймаут на подключение к серверу обновлений.

Проблема №3. Такая же беда есть с проведением вебинаров, видео/аудио потоки стабильно работают только при прямом доступе в интернет, без прокси.

Техподдержка софта и вебинаров об этом знают, в FAQ и в общении предупреждают, что нужен "нормальный" интернет.

Ещё пример тут, обратим внимание на первую и четвёртую рекомендации.

Сразу же первая рекомендация (Скриншот 1):

Используйте последнюю версию рекомендуемых браузеров.

Разве её проигнорируешь? Хорошо, не игнорируем, обновим браузер, к счастью ещё обновляются через прокси.

Четвёртая рекомендация уже жёсткая (Скриншот 2):

4. Если возникают проблемы со звуком/видео и вы находитесь на рабочем месте:
Отключите корпоративный VPN/proxy. Если это невозможно, подключитесь к вебинару (из письма-приглашения или по ссылке) через мобильное приложение Webinar.

Прокси невозможно отключить, у нас интернет раздаётся только через прокси и строго по учёткам (Схема 1).

Проблема №4. Кроме таких случаев, встречались некоторые ОС и софт, они при установке/активации не предоставляют возможность прописать прокси. Доступны настройки, связанные только с IP-адресом, маской, шлюзом и ДНС на сетевой карте.

В учреждении (Схема 1) интернет не раздаётся на динамических или статических IP, как на домашних роутерах дома, все выходят в интернет по учёткам через прокси. Больше нет других способов выйти в интернет. Прокси логин и учётку берёт из Active Directory (на схеме не отображено).

Проблема №5. Что получается тогда? Необходимо предоставить техперсоналу ИТ доступ в интернет по учётке без прокси для обновления ОС и софта, но с этим тоже вопрос:

• какая железка или софт это умеет?

• по какой технологии реализовать? По PPPoE, L2TP?

• напрячься и поднять RADIUS-сервер и подружить со шлюзом, но с каким?

• есть смысл дальше работать с Active Directory и Windows, если его разработчик ушёл из России и парк рабочих ПК массово переходит на Linux и Астра Линукс?

• есть ли шлюзы, которые умеют в себе хранить базу учёток? Или в любом случае нужен выделенный сервер для работы с базой учёток?

Проблема №6. Раньше был PPPoE-сервер на железке Cisco с выделенным физическим RADIUS-сервером. Техперсонал создавал PPPoE-подключение, вводили свой логин и пароль и выходили в интернет. По завершении всех работ удаляли подключение, чтобы пользователи/обучающиеся не вышли в интернет по чужому логину, если кто-то из техперсонала случайно сохранит пароль в созданном подключении.

Это было неудобно и подключение забывали удалить. Так работали годами до тех пор, пока провайдер не сменился, а с ним поменялись и ключевые настройки интернета. Админ, настраивавший PPPoE и RADIUS-серверы уволился, поэтому некому было внести новые интернет-настройки в шлюз. Вдобавок, руководство хотело списать железку Cisco, как устаревшую модель. Модель вроде 2811.

В общем, PPPoE-сервер больше не существовал в учреждении, поэтому его на схеме 1 нет. В кратчайшие сроки для поддержания работоспособности парка ИТ техперсоналу была предложена альтернатива - проставлять выделенный статический IP с разрешённым выходом в интернет. Это оказалось небезопасным, статическим IP любой мог воспользоваться, если студент подглядит какими IP пользовался техперсонал. Либо техперсонал забывал его удалить по завершении всех работ с ПК. Отдельно были случаи, что после удаления статического IP, он вновь незаметно возвращался в настройки сетевой карты после перезагрузки ОС. Потом, когда прописывали статику на других ПК, он не ставился из-за конфликта IP и техперсонал не мог найти, где его "оставил", т.к. парк ПК был большим.

Проблема №7. Даже при отсутствии альтернатив, к PPPoE-серверу на Cisco 2811 всё равно не хотелось возвращаться:

• Много манипуляций для создания PPPoE-подключения.

• Случайно сохраняют пароль и забывают удалить PPPoE-подключение.

• Были слухи, что вендоры от него отказываются, устарел и тому подобное. Шлюзы Элтекс, Zyxel не исключение, в них PPPoE-сервера нет.

• Cisco 2811 не был шустрым, задержки трафика при загрузке/отправке данных были больше, чем при использовании статического IP.

Проблема №8. Поднимать на физическом сервере ОС с PPPoE, L2TP-сервером не вариант, много суеты. Необходимо регулярно:

• менять батареи в ИБП, запитывающего сервер;

• своевременно проверять состояние накопителей, пока бэдами не посыпались.

• продувать от накопившейся пыли;

• менять термопасту и износившиеся кулеры;

• поддерживать работоспособность сплит-систем в серверной.

Проблема №9. Это всё требует внимание, которое не оплачивается, зарплата больше не становится. И с учётом того, что другие комплектующие сервера не будут ломаться (ОЗУ, мамка, проц, контроллеры).

Нужно что-то другое и попроще, чтобы персоналу было легче подключаться к интернету, был шустрым, с минимальными задержками. Чтобы шлюз настраивался удобно, с первого раза. Это же так поднимет общую производительность труда и всем настроение.

А что вы думаете? Прошу в комменты.

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

Где проблема встречается?

Проблема №10. В крупном образовательном учреждении. Таких устройств в день набирается не менее 3 штук. В здании коридоры длинные и много этажей, неудобно технику таскать в ремонтный кабинет отдела ИТ, в котором есть интернет для переустановки софта без прокси. Теряем время на перенос системника. Да и потом, если системник возвращаешь пользователю, на месте выясняется, что забыли обновить одну программку из интернета, а она не обновляется через прокси, потом ещё доустановить свежие дрова на принтер, плоттер, сканер, МФУ из интернета. Прокси блокирует некоторые сайты с драйверами, если их не оказалось на официальном сайте производителя.

Проблема №11. В этом же учреждении в компьютерных классах, проводятся компьютерные курсы по изучению различных компьютерных программ, операционных систем и много другого. Чтобы обучающиеся не учились по устаревшим программам, все программы регулярно обновляются до актуальных версий техперсоналом. В одном классе ПК по 16-38 шт. Все ПК не потащишь в ремонтный кабинет.

Поэтому техперсонал ходит к этим ПК и им там на месте нужна учётка доступа в интернет без прокси. Чтобы технику туда-сюда не таскать. На месте авторизовался, обновил софт из интернета. Молодец, задача выполнена.

Про флешки забудьте, учреждение не покупает и изнашиваются быстро.
Техперсонал восстанавливать софт из образа не желает, софт сильно меняется или начинка ПК поменялась после ремонта и надоедает переписывать образы каждый раз. Им проще всё с нуля быстро всё установить, но увы, для этого нужен хороший интернет на месте.

Как решать эту проблему?

Как это должно выглядеть? Техперсонал вводит легкозапоминаемую команду из одной строки для создания интернет-подключения на любой ОС, далее запросит логин и пароль. После успешной авторизации логина и пароля выпустит в интернет. По завершении всех работ созданное интернет-подключение автоматически удаляется после перезагрузки ОС или отключения/включения сетевой карты, не оставляя следов. Если техперсонал опять забудет это сделать, то интернет по таймеру прекратится через время.

Пробовал L2TP-сервер поднять на отечественном роутере Элтекс ESR-21 и в дальнейшем с ним работать, он умеет хранить в себе учётки без внешнего RADIUS-сервера. На компах процесс создания L2TP подключения к интернету похож на предыдущий PPPoE.

Но техперсонал отказался создавать и удалять вручную L2TP подключения, т.к. постоянно забывали удалить подключение. Ну отказались от L2TP и хорошо, при активном использовании интернета через одно L2TP подключение одно ядро из нескольких ядер ЦПУ роутера Элтекс нагружалось. Не критично, но хотелось бы, чтобы одно ядро не нагружалось более 6%, а остальные были бы по 0%.

Поэтому искал ещё варианты.

Из доступных вариантов доступа в интернет по паролю подошёл Captive Portal, на Zyxel именуется "веб-аутентификация". Большую роль на выбор оказали успешно реализованные проекты, связанные с системой гостевого доступа в интернет по Wi-Fi. Там узнал множество ключевых данных, подходившие для организации парольного доступа.

Веб-аутентификация есть на всех межсетевых экранах Zyxel ATP / USG Flex. На снятых с производства моделях тоже есть:

• NXC5200 / 2500 / 5500

• ZyWALL 110 / 310 / 1100

• USG 110 / 310 / 1100 / 2200

• VPN 50 / 100 / 300 / 1000

На более ранних моделях может отсутствовать!

Сейчас приступаем к пошаговой настройке веб-аутентификации на 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.

Создаём правило (рис.1), где требуем авторизацию у пользователей с любым IP (IP-адрес источника), подключённых к интерфейсу "lan1" и обращающихся на любой IP-адрес назначения.

Интерфейс "lan1" в дефолте у USG Flex 100W это порты P3, P4 и P5, у других моделей интерфейсы и порты могут отличаться и при желании настраиваются в КОНФИГУРАЦИЯ -> Сеть -> Интерфейс -> Порт.

В некоторых случаях авторизацию можно запрашивать не только по интерфейсу, но и по IP-адресу источника или по IP-адресу назначения, либо вместе. При необходимости можно по расписанию включать правило.

После глобального активирования (рис.2) веб-аутентификации правила действуют снизу вверх. Поясняю:

• трафик пользователя проверяется сначала с правила "Default", не требующее авторизацию (unnecessary) у любого пользователя с любым IP (IP-адрес источника), устанавливающего соединение с любым IP (IP-адрес назначения), на любом внутреннем интерфейсе (кроме WAN);

• далее трафик пользователя проверяется по правилу №1, в котором требуется авторизация (force) у пользователей, подключённых к интерфейсу "lan1" и им предложится страница авторизации. В интернет выпустит только после успешного ввода логина и пароля;

• трафик пользователей остальных интерфейсов ("lan2" и другие) проигнорируются правилом №1. Других вышестоящих правил нет, значит последним подходящим по критериям правилом "Default" выпустит в интернет, не требуя авторизацию.

Создаём учётки техперсоналу (рис.3). Особое внимание уделим полям "Время аренды" и "Период повторной аутентификации".

Время аренды - это первичное время действия учётки после авторизации. Если её не продлевать в личном кабинете, учётка автоматически завершит свою работу (выход из системы) и доступ в интернет прекратится. Шлюз просто заново потребует ввести логин и пароль.

Это помогает в случаях, если техперсонал дрова выкачал и забыл завершить авторизацию и ушёл, а интернет оставил рабочим на компе. Если учётку не продлевали, шлюз сам завершит работу учётке через установленное время, на рис.3 это - 120 мин.

Период повторной аутентификации - максимальный срок действия учётки после авторизации. Это максимальное время работы с учёткой с учётом нескольких продлений аренды. Шлюз сам завершит работу учётке через заданное время, на рис.3 - это 360 мин и снова потребует ввести логин и пароль.

Допустим, ОС обновлялась более 120 мин и техперсонал продлевал аренду, а потом по завершении всех работ забыл завершить авторизацию и ушёл, интернет оставил рабочим на компе. И, если кто-нибудь, на этом компе воспользуется забытым интернетом и чужую учётку продлит и продлевает в дальнейшем, шлюз сам завершит работу учётке через установленное время, на рис.3 это - 360 мин. Сколько ни продлевай втихую аренду, шлюз без вариантов завершит работу учётки строго через 360 минут и снова запросит логин и пароль.

В целях усиления безопасности можно применить принудительную смену пароля, ограничение количества одновременных входов в систему, ограничение количества попыток входа в систему и так далее (рис.4).

В веб-интерфейсе нет списка заблокированных учёток и средств разблокировки. Это возможно только в CLI. Справочник команд в CLI тут на стр.459. Скриншот команд для работы с учётками на рис.5.

Чтобы USG Flex 100W не конфликтовал с действующим шлюзом на схеме 1, меняем дефолтный 192.168.1.1 на 192.168.1.10 (рис.6) у интерфейса "lan1".

Следом отключаем DHCP-сервер (рис.7), чтобы по схеме 1 использовать прежний DHCP-сервер.

Перезагружаем USG Flex 100W. После перезагрузки убедитесь, что USG Flex 100W пингуется по новому IP 192.168.1.10 и пускает на веб-интерфейс.

По схеме 2 коммутатор подключаем к USG Flex 100W в порт P3, он же "lan1". Провайдер в порт P2 ("WAN").

На ПК в классе ещё раз пингуем 192.168.1.10. Если успешно, отключаем прокси (рис.8), далее набираем следующую команду в cmd на Windows (рис.9):

После того, как шлюз поменялся на 192.168.1.10 (рис.10), должна сама появиться страница авторизации (рис.11). Но, в зависимости от ОС, может не появиться. Тогда нужно запустить браузер Firefox и там будет предложение открыть страницу входа в сеть (рис.12).

В других браузерах приглашения нет, нужно самому набрать любой http сайт, например, www.ru или http://www.ru и перейдёт на страницу авторизации (рис.11).

После успешной авторизации отобразится "личный кабинет" учётки (рис.13).

По завершении всех работ с ПК техперсонал должен нажать на "Выход из системы" и выключить/включить сетевую карту, чтобы ранее изменённый шлюз 192.168.1.10 "забылся" и заново пропишутся динамические настройки с DHCP-сервера.

Или перезагрузить ПК, после перезагрузки шлюз 192.168.1.10 тоже забывается и сетевая карта прописывает новые динамические настройки IP-адреса с DHCP-сервера согласно схеме 2.

Соответственно, после откл/вкл сетевой карты или перезагрузки ОС интернет не работает на этих ПК, пока заново вручную не пропишут команду изменения шлюза (рис.9).

Если техперсонал забывает выйти из системы или удалить шлюз, то рано или поздно аутентификация на ПК завершается автоматически и интернет больше не работает или попросит админа завершить работу авторизованной учётки в веб-интерфейсе USG Flex 100W, после этого интернет тоже перестанет работать. Но самое главное, что на ПК не остаётся никаких следов интернет-подключения, чего и добивались.

Вывод:

Проблема №1 не устранена к сожалению, это мировой тренд и диктовка разработчиков.

Остальные проблемы почти устранены:

• Техперсонал получает быстрый интернет по паролю с минимальными задержками, в котором всё нормально загружается, без ошибок загрузки файлов. Ядра ЦПУ роутера Zyxel мизерно нагружаются (проблемы №2, №3 и №5 устранены).

• Проблема №4 частично устранена. Не у всех устройств есть CNA-браузер или возможность запустить браузер перед установкой/активацией. Ведь логин и пароль вводится только в браузере.

• Забытый техперсоналом работающий интернет всё равно прекращает работу через указанное время или после откл/вкл сетевой карты или перезагрузки ПК (проблемы №6 и №7 устранены).

• Интернет-подключение самоаннулируется без следов после откл/вкл сетевой карты или перезагрузки ПК (проблемы №6 и №7 устранены).

• Возможность завершить работу авторизованной забытой учётки в веб-интерфейсе шлюза (проблемы №6 и №7 устранены).

• Не нужен отдельный сервер с аутентификацией и контролем доступа в интернет (проблемы №8 и №9 устранены).

• Шлюзы Zyxel ATP и USG Flex выполнены в 1U форм-факторе (модели ATP/USG Flex 100 настольного/настенного исполнения), конфигурация сохраняется в одном файле небольшого размера, читается текстовым редактором. Не нужно бэкапить всю ОС или дисковый раздел куда-нибудь на надёжное файловое хранилище. Избавляет от регулярной возни с ИБП, накопителями, чисткой от пыли, заменой термопасты, сплит-системами (проблема №8 устранена). В идеале это всё нужно, но хотя бы так часто возиться не требуется и железка Zyxel работает без этого всего, если денег не дают на замену батарей ИБП или закупку сплит-системы.

• Веб-аутентификация быстро настраивается на шлюзах Zyxel (проблема №9 устранена).

• В случае проблем с основным провайдером, техперсонал авторизуется по своей второй учётке и выходят в интернет через резервного провайдера*.

* Об этом будет рассказано в другой публикации.

А что вы думаете? Прошу в комменты.

На сегодня всё.

Об авторе:

Кто я? Меня зовут Александр. 17 лет профессионально занимаюсь СКС и сетевым оборудованием. Получил много опыта работы с сетевым оборудованием различных вендоров. Приветствую простоту и дружелюбность конфигурирования/мониторинга сетевого оборудования, ответственность вендора за качество выпускаемой продукции и готовность исправлять недостатки, чтобы не тормозили сдачу новых проектов в назначенные сроки. Меня можно встретить и лично пообщаться в Телеграме - @NSanchez13, так что, если будут вопросы, комментарии, мнения – милости прошу.

#доступ в интернет по паролю.