На сайте разработчика шлюза есть ряд справочных материалов, достаточно полно освещающих этот вопрос, но часть из них устарела, а некоторые моменты не получили нужного разъяснения.
Основная проблема возникает, когда сервер RDS сконфигурирован как «RD Session Host» — в этом случае пользователи подключаются к сети, используя один исходящий IP-адрес на всех (адрес сервера RDS), что приводит к классической ситуации «кто первый встал, того и тапки». Только в данном случае тапки достаются последнему.
Что у нас есть:
— есть домен AD (пусть будет habr.local);
— сервер RDS на базе Windows Server 2012(r2) сконфигурирован как «RD Session Host»;
— на сервере RDS в качестве браузера используется штатный Internet Explorer 11;
— шлюз на базе Kerio Control (пусть его имя будет kerio-fw).
Описанная схема работает так же и для «классического» терминального сервера на базе Windows Server 2008 R2.
Приступим.
Как уже написано, основная проблема — в том, что пользователи в количестве большем, чем один, пытаются авторизоваться на шлюзе с одного IP-адреса. Для решения этой проблемы разработчики шлюза предлагают несколько способов, точнее — два: использование непрозрачного прокси-сервера, и принудительная авторизация в браузере.
Из них более-менее работает лишь первый — непрозрачный прокси. Увы, далеко не все программы вообще знаю, что такое прокси-сервер, а уж прозрачно авторизоваться в нём — могут единицы.
Часть первая: «Поиск и обретение».
После мучительных попыток скрестить ежа с ужом пришло озарение: схема «один IP -> много пользователей» работать нормально не будет. Стало легче, т.к. обозначился путь выхода: «Свой IP для каждого даром, и пусть никто не уйдет обиженным» .
Логичная для этой ситуации схема VDI нас не устраивала, но интернет быстро подсказал решение: Remote Desktop IP Virtualization.
Коротко: данная технология появилась в Windows Server 2008 R2 и позволяет назначить индивидуальный IP-адрес либо всей сессии пользователя — режим «per-session», либо любому экземпляру запускаемых пользователями программ из списка — режим «per-program».
То, что надо, короче.
Режим настраивается просто: применяем на нужные серверы следующую политику GPO:
Не забываем указать свою подсеть, в которой находится сетевой адаптер, который нужно виртуализировать. Если адаптеров несколько — указываем только один (больше одного не поддерживается).
Замечание 1: по умолчанию «виртуальные» IP-адреса запрашиваются у DHCP-сервера, и большинство (возможно что и все) не-microsoft DHCP-серверы некорректно обрабатывают такие запросы. Т.е. вам нужен включённый в домен Windows-based сервер с ролью «DHCP Server».
Замечание 2: если по каким-то причинам развернуть Windows-based DHCP-сервер не представляется возможным, можно с помощью опять же групповых политик назначить для сервера диапазон IP, из которого он сам себе будет назначать «виртуальные» IP, никого не спрашивая. В этом случае вся ответственность за возможные коллизии лежит на вас.
Замечание 3: Пул адресов DHCP-сервера должен быть достаточным для обеспечения адресами всех ваших «виртуальных» пользователей.
После этого все терминальные пользователи чудесным образом стучаться в шлюз каждый со своим IP-адресом, и дальше уже дело техники и вкусов, как их авторизовать — мануалов достаточно как на сайте разработчика, так и в интернетах.
Но, думаю, есть смысл довести дело до логического конца, и изложить процесс так, как он реализован у нас. Тем более что в процессе этой реализации выявлен ряд проблем, слабо описанных в сети.
Часть вторая
Так как сессиям пользователей IP-адреса назначаются случайным образом, то привязать пользователя в Kerio Control к конкретному адресу возможности нет. Значит, нужно каким-то образом авторизовать пользователя на шлюзе.
При этом стояла задача делать всё максимально прозрачно — никаких окошек запроса логина и пароля, ничего, что бы пользователь мог сделать не так. А то ведь он обязательно сделает всё не так, дай только ему возможность.
К счастью, шлюз Kerio Control легко подключается к домену и поддерживает прозрачную NTLM-авторизацию браузером.
Политика GPO:
Но если есть другие программы, требующие доступа в интернет (мессенджеры, почтовые клиенты, VoIP и т.п.), то налицо небольшая проблема — пока пользователь не перейдёт в браузере на произвольную страницу, и тем самым не авторизуется на шлюзе — не видать ему интернета как своих ушей.
Решение очевидное, и оно описано в документации на сайте разработчика — logon script.
Вот тут была уничтожена неделя рабочего времени (с перерывами на обед).
Dim oIE
Set oIE = CreateObject("InternetExplorer.Application")
oIE.Visible = False
oIE.Fullscreen = False
oIE.Toolbar = True
oIE.Statusbar = True
oIE.Navigate("http://www.google.com/")
WScript.Sleep(30000)
oIE.quitОсобо продвинутые одмины в интернетах используют перенаправление на страницу авторизации шлюза
oIE.Navigate("https://kerio-fw.habr.local:4081/login/?NTLM=1")Дело в том, что указанный скрипт, как и все его модификации в интернетах — не работает корректно в версиях Windows старше 7 (и соответствующих серверных версиях). В зависимости от ритма удара в бубен авторизация либо не происходит, либо окно демонстрируется пользователю (и пугает его), либо зависает процесс iexplore.exe — в общем, всё плохо.
Интенсивным использованием метода «научного тыка» был найден виновник — User Account Control, он же UAC. Так как понижать защищённость системы желания не было, то ещё какое-то время было потрачено на то, что бы убедится — без его отключения скрипт нормально работать не будет. Убедились.
К счастью, изначально были задействованы и настроены Software Restriction Policies (Политики ограничения использования программ), по этому после недолгих моральных страданий было решено пожертвовать UAC-ом во имя светлого будущего.
Dim IE
Set IE = CreateObject("InternetExplorer.Application")
IE.Visible = False
Wscript.Sleep(3000)
IE.Navigate2("https://kerio-fw.habr.local:4081/login/?NTLM=1")
Wscript.Sleep(20000)
IE.QuitDim IE
Set IE = CreateObject("InternetExplorer.Application")
IE.Visible = False
IE.Navigate2("https://kerio-fw.habr.local:4081/logout")
Wscript.Sleep(3000)
IE.QuitВ процессе тестирование выяснилось ещё пару нюансов:
— если назначать запуск скрипта с помощью GPO (logon script), то он периодически не выполнял авторизацию и зависал — возможно, потому что сессии не успевал назначиться IP-адрес, или по какой-то другой причине;
— если пользователь отключался от шлюза по тайм-ауту бездействия, то он понятное дело терял подключение к интернету;
— когда пользователь завершал свой сеанс на терминальном сервере, его IP-адрес мог быть выделен другому вошедшему пользователю до того, как шлюз отключит предыдущего по тайм-ауту.
Всё это привело к схеме, когда для авторизации пользователя на шлюзе создаётся (обновляется) отдельное задание в планировщике задач Windows (средствами GPO), запускающее указанный выше скрипт по триггерами на вход пользователя в систему, на подключение к отключенному сеансу, и на просто периодический запуск (у меня один раз в час). Задание выполняется только при наличии залогинившегося пользователя. Для отключения от шлюза при выходе пользователя используется стандартный скрипт (logoff script), т.к. в планировщике задач нет соответствующего триггера.
Так же в планах (но руки не дошли ещё) на выход пользователя повесить скрипт, отключающий эту задачу, т.к. иначе она каждый час пытается запуститься, но если пользователя нет в системе — пишет в историю ошибку. Хотя страшного ничего в этом нет, но перфекционизм, блин...
Спасибо всем, кто дочитал — надеюсь, этот пост сбережёт вам немного столь ценного нынче времени.
Комментарии (21)
lovecraft
13.11.2015 08:15Принципиальные проблемы с учетом трафика на терминале нужно решать не на шлюзе, а на самом терминале. Ставится какой-нибудь TMeter, котрый умеет логгировать трафик с учетом PID/UID, вроде там можно и трафик ограничивать и т.п. Так проще, потому что, когда уже обезличенный трафик уходит с сервера на шлюз, начинаются костыли и подпорки, чтобы на шлюзе снова привязать трафик к пользователям. TCP/IP не поддерживает авторизации на уровне протокола, поэтому даже Microsoft начинает лепить откровенно временные решения:
— В ISA был совершенно глючный агент, который вполне мог повесить терминал
— В RDP IP Virtualization, вроде бы, нельзя до сих пор нельзя использовать две сетевые карты или каким-то образом привязать пользователей к их адресам на уровне службы RDP (кроме написания своей версии TSVIPool.dll). Т.е. это — временное решение, несмотря на то, что ее ввели в 2008 R2 и до сих пор не убрали.SyavaSyava
13.11.2015 09:44Ставить на каждый сервер свой шлюз – не лучшее в нашей ситуации решение, ибо их сильно больше одного, а пользователей – очень сильно больше ))
В итоге будет дикий кошмар по синхронизации и управлению всем этим хозяйством. Плюс оверхед ресурсов железа и потенциальные проблемы с производительностью и стабильностью.
С агентами тоже не хорошо – ничто не идеально, и любят они в самый неподходящий момент заглючить, а то и сервер подвесить, если повезёт. Есть вирт.машины с сотней пользователей (да, только хардкор) – и как оно там себя поведёт, неизвестно, да и нет желания выяснять.
В общем, чище сервер – крепче спишь )))
Несколько сетевых карт использовать можно (с Win2012), но они должны быть в разных подсетях, и виртуализировать можно только одну. Но для меня это не проблема, ибо одной достаточно. А случайность выдачи IP-адресов сессиям пользователей и компенсируется скриптом авторизации. Костыль, конечно – но работает.
В чём-то даже удобней – нет лишних телодвижений по назначению адреса пользователю, потом его привязке на шлюзе. А при удалении – всё в обратном порядке. Тут же – создал юзера, раскидал по группам, и забыл. Не нужен – удалил.
Касательно временности – поглядим, что будет дальне. В любом случае, оно есть, и оно закрывает мою проблему.
gotch
13.11.2015 08:49Скрипт? А почему просто в Startup запуск IE с домашней страницей ya.ru не вариант?
Kerio умеет только NTLM? А Kerberos?SyavaSyava
13.11.2015 11:56Всё необычное пугает пользователей. А так как есть постоянный процент «новичков» — поток звонков/писем в техподдержку с просьбами «удалить вирус» обеспечен. Проверено. А так да, для каких-то случаев этого достаточно. Более того, как написал в тексте — если нужен только браузер, то вообще ничего запускать не нужно.
Мне нужно было реализовать максимально прозрачный для юзеров и программ процесс, при этом гарантирующий, что информация на шлюзе о пользователях будет актуальной, не возникнет путаницы, когда один случайно работает под учётными данными другого, и других накладок. Отсюда и все извращения со скриптами.
> Kerio умеет только NTLM? А Kerberos?
Умеет. Более того, его и использует для доменных учётных записей. NTLM у них — это скорее некое собирательное название: кто может — использует Kerberos, кто не может — NTLM.gotch
13.11.2015 20:34Да это же терминальный сервер интернета. Залогинился, а вот он перед тобой интернет. Интернет эксплорер, то есть.
У каждого, конечно, свои схемы работы, у нас с автозапуском, но без Керио.
А про индивидуальные ip даже не подозревал, спасибо, интересно.
anton1234
Это все плохо.
Учет трафика на основе ип-адресов, прошлый век. Логон скрипты на vbs, использующие еще и логику с WScript.Sleep(30000).
Вы зло!
SyavaSyava
Спасибо за ваш содержательный ответ. Сразу видно глубокое понимание предмета и «логики WScript.Sleep». Надеюсь на дальнейшие ваши столь же ценные комментарии.
anton1234
Запустим IE при каждом входе пользователя, подождем 3 секунды, чтобы IE успел загрузится и перейдем по ссылке, подождем еще 20 секунд. Ничего не перепутал?
Каждый раз загружаете IE, тратите 23 секунды и при этом может еще и не пройти ваш фокус, если по каким-то причинам потребуется больше времени.
SyavaSyava
Этот процесс выполняется в фоне параллельно обычному процессу старта сессии. Т.е. нет задержки в 23 секунды, если вы это имели ввиду. А так как шлюз в локальной сети, то 20 секунд – это очень оптимистичный запас.
Ещё раз повторюсь – выше изложено решение конкретной проблемы, достаточно часто поднимаемой на профильных ресурсах в сети. Если вы можете подсказать более правильное с точки зрения архитектуры решение данное конкретной проблемы – с удовольствием выслушаю.
Для начала хотя бы порекомендуйте корпоративный шлюз (бесплатный или примерно равной с Kerio Control стоимости и похожий по функционалу), который может фильтровать и учитывать трафик группы пользователей с терминального сервера с одним IP – без скриптов, прокси и прочих атрибутов прошлого века.
F1RST
Оговорюсь сразу, с Kerio Control не работал, но полагаю, что тот же самый Squid или TMG с тем же ProxyInspector, по функционалу не уступят. Если TMG и еже с ним просят денежку и возможно выйдут для компании дороже Kerio, то Squid бесплатен и его настройка — лишь вопрос квалификации админа.
SyavaSyava
Да знаю я их всех, со многими непосредственно имел дело. TMG может (мог) нужное, в силу интеграции с Windows и AD, но уже закрыт и не продаётся. Остальные примерно одинаковы по возможностям, плюс/минус.
Суть не в использовании именно Kerio, у него своих глюков хватает, хотя и чертовски удобен в использовании. Суть в том, что вместо конкретных советов некоторые начинают троллить на тему «скрипты зло, windows плохо, и вообще сейчас в моде ajax и web 2.0».
У меня описана конкретная проблема, и конкретное её решение. Это не филосовский опус о «сравнительном анализе вина», где можно бесконечно растекаться мыслию по дереву.
Да, решение не совершенное с точки зрения архитектуры, но оно работает. Не можешь предложить ничего лучшего – «давай, до свидания» (это я не вам сейчас, а обобщённо, потенциальным желающим пофлудить).
anton1234
У меня коллеги пытаются решить любую проблему двумя способами:
1. Перезагрузить сервер\рабочую станцию.
2. Добавить пользователя в администратора. Как-то раз обнаружил, что всех пользователей добавили в группу Enterprise Administrators.
Некоторые проблемы действительно этим способом решаются.
Но нужно понимать, что тем самым они создают куда более серьезные. Это как лечить головную боль обезглавливанием.
Также и ваше «решение». Игра не стоит свеч. Вы делаете слишком много плохих вещей, достигая своей цели.
Вы написали статью, чтобы поделиться опытом и чтобы кто-нибудь сделал у себя также.
Я критикую ее, делясь своим опытом, и надеюсь, что администраторы хотя бы задумаются над тем, что делают прежде чем скопипастят.
SyavaSyava
Не стоит тянуть за уши не относящиеся к теме аналогии – попахивает пустомельством. Ни перезагрузка, ни добавление кого-либо в администраторы в статье не упоминается. Описано отключение механизма UAC, но на этом сделан акцент и приведено обоснование. Не нравится – не отключай.
> Вы делаете слишком много плохих вещей, достигая своей цели
Судя по всему, я делаю много вещей, которые ВЫ почему-то считаете плохими. Да и то, ни одного разумного довода в пользу их «плохости» пока не прозвучало.
> Я критикую ее
Критика – это тут
https://ru.wikipedia.org/wiki/%D0%9A%D1%80%D0%B8%D1%82%D0%B8%D0%BA%D0%B0
Ваши тексты с критикой ничего общего не имеют.
> делясь своим опытом
Может я что-то пропустил, но ничего внятного из вашего опыта мы пока не услышали – сплошное «бла-бла-бла».
anton1234
Перезагрузки к вашему методу никакого отношения не имеют. Это был пример того как можно решать некоторые проблемы, но как этого делать не стоит.
anton1234
Для веб трафика proxy правильное решение. NTLM SSO авторизацию умеют все браузеры и почтовые клиенты. Я не знаю офисного ПО, которое не умело бы работать с proxy. Плюс к этому windows позволяет настраивать proxy через GPO либо wpad записи.
Если нужен более высокий уровень контроля, то следующий шаг это мониторинг по id процесса, естественно со специализированным ПО на каждом TS и центральным командным центром. Это функционал ПО класса DLP(Data loss prevention), бренды symantec, trendmicro, proofpoint, судя по рекламному буклету теперь и kaspersky.
SyavaSyava
Ооо, понятно. Теоретик detected.
> Я не знаю офисного ПО, которое не умело бы работать с proxy
Если вы чего-то не знаете, это не значит, что этого нет. Хотя можно себя в этом успешно убедить. Ну а если не получится – объявить это плохим, устаревшим и неправильным. Особенно когда это ничего не стоит.
> Если нужен более высокий уровень контроля, то следующий шаг это мониторинг по id процесса, естественно со специализированным ПО на каждом TS и центральным командным центром. Это функционал ПО класса DLP(Data loss prevention), бренды symantec, trendmicro, proofpoint, судя по рекламному буклету теперь и kaspersky.
Спасибо, кэп. Полагаю, ВЫ оплатите нам несколько сотен лицензий на это чудесное ПО, а так же его внедрение и связанные с этим издержки? Таких советов я сам могу вам на «n-лимонов» надавать (я много умных букафф знаю), но извините, некогда – нужно работать с тем, что есть, а не трепать языком про «DLP-системы»
anton1234
Для примера, что из офисного ПО не умеет работать с proxy?
SyavaSyava
Из того, что запомнилось: клиент 3CX Phone Windows, 1С клиентская и серверные части, клиенты интернет-банков, ещё что-то, не помню уже. При этом часть программ формально была способна использовать прокси, но работала при этом «странно» – могла отсутствовать часть функционала, причём эта часть менялась из-за неустановленных факторов от случая к случаю.
Можно конечно ковыряться неделями с каждой программой в поисках причин, подбирать аналоги, что бы не рушить идеалистическую картину, при этом потеряв в процессе половину клиентов (не все готовы оплачивать длительные поиски «священного грааля» своим рублём, особенно в условиях кризиса) – но для меня один «плохой» скрипт сейчас лучше теоретической утопии завтра.
Если бы всё работало идеально – естественно не пришлось бы городить это всё, да и вообще IT-шники вымерли бы как класс. Но на практике всё несколько отличается от обещаний вендоров и сладких речей маркетологов.
anton1234
А какой смысл считать трафик 1С, Банк клиентов и собственной ип телефонии?
Да и все работает, с прокси, просто специалист не смог разобраться с настройкой.
У меня нет задачи переубедить вас, эти комментарии не для того. Вы затронули интересную и действительно востребованную тему и я хочу внести свой вклад.
Мой посыл в том, что трафик учет которого действительно важен, прекрасно работает через прокси. Есть софт который настраивается на работу с прокси чуть сложнее, это те самые банк клиенты и 1с. Все банк клиенты которые настраивал я, а это 90% всех банков России и несколько зарубежных, умеют работать с прокси. Хотя считать сколько трафика ушло на них, на мой взгляд, нет никакого смысла.
Задешево или даже забесплатно, с прозрачной авторизацией и ad интеграцией- это прокси, в частности squid. Будут и графики и квоты, есть бесплатные и платные надстройки к squid.
То что предлагает ТС, это плохо. Решение не эффективно и опасно. Оно считает трафик по косвенному признаку — ip адресу. А также требует наличие и учет этих самых адресов, да еще и скрипту недостаточно прав пользователя, позволю себе два не русских слова, т.к. они наилучшим образом отражают смысл — overhead и overengineering.
SyavaSyava
> А какой смысл считать трафик 1С, Банк клиентов и собственной ип телефонии?
Подмена тезиса. Речь не о подсчёте трафика этих программ, а о том, что они не работали должным образом с прокси-сервером.
> Да и все работает, с прокси, просто специалист не смог разобраться с настройкой
Голословное утверждение, апелляция к очевидности. Без комментариев.
> Мой посыл в том, что трафик учет которого действительно важен, прекрасно работает через прокси
Подмена тезиса, вы опять спорите сами с собой.
> Задешево или даже забесплатно, с прозрачной авторизацией и ad интеграцией- это прокси, в частности squid
Ложная альтернатива. Цель статьи — уйти от прокси в данной конкретной ситуации, а не настроить работу через прокси. А надо это делать, или нет — думаю каждый сам решит для себя.
> То что предлагает ТС, это плохо.
Голословное утверждение, апелляция к очевидности.
> Решение не эффективно и опасно
Голословное утверждение, апелляция к очевидности.
> Оно считает трафик по косвенному признаку — ip адресу
Не более косвенный, чем IP-адрес вашего компьютера. Вот только в отличии от IP-адреса компьютера, пользователь его сменить не может.
> А также требует наличие и учет этих самых адресов
Вы наверное умеете выходить в интернет без IP-адресов? Не поделитесь рецептиком?
> да еще и скрипту недостаточно прав пользователя
Ложь. Что такое UAC — можете почитать в Википедии, там для новичков всё хорошо описано. К права пользователя этот механизм имеет весьма отдалённое отношение.
— Итого:
— Подмена тезиса — 2 раза;
— Голословное утверждение, апелляция к очевидности — 3 раза;
— Ложная альтернатива — 1 раз;
— Прямая ложь — 1 раз.
Диагноз: демагогия. Продолжение дискуссии бессмысленно.