Настройка TMG Beta 3 для SSTP VPN подключений — часть 2: настройка брандмауэра на прием подключений SSTP

Посетителей: 4465 | Просмотров: 7067 (сегодня 0) Шрифт:

В первой части этого цикла статей я рассказал о преимуществах SSTP и о примерной тестовой сети, с которой работаю. Если вы пропустили эту часть, перейдите по этой ссылке, чтобы понять основные концепты SSTP и конфигурацию тестовой сети.

Теперь давайте перейдем к задаче сборки рабочей SSTP конфигурации на TMG Beta 3. Следует учитывать, что эта конфигурация создана для третьей бета версии продукта и после выхода продукта в RTM версии могут быть определенные изменения. В этом примере я использую TMG Enterprise Edition в массиве с одним участником. Процедуры будут слегка отличаться, если вы устанавливаете TMG VPN решение с помощью массива Enterprise, поскольку вам придется делать такие вещи, как определение владельца подключения, и вы не сможете использовать DHCP для информации IP адресов.

Шаги, необходимые для создания рабочего решения в тестовой сети, включают следующее:

Создание сертификата веб приемника SSTP Web Listener

TMG использует веб приемник (Web Listener) для принятия подключений от SSTP VPN клиентов. Это слегка усложняет дело. Веб приемник SSTP требует присвоения ему сертификата. Это означает, что вам нужно выделить IP адрес для веб приемника SSTP в большинстве ситуаций. Причина этого заключается в том, что веб приемник SSTP не требует проверки подлинности. Он не только не требует проверки подлинности, вы не сможете принудительно внедрить аутентификацию на этом веб приемнике. По этой причине вы вряд ли будете использовать тот же веб приемник для правила веб публикации (Web Publishing Rule). Таким образом, следует запланировать выделение IP адреса на внешнем интерфейсе брандмауэра TMG для SSTP приемника.

Следующая проблема, с которой нам предстоит разобраться, представляет собой собственно получение сертификата. Во времена Windows 2003 получение сертификата с сайта подачи заявок через интернет было простым делом. Однако все изменилось с выходом Windows Server 2008, и если вы думаете, что сможете использовать сайт подачи заявок через интернет для получения сертификата веб сайта для приемника SSTP, вы будете сильно разочарованы. Просто ради интереса можете попробовать. Однако не стоит тратить слишком много времени на это, поскольку это не сработает.

Вам придется использовать другие способы получения сертификата. Для начала вам необходимо решить, какой тип сертификата вы хотите использовать:

В этом примере я использую частный сертификат. Это означает, что мне придется сделать две вещи, чтобы все работало правильно:

Как на счет подробностей? Как вы требуете сертификат веб сайта? Мой врач говорит, что я должен снижать свое кровяное давление, поэтому я решил использовать мастера Windows Server 2003 IIS Web Site Certificate Request Wizard для получения сертификата. Однако это лишь один из способов выполнения данной задачи. Существует масса других способов. Если у вас нет проблем с давлением или других проблем со здоровьем, которые не позволяют вам использовать командную строку, то настоятельно рекомендую вам использовать процедуру, описанную Джейсоном Джоунсом.

Сертификат, который я создал для веб приемника SSTP, показан на рисунке ниже. Общее имя сертификата будет vpn.msfirewall.org, а улучшенный ключ (Enhanced Key Usage) для аутентификации сервера (Server Authentication).

Получите сертификат веб сайта выбранным вами способом и скопируйте его на рабочий стол на брандмауэре TMG.

Установка сертификата веб приемника SSTP

Следующим шагом будет установка сертификата веб сайта на брандмауэр TMG. Это простая часть. Выполните следующие шаги на брандмауэре TMG, чтобы установить сертификат:

Импортированный сертификат появится в окне консоли, подобно тому, что показано на рисунке ниже.

Убедитесь в том, что ЦС сертификат установлен в хранилище сертификатов корневого доверенного центра сертификации машины. Брандмауэр TMG, используемый в лабораторной сети, был настроен в качестве участника домена перед установкой ПО TMG, поэтому авторегистрация автоматически установила сертификат, поскольку я использовал производственный ЦС Windows Server 2003 Enterprise CA. Если вы не используете подобную конфигурацию, вам необходимо убедиться, что ЦС сертификат установлен на брандмауэре. На рисунке ниже показан ЦС сертификат, установленный в нужное место.

Исправление проблем с CRL

Я уже упоминал о проблеме CRL. Когда SSTP VPN клиент создает подключение, он будет проверять CRL на предмет отзыва сертификата веб сайта. Расположение CRL включено в сертификат, как показано на рисунке ниже.

На рисунке 4 видно, что CRL доступен через HTTP подключение. Это означает, что мне нужно опубликовать свой веб сайт CRL. Обратите внимание, что имя по умолчанию включено в сертификат. Есть некоторые вещи, которые можно сделать с настройкой личного ЦС, чтобы изменить URL, используемый для публикации CRL, и вам, возможно, придется сделать это в производственной среде. Для подробной информации об этих изменениях нажмите здесь.

Сейчас я расскажу вам, а позже и покажу, что точка распространения CRL Distribution Point недоступна непосредственно с этого URL. Итак, если вы планируете опубликовать свой CRL, и считаете, что сможете воспользоваться URL, указанным на сертификате, вы будете неприятно удивлены тем, что это не работает. Мы рассмотрим эту проблему более подробно позже.

Если вы используете коммерческий сертификат, вам не нужно беспокоиться о публикации своего CRL сайта. Коммерческий CRL должен быть доступен с любого интернет подключения.

Теперь давайте вернемся назад к задаче публикации сайта CRL. Она требует создания правила веб публикации (Web Publishing Rule):

Теперь переходим к клиенту и пытаемся зайти на сайт. На моем тестовом клиенте под управлением Windows 7 я введу http://dc.msfirewall.org/CertEnroll/dc.crl и нажму клавишу enter. Вы должны увидеть следующее диалоговое окно.

Если вы откроете CRL, вы увидите нечто вроде того, что показано на рисунке ниже.

На данный момент мы знаем, что правило работает. Однако мы не знаем, будет ли SSTP клиент на самом деле использовать путь, указанный в правиле. Дам вам подсказку: SSTP клиент не использует этот путь. Это означает, что нам нужно пересмотреть это правило позже. Но я хочу показать вам процесс подключения SSTP, прежде чем подробно описать эти детали, о которых мы поговорим в следующей части.

Заключение

В этой части цикла о настройке брандмауэра TMG на прием подключений от SSTP VPN клиентов мы обсудили проблемы, связанные с сертификатами, а затем установили сертификат веб сайта на брандмауэр TMG. После этого мы создали правило веб публикации с целью публикации CRL сайта для нашего частного ЦС. Обратите внимание, что вам не нужно выполнять этот шаг, если вы используете коммерческий ЦС. В третьей части этого цикла мы рассмотрим шаги настройки компонентов VPN сервера и затем создадим VPN подключение с помощью SSTP.

Установка сертификатов Let’s Encrypt на Windows Server

Для работы служб удаленного доступа Windows Server, таким как Remote Desktop Gateway и Remote Access VPN требуется требуется сертификат, выданный публичным удостоверяющим центром.

Сертификат используется для шифрования трафика между клиентом и сервером, а также для аутентификации сервера (не клиента). Можно использовать самоподписанный сертификат, но в таком случае вам придется устанавливать его на каждое устройство ваших пользователей.

Есть бесплатная альтернатива — сервис Let’s Encrypt, в котором можно бесплатно за несколько минут получить валидный сертификат.

Для работы с сервером сертификации необходимо загрузить клиент Win-Acme. Клиент распространяется бесплатно, исходный код доступен в GitHub.

Загрузите последнюю версию Win-Acme с сайта https://github.com/win-acme/win-acme/releases, вариант trimmed. Распакуйте архив на Windows сервере, где необходимо установить сертификат.

Установка сертификата для SSTP VPN

Перед установкой, убедитесь, что:

• адрес сервера указан в DNS
• на сервере установлена роль Direct Access and VPN (RAS)

где vpn.example.com — адрес вашего сервера.

Установка сертификата для Remote Desktop Gateway

Перед установкой, убедитесь, что:

• адрес сервера указан в DNS
• на сервере установлена роль Remote Desktop Gateway

где rds.example.com — адрес вашего сервера.

Обратите внимание, сертификат Let’t Encrypt выдается сроком на 3 месяца, но скрипт установки создает задачу в Task Scheduler для автоматического обновления.

Как защитить vpn mikrotik сертификатами?

Дмитрий Шицков,
В этом случае не можно, а нужно добавить в доверенные сертификат, только не сервера, а созданного CA, иначе сертификат сервера не пройдет проверку подлинности, которая в sstp обязательна.
Кроме того, в common name сертификата сервера должен быть указан или fqdn сервера, или его IP.
В случае sstp для аутентификации по клиентскому сертификату необходимо использовать EAP, который для vpn подключений микротиком не поддерживается, поэтому в тиках sstp возможен только через логин/пароль.
Исключение составляет подключение через sstp двух микротиков, в этом случае использование клиентского сертификата возможно.
Надо понимать, что sstp — проприетарный протокол майкрософт; все сторонние реализации работают не так, как «каноничная» реализация, т.е. виндовая. Отсюда и бардак. :F

UPD: впрочем, может я и не прав на счёт eap для vpn. Народ в интеретах пишет, что возможно. Но это нужно или иметь radius сервер, или городить его на микротике.
Года два-три назад это точно не работало.
В любом случае, про галку «verify client cert» забудьте, это не EAP, и не часть «каноничного» sstp, а велосипед от микротика, с виндовым клиентом работать не будет.

Verify client certificate работает только при соединении через sstp двух микротиков. Windows для проверки подлинности клиенским сертификатом (для sstp) должен использовать EAP, который микротик не поддерживает ни в каком виде (для vpn).

Вариантов с проверкой клиентского сертификата в тиках при сочленении с виндовым клиентом только два: openvpn и ikev2

UPD: впрочем, может я и не прав на счёт eap для vpn. Народ в интеретах пишет, что возможно. Но это нужно или иметь radius сервер, или городить его на микротике.
Года два-три назад это точно не работало.

Windows Server 2012 R2 Remote Access — Настраиваем VPN сервер на использование протокола SSTP

Прошло уже более года, после того как мы начали работу с VPN соединениями на базе протокола L2TP/IPsec и авторизацией через RADIUS . Накопился некоторый опыт использования описанной конфигурации, были выявлены её плюсы и минусы, сделаны определённые выводы. Опираясь на эти выводы, в данной заметке мы продолжим развитие темы настройки безопасных VPN соединений и рассмотрим шаги, необходимые для организации возможности работы по протоколу SSTP (Secure Socket Tunneling Protocol).

Опыт использования L2TP/IPsec VPN показал, что при наличии внятной пошаговой инструкции по подключению, большинство пользователей способны без особых проблем настроить такое VPN-подключение самостоятельно. Но всё-таки всегда остаются индивидуумы, которые умудряются наделать ошибок даже в таких условиях, и поэтому мысль о необходимости упрощения процесса создания VPN-подключения всегда мелькала где-то на заднем фоне. К тому же в ряде ситуаций мы столкнулись с проблемой блокировки некоторых портов, необходимых для L2TP/IPsec VPN, обнаруженной на уровне интернет-провайдеров. Причём иногда дело доходило до абсурда, когда у одного и того-же интернет-провайдера трафик L2TP/IPsec в одном конце города транслировался беспрепятственно, а в другом конце города блокировался. Мы уже даже мысленно поделили для себя зоны разных интернет-провайдеров на сегменты, где L2TP/IPsec VPN будет работать без нареканий, и на зоны, где точно будут проблемы и нам потребуется подумать об альтернативных вариантах доступа к ресурсам локальной корпоративной сети. Помимо этого, были и случаи, когда командированные пользователи и «отпускники», удалённо пытающиеся подключиться через «гостиничный интернет», испытывали проблемы в силу всё тех же проблем с блокировкой нужных портов. Разумеется перед внедрением L2TP/IPsec VPN мы понимали все эти риски и в подавляющем большинстве проблемных ситуаций находилось какое-то обходное решение, но «осадочек» от каждой такой ситуации оставался неприятный.

Я начал вспоминать, почему же ранее мой выбор пал именно на L2TP/IPsec. Определяющих факторов было два – приемлемый уровень безопасности и поддержка более широкого круга клиентских ОС. Помню, что в то время меня заинтересовал протокол SSTP, но было пару факторов, которые заставили меня отстраниться от данной технологии. Во первых, на то время у нас было ещё достаточное количество клиентов на базе Microsoft Windows XP, а в этой ОС протокол SSTP, как известно, не поддерживается. Во вторых, у меня не было возможности использовать публичный сертификат с корпоративными доменными именами для защиты SSTP соединений, а заменять его на сертификат внутреннего выделенного ЦС не было желания, так как это влекло за собой проблемы связанные с распространением его корневого сертификата на интернет-клиентов и публикации списка отзыва сертификатов (Certificate Revocation List – CRL) в Интернет.

Но прошло время, клиентов с Windows XP стало на порядок меньше (усиление корпоративной политики ИБ и агрессивные рекламные компании Microsoft по обновлению ОС сделали своё дело), а у меня появилась возможность работы с публичным сертификатом. К тому же на глаза мне попалась информация о том, что на таких OC, как Linux и Apple Mac OS X, клиентское ПО для поддержки SSTP подключений уже давно вполне успешно эксплуатируется, несмотря на то, что в своё время этому протоколу пророчили «Win-изоляцию» в силу его проприетарности.

Таким образом, совершенно определённо, для нас настало время испытать на практике все преимущества SSTP, в частности возможность работы практически в любых условиях, везде, где только есть возможность использования стандартного Интернет-соединения по протоколу HTTPS (TCP 443). То есть при использовании SSTP, теоретически, у вас нигде не должно возникнуть проблем с VPN подключением, ни из дома (даже при условии использования всяких там NAT-ов и всевозможных кривых настроек местного сетевого оборудования интернет-провайдеров), ни в гостинице (даже при условии использования прокси), ни где быто ни было ещё. К тому же процедура настройки VPN-соединения с использованием SSTP на клиентской системе упрощается до безобразия и не подразумевает манипуляций с цифровыми сертификатами (при условии, что на стороне сервера используется публичный сертификат).

Основные требования к клиентам и их настройка

Если речь вести о клиентских системах на базе ОС Microsoft Windows, то нужно учесть, что SSTP работает на системах начиная с Windows Vista SP1 и более поздних. Для клиентских систем ниже Windows Vista SP1, в том числе и для ещё «живых мамонтов» в виде Windows XP, как и ранее, предполагается использование протокола L2TP/IPsec со всеми вытекающими обстоятельствами, о которых я говорил выше. От использования протокола PPTP, как уже давно скомпрометированного, предлагается отказаться вовсе. Ссылки на обновлённые инструкции по настройке SSTP соединения на клиентских ОС Windows можно найти в конце этой статьи.

Для клиентских систем на базе ОС Linux вполне жизнеспособным себя показывает проект с открытым исходным кодом SSTP-Client. Мной уже подготовлены пошаговые инструкции для не особо искушённых пользователей Linux-систем на примере настройки в Ubuntu Linux 14.04 и 15.04/15.10 .

По поводу клиентских систем на базе ОС Apple Mac OS внятного пока ничего сказать не могу, так как под руками их у меня попросту нет. По имеющейся поверхностной информации можно использовать SSTP-Client (в качестве консольного варианта), а можно использовать созданный на его основе пакет iSSTP с управлением через графический интерфейс. Надеюсь, что в ближайшее время Виталий Якоб нас порадует соответствующей инструкцией пользователя.

Общее для все клиентов требование — клиент SSTP VPN должен иметь возможность проверять списки отзыва сертификатов (CRL) для подтверждения того, что сертификат предоставляемый VPN-сервером не был отозван. Такого рода проверка может быть отключена на стороне клиента, но это не самое лучшее решение с точки зрения безопасности, и его имеет смысл использовать лишь в крайних случаях.

Основные требования к VPN-серверу и его настройка

Серверную часть VPN-соединения в нашем случае будет представлять собой расширение к созданной ранее конфигурации VPN-сервера на базе Windows Server 2012 R2 с ролью Remote Access.

Из основных требований к VPN-серверу, как уже наверно понятно из всего вышесказанного, является наличие на нём установленного сертификата. Получить такой сертификат можно из публичных ЦС и, как правило, такие сертификаты стоят немалых денег. Но есть и бесплатные варианты, например WoSign Free SSL Certificates . Сам я пока опыта общения с таким ЦС не имел, и поэтому будет интересно выслушать Ваши комментарии по этому поводу.

Требования к сертификату VPN-сервера

Важным для SSTP является то, что при генерации запроса на получение сертификата от стороннего публичного ЦС нужно помнить про то, что в запрашиваемом сертификате должна присутствовать политика применения (Extended Key Usage, EKU) — Server Authentication (1.3.6.1.5.5.7.3.1). Само собой для такого сертификата должен быть разрешён экспорт закрытого ключа, так как возможно нам потребуется установка сертификата на несколько VPN-серверов в случае, если, например, используется кластерная конфигурация.

Обязательным требованием к получаемому сертификату является также то, что список отзыва сертификатов (CRL) указанный в сертификате обязательно должен быть доступен в Интернете, так как в самом начале создания SSTP соединения клиентский компьютер будет пытаться проверить не является ли предоставленный VPN-сервером сертификат отозванным. Не будет доступного CRL – не будет SSTP соединения.

Полученный сертификат устанавливается на VPN-сервере в хранилище сертификатов Local Computer\Personal и должен иметь привязку к закрытому ключу этого сертификата.

Также разумеется, что ЦС выдавшему сертификат должны доверять не только наши VPN-серверы, но и все наши внешние Интернет-клиенты, которые будут подключаться к этим серверам по протоколу SSTP. То есть корневой сертификат (их может быть и несколько) должен присутствовать на всех компьютерах в хранилище сертификатов Local Computer\Trusted Root Certification Authorities. Информацию об этих требованиях можно найти в статье TechNet Library — Configure RRAS with a Computer Authentication Certificate . В большинстве современных клиентских ОС коллекция публичных корневых сертификатов обновляется автоматически при наличии постоянного подключения к Интернет.

Настройка роли Remote Access

После того, как на VPN-сервере установлен сертификат, откроем оснастку Routing and Remote Access и в свойствах сервера VPN на вкладке Security выберем этот сертификат для SSTP в разделе SSL Certificate Binding

Изменение этой опции выведет предложение об автоматическом перезапуске служб RRAS. Соглашаемся с перезапуском служб.

Далее в разделе Ports добавим порты SSTP. В нашем примере под SSTP соединения отдаётся большая часть портов и небольшая часть портов выделяется для клиентов без поддержки SSTP, например Windows XP. Возможность же подключения по протоколу PPTP отключаем совсем.

Информацию о том, как правильно отключить возможность подключения по протоколу PPTP, можно найти в статье Routing How To. Add PPTP or L2TP ports . Пример на скриншоте:

После сделанных изменений проверим TCP прослушиватели (TCP Listener) работающие на нашем VPN-сервере. Среди них должен появиться прослушиватель для 443 порта, на который VPN-сервером будут приниматься клиентские подключения по протоколу SSTP:

Не забываем настроить брандмауэр, включив уже имеющееся после установки и настройки роли Remote Access правило Secure Socket Tunneling Protocol (SSTP-In)

Поимо этого можно отключить разрешающее правило для входящих PPTP-подключений на порт TCP 1723 (в конфигурации по умолчанию это правило называется «Routing and Remote Access (PPTP-In)«)

Так как наш VPN-сервер является членом NLB-кластера, нам потребуется дополнительно создать правило разрешающее балансировку порта TCP 443.

Сделанных настроек вполне достаточно для того чтоб наш VPN-сервер смог успешно принимать SSTP подключения.

Проверяем подключение VPN-клиента

На клиентской машине имеющей прямой доступ в интернет по 443 порту настраиваем проверочное VPN-соединение и выполняем подключение…

На стороне сервера при этом убеждаемся в том, что клиент использует один из свободных созданных нами ранее SSTP портов…

Инструкции для пользователей

Как уже отмечалось ранее, для пользователей выполняющих подключение к корпоративным VPN-серверам из Интернет необходимо разработать чёткие пошаговые инструкции. Мне удалось протестировать (и параллельно разработать пошаговые инструкции для пользователей) VPN-подключения в составе следующих операционных систем:

• Windows XP 32-bit RU SP3
  (Инструкция переписана с учётом использования L2TP/IPsec, но при отсутствии работающего PPTP. Запрос и установка сертификата делаются в два этапа разными скриптами)
• Windows VistaBusiness 32-bit RU SP2 (SSTP)
• Windows 7Pro 32-bit RU SP1 (SSTP)
• Windows 8.1 Pro 64-bit RU (SSTP)
• Ubuntu Desktop Linux14.04 64-bit (SSTP)
• Ubuntu Desktop Linux15.04 64-bit (SSTP)
• Ubuntu Desktop Linux14.10 64-bit (SSTP)

Инструкции в формате DOCX (а также нужными исполняемыми файлами), которые, при желании, вы можете адаптировать под своё окружение можно скачать по ссылке . Часть инструкций доступна для онлайн просмотра и обсуждения на нашем Вики .