В старые добрые времена Windows Server 2003 и даже раньше, когда нам, системным инженерам, требовалось сделать Terminal Server (TS) доступным из интернета, у нас не было действительно хороших решений. Можно было просто опубликовать сервер через стандартный порт RDP (TCP 3389), или изменить порт на какой-нибудь другой, нестандартный (или стандартный для другого протокола, например SSL, порт TCP 443) – в надежде «спрятать» TS от плохих парней. В любом случае, даже если вы публиковали TS через TCP 443 (и ваши клиенты подсоединялись набирая в терминальном клиенте (TS Client, TSC в дальнейшем) что-то вроде our_org_ts.com:443) – протокол на самом деле оставался тем же Remote Desktop Protocol, RDP.
Заходя подобным образом на ваш our_org_ts.com:443, плохие парни, так же, как и клиенты, видели стандартный logon screen. То есть, была возможность для многообразных атак, начиная от примитивного brute force попыток по подбору имени пользователя и пароля, и заканчивая разнообразными DDoS (как пример – если вы установили задержку на logon screen после нескольких неправильных попыток пароля, то вот вам готовый маленький DDoS – достаточно только неправильно ввести пароль несколько раз, как пользователь заблокирован на какое-то время).
Еще хуже обстояли дела, когда требовалось разрешить доступ из интернета к рабочим станциям в организации. Вы спросите, почему?! – ведь VPN еще никто не отменял! На это я отвечу двумя возражениями:
- VPN дает полный доступ к сети организации, или ее сегменту. Нам это не требуется: все чего мы хотим это чтобы пользователь из интернета работал на своем рабочем компьютере через RDP. Естественно, ограничение доступа можно реализовать сетевыми фильтрами, но я покажу вам способ получше.
- Очень большое количество различных организаций и публичных сетей блокируют все кроме нескольких протоколов – обычно это HTTP(S) и почтовые протоколы. Чтобы не быть голословным, 2 примера: 1) гостиницы; 2) различные организации с правильным админом (еще немного об этом ниже). Таким образом, если вы – консультирующая организация, и ваши работники должны заходить на свои рабочие места из других организаций, то ваш выбор протокола удаленного доступа – скорее всего, SSL.
Но есть же уже SSL VPN решения? Зачем нам что-то еще? Последние два возражения, и мы приступаем, наконец, к сути:
- Еще раз: SSL VPN (как и любой другой VPN) дает вам доступ к сети. Это означает много вещей, например, что вам выдается IP принадлежащий организации, с которой вы соединяетесь (допустим, вы консультант и подсоединяетесь к вашей конторе). Еще это означает, что вирусы, находящиеся на вашей машине (ну хорошо, возможно, находящиеся на вашей машине), получают готовый транспорт в сеть вашей организации – ваш отдел Network Security этому несказанно рад. Ну и напоследок – если вы работаете из другой организации, то ваш компьютер, если вы подсоединились через любой VPN, является сетевым мостом (bridge) между организациями. Этому очень обрадуются админы уже обеих организаций, а также, возможно, органы IP Compliance (Шишков, прости – люблю я очень это слово, но не могу перевести). Не надо говорить, что это несерьезно и таких органов нету: еще в 2004, когда я работал на Украине в одной фармацевтической конторе, наши зарубежные партнеры очччень интересовались такого рода вопросами.
- TS Gateway (TSG), в отличие от VPN, является L7 сервисом по классификации OSI. Это означает, что уровень контроля, учета и отчета принципиально отличается от VPN L3 сервисов. Например, TSG легко отвечает на вопросы куда подсоединился пользователь, сколько времени там провел, сколько байт было передано в обе стороны и т.д. Кроме того, можно разрешать подсоединения, например, только к компьютерам, включенным в определенную группу. Вообще – приведенные примеры только малая толика возможностей предоставляемых TS Gateway.
Я действительно надеюсь, что я заинтересовал читателей этим введением (а скорее – введением в проблему, которую решает TS Gateway). Если так – тогда я надеюсь, что мы скоро встретимся, и я обещаю вам рассказать в цикле статей вот о чем:
- Что нужно для того чтобы установить TS Gateway (prerequisites), а также от каких сервисов в организации он зависит (dependencies)
- Процесс установки. Политики авторизации соединений (Connection Authorization Policy, CAP) и ресурсов (Resource Authorization Policies, RAP): основы
- Интеграция с другими ролями в Windows Server 2008 (R2) Terminal Services: TSWA, TS, RemoteApp
- TS Gateway: внутреннее устройство
- Политики TSG: внутреннее устройство и расширенные сведения
- Мониторинг и отчетность для TS Gateway
- TSG: построение отказоустойчивых и масштабируемых решений
- Еще много о чем, включая мой любимый PowerShell, TSWA, TS, Session Broker, RemoteApps, а также просто рекомендации инженера который занимался развертыванием и эксплуатацией Windows Server 2008 (Longhorn) и даже еще не выпущенного Windows Server 2008 R2 (Win7 Server)
Немного о себе:
Ну, вы уже догадались наверное, где я работаю :). Занимаюсь проектированием и экспериментальным развертыванием новых систем (dogfooding) и попытками (чаще – удачными) превращения их в полноценные сервисы, с передачей другим группам для поддержки. Конкретно о TS Gateway: мой сервис обслуживал около 8000 активных пользователей еще во время Longhorn RTM (кстати, с месячным временем простоя меньше 2 минут). О других достижениях :) – по ходу публикаций. Обещаю, будет интересно! (если эта тема кого-нибудь зацепит).