Глава 6. Удалённый доступ

Существуют две разновидности удалённого доступа, имеющиеся в Windows Server 2016. Наиболее общим способом для реализации роли Remote Access является в предоставлении DirectAccess для ваших подключённых к домену компьютеров Windows 7, 8 и 10, а также VPN для всех остальных. Машины DA являются обычным корпоративным активом во владении вашей компании. Одна из первичных причин почему DirectAccess обычно применяется только для имущества компании состоит в том, такая клиентская машина должна подключаться к вашему домену потому что имеющиеся настройки конфигурации DA приносятся вниз к клиентам через GPO. Я сомневаюсь что вы пожелаете чтобы ваши домашние и персональные компьютеры присоединялись к вашему домену.

VPN по этой причине применяется для клиентов более ранних версий, таких как Windows XP или не присоединённых к домену Windows 7/ 8/ 10, а также для домашних и персональных устройств, которые хотят получить доступ к вашей сетевой среде. Поскольку это обычный перехватчик VPN со всеми нормальными доступными протоколами, такими как PPTP, L2TP, and SSTP, он может даже работать для соединения устройств подобных смартфонам и планшетам с вашей сетевой средой.

Внутри роли Remote Access Server 2016 существует также третья доступная функция, имеющая название WAP (Web Application Proxy). Эта функция не применяется для полного подключения удалённых компьютеров к вашей сетевой среде в отличие от DirectAccess и VPN; вместо этого, WAP применяется для публикации внутренних веб- ресурсов во всемирный Интернет. Например, если мы запускаем Сервер Exchange и SharePoint внутри вашей сетевой среды и хотим опубликовать доступ к этим ресурсам на основе веб- доступа в Интернет для присоединения внешних пользователей, WAP мог бы стать механизмом, который может опубликовать доступ к этим ресурсам. Выражение публикация для интернет аналогична имеющемуся в Обратному прокси (Reverse Proxy), а WAP может действовать аналогично. Он также может выступать в роли прокси ADFS.

Для получения дополнительной информации по роли WAP, пожалуйста, обратитесь к http://technet.microsoft.com/en-us/library/dn584107.aspx.

Одна из наиболее запутывающих частей настройки DirectAccess состоит в том что существует множество способов выполнения этого. Некоторые при этом являются хорошими идеями, в то время как другие нет. Перед тем как мы приступим к расркутке данного рецепта, мы собираемся обсудить ряд вопросов и ответов, которые помогут нам в успешной реализации DA. Один из самых первых вопросов, который всегда присутствует сам по себе при настройке DirectAccess звучит так: "Как мне назначать адреса IP своему серверу DA?" Это достаточно нагруженный вопрос, так как ответ зависит от того как вы собираетесь реализовывать DA, какие функции собираетесь применять, и даже от того, насколько безопасным вы предполагаете сделать свой сервер DA. Позвольте мне ответить на некоторые вопросы, излагая потенциальные ответы на такие вопросы и обсуждая эффект от принятия каждого решения.

Теперь, когда у нас имеются некоторые общие соображения о том как мы хотим реализовать свои технологии удалённого доступ, с чего нам начинать? Большинство служб, которые вы хотите выполнять на Windows Server начинаются с установки некоторой роли, однако реализация удалённого доступа начинается до того. Давайте пройдём весь процесс получения некоторого нового сервера и превращения его в сервер Удалённого доступа (Remote Access) Microsoft.

Вся наша работа будет выполняться на новом Windows Server 2016. Мы обсуждаем подход с двумя NIC, поэтому у нас имеются два NIC, установленных в этом сервере. Причём Внутренний NIC подключён к вашей корпоративной сетевой среде, в то время как Внешний NIC подключён к всемирному Интернету для целей упрощения. Внешний NIC также может быть подключён в некую DMZ.

Для превращения своего нового сервера в некий сервер Удалённого доступа выполните следующие шаги:

Включённый в Server 2016 технологии удалённого доступа имеют великолепную функциональность, однако их начальная настройка может вас смутить. Следуя процедуре, перечисленной в данном рецепте, вы будете настроены на верный путь чтобы быть успешным в своём развёртывании и будете предотвращены от попадания в проблемные ситуации в процессе своей дороги. Причина, по которой я абсолютно настаиваю на том чтобы вы держались подальше от метода развёртывания помеченного ярлыком предоставляющим Getting Started Wizard является двойной:

Одна из самых замечательных вещей относительно DirectAccess состоит в том, что все нужные вашим компьютерам клиентов настройки связи нужные им для соединения содержатся внутри GPO (Group Policy Objects, Объектов групповой политики). Это означает, что вы можете превращать новые компьютеры клиентов в клиентов с DirectAccess подключением даже не прикасаясь к их системам. После того, как вы один раз надлежащим образом настроите их, всё что вам нужно будет делать в дальнейшем это добавлять новые учётные записи компьютеров в некую группу безопасности Active Directory, и в процессе следующего цикла автоматического обновления Групповой политики (обычно в пределах 90 минут) такой новый компьютер будет подключён через DirectAccess даже когда находится за пределами вашей корпоративной сетевой среды.

Несомненно вы можете выбрать ничего предварительно не устанавливать при помощи GPO и DirectAccess всё равно будет работать. Когда вы дойдёте до конца своего мастера настройки DA, он проинформирует вас, что два новых GPO почти готовы быть созданными внутри Active Directory. Один GPO применяется для содержания ваших настроек сервера DirectAccess, а другой GPO используется для помещения в нём настроек ваших клиентов DirectAccess. Если вы дадите возможность вашему мастеру обработать генерацию таких GPO, он создаст их, привяжет их, поставит на них фильтрацию и наполнит их автоматически настройками. Почти в половине случаев я наблюдал людей, которые делали это именно таким образом и были навсегда счастливы позволив своему мастеру управлять такими GPO и сейчас и впоследствии.

Существует и другая половина случаев, и она желает чтобы мы слегка больше участвовали в персональном сопровождении управления таких GPO. Если вы намереваетесь настраивать новую среду DA, однако у вас не хватает полномочий для создания GPO, ваш мастер вовсе не будет собираться рассматривать возможность их создания. В этом случае вам необходимо будет работать с кем- то из вашей команды ActiveDirectory чтобы он сделал это. Другой причиной для ручного управления вашим GPO является пожелание наличия лучшего контроля за размещением таких политик. Когда вы позволяете своему мастеру DA создавать определённую GPO, он присоединит её к самому верхнему уровню вашего домена. Он также настроит Фильтрацию безопасности (Security Filtering) такого GPO с тем, чтобы они не имели возможности применения ко всему в вашем домене, однако когда вы откроете сою консоль управления Групповой политикой (Group Policy Management Console), вы всегда будете наблюдать эти политики DA перечисленными прямо в самых верхнем уровне своего домена. Иногда это просто является нежелательным. Поэтому, также и по этой причине вы можете пожелать выбрать ручное создание и управление GPO с тем, чтобы мы могли безопасно размещать и присоединять их там, где мы пожелаем сами.

Хотя сами по себе мастера DirectAccess и работают на своих серверах DA, наша работа сданным рецептом проходит не там. Настройки Групповой политики, которые мы будем выполнять, целиком осуществляются внутри Active Directory и мы будем выполнять эту работу изнутри некоторого Контроллера домена в своей среде.

Чтобы предварительно подготовить GPO для применения в DirectAccess выполните следующие шаги:

Создание GPO в Active Directory достаточно простая задача, однако критически важно чтобы вы правильно настроили свои Ссылки (Links) и Фильтрацию безопасности (Security Filtering). Если вы не позаботитесь о том, чтобы обеспечить то, что эти настройки соединения DirectAccess были готовы применяться только к тем машинам, которые на самом деле нуждаются в таких настройках, вы можете создать некую вселенную проблем с внутренними серверами, получающими настройки удалённых соединений и создающих им проблемы с соединениями внутри вашей сетевой среды.

Ключевым фактором здесь является обеспечение того, что настройки GPO сервера DirectAccess применяются только к компьютерам клиентов того DA, который вы планируете включит в вашей сетевой среде. Наилучшей практикой здесь будет определить такой GPO только для применения к некоторой специфической Группе безопасности Active Directory с тем, чтобы у вас был полный контроль над находящимися именно в этой группе учётными записями компьютеров. Мне приходилось наблюдать некоторые коллективы, делающие свою работу только на основе ссылок Подразделений (OU) и включающих целые OU в такую фильтрацию для GPO своих клиентов (полностью предшествующему применению какой- либо группы AD), однако выполнение этого подобным образом делает слегка более сложным добавлять или удалять машины из списка доступа в будущем.

Когда компьютер клиента строит свой DirectAccess туннель IPsec обратно в свою корпоративную сеть, он имеет возможность запросить некий сертификат как часть такого процесса авторизации. В более ранних версиях DirectAccess именно им и был Server 2008 R2, а такие сертификаты предоставлялись UAG (Unified Access Gateway, Шлюзом унифицированного доступа), причём такие сертификаты требовались для того, чтобы заставить работать DirectAccess. Настройка таких сертификатов совсем не является важным делом. Поскольку в вашей сетевой среде имеется некий сервер CA, вы уже подготовлены к бесплатному выпуску таких сертификатов. К сожалению, тем не менее, существовало достаточное число жалоб назад в Microsoft с тем, чтобы сделать для них такие сертификаты рекомендуемыми вместо обязательных, и они создали новый механизм в Windows 8 и Server 2012 с названием KerberosProxy, который можно было применять вместо обсуждаемого механизма для создания туннелей. Это позволило строить туннели DirectAccess без таких сертификатов компьютеров, делая данный процесс аутентификации более простым при начальной настройке, однако менее безопасным в итоге.

Я вам строго рекомендую чтобы вы всё- таки использовали в своих установках сертификаты! Они не трудны в настройке, а их применение делает более сильной аутентификацию вашего туннеля. Более того, у многих из вас просто может не быть выбора и вам всё ещё необходимо устанавливать такие сертификаты. Только простейшие сценарии DirectrAccess, причём все они применяют Windows 8 или выше на стороне клиента, могут отойти в сторону с методом ярлыков приведённых ранее сертификатов. Всякий кто желает присоединять Windows 7 через DirectAccess будет вынужден применять сертификаты как часть своей реализации. Помимо доступа Windows 7, всякий кто собирается применять расширенные свойства DirectAccess, такие как балансировка нагрузки, многосайтовость или двухфакторная аутентификация, также вынужден применять такие сертификаты. При любом из этих сценариев сертификаты становятся вновь востребованным требованием, а не просто рекомендацией.

Основываясь на своей практике, я могу предположить что практически все имеют клиентов Windows 7, которые получили бы преимущества будь они соединяемыми через DirectAccess и это всегда будет хорошей мыслью сделать вашу среду DA избыточной имея в ней сервера балансировки нагрузки. Это в дальнейшем придаст особое значение тому моменту, что вы просто должны установить аутентификацию сертификатами прямо на входе, вне зависимости от того нужна она вам в начале или нет. Вы можете впоследствии принять решение об изменении, что вам могут понадобиться сертификаты, и было бы намного проще иметь их уже установленными с самого начала, нежели пытаться включить их позже в работающую среду DA.

Чтобы распространять сертификаты, вам необходим работающим в вашей сетевой среде некий сервер CA. Когда сертификаты распространяются на соответствующие места, оставшаяся часть нашей работы будет выполнена нашим сервером DirectAccess Server 2016.

Чтобы сделать применение сертификатов частью процесса аутентификации вашего туннеля DirectAccess, выполните следующие шаги:

Требование сертификатов как части процесса аутентификации вашего туннеля DirectAccess является хорошей мыслью в любом окружении. Это делает ваше решение более безопасным, а к тому же добавляет расширенные функции. Первичным двигателем для большинства компаний требовать такие сертификаты является допуск клиентов Windows 7 к соединениям через DirectAccess, однако я предлагаю в любом случае использовать DirectAccess в любой ёмкости с применением таких сертификатов. Они просты для развёртывания, легки для настройки и дают вам некоторое дополнительное душевное спокойствие с осознанием того, что только компьютеры с некими сертификатами выпускаемыми напрямую для них с вашего внутреннего сервера CA собираются иметь возможность соединяться через вашу входную точку DirectAccess.

Если вы пронеслись со свистом мимо своих установок по умолчанию при настройке DirectAccess, или, что ещё хуже, воспользовались Getting Started Wizard, велики шансы, что ваш Сервер сетевой локации (NLS, Network Location Server) работает прямо на самом сервере DirectAccess. Именно это является не рекомендуемым методом применения NLS; в действительности он должен работать на отдельном веб сервере. На самом деле, если в дальнейшем вы пожелаете делать нечто продвинутое в будущем, например, настройку балансировки нагрузки серверов DirectAccess, вам в любом случае придётся собраться перенести NLS на другой сервер, поэтому вы можете сделать это прямо сейчас, при первой установке.

NLS является очень простым требованием, но очень критичным. Это всего лишь некий вебсайт, причём совершенно не имеет значение его содержимое, он всего лишь должен работать внутри вашей сетевой среды. Причём ничего не должно быть доступно вовне. Действительно, ничего не должно быть доступно вовне, потому что вам именно это и нужно, чтобы данный сайт был доступен только изнутри. Данный вебсайт NLS является значительной частью механизма, при помощи которого компьютеры клиентов DirectAccess определяют когда они находятся внутри своего офиса, а когда вне его пределов. Если они могут видеть такой вебсайт NLS, он и знают, что находятся внутри вашей сетевой среды и разрешение имён DirectAccess будет отключено, что на самом деле выключает DA. Если же вы не видите своего вебсайта NLS, они будут предполагать, что находятся за пределами корпоративной сетевой среды и включат разрешение имён DirectAccess.

Существует два ляпа при настройке вебсайта NLS:

Итак, давайте вместе пройдёмся в точности тем процессом, который я всегда осуществляю когда настраиваю вебсайт NLS в новой среде DirectAccess.

Наш NLS вебсайт будет размещаться на некотором сервере IIS, который работает под управлением Server 2016. Большая часть работы будет выполняться именно с этого веб сервера, но мы также создадим запись DNS и воспользуемся для этой задачи Контроллером домена.

Давайте совместно пройдёмся путём создания вебсайта Сервера сетевой локации:

В данном рецепте мы настроили базовый вебсайт Сервера сетевой локации для его применения в окружении DirectAccess. Именно этот сайт является тем что нам нужно в случае, когда наши компьютеры клиентов DA пытаются определить находятся ли они внутри корпоративной сетевой среды или вовне её. Хотя этот рецепт и отвечает нашим требованиям NLS, и на самом деле переносит нас в правильную практику установки NLS, размещающегося на своём собственном веб сервере, присутствует даже ещё один шаг, который способен сделать его ещё лучше. В настоящее время такой вебсайт является единой точкой отказа NLS. Если такой веб сервер выйдет из строя или будет иметь проблемы, мы получим клиентские компьютеры DirectAccess внутри нашей сетевой среды, которые будут полагать что они находятся за её пределами и они будут иметь некоторые существенные проблемы разрешения имён, пока не разрешится проблема нашего NLS. Имея это ввиду, великолепной идеей будет сделать NLS избыточным. Вы можете свести сервера в совместный кластер, воспользовавшись Microsoft NLB (Network Load Balancing, Балансировкой сетевой нагрузки), или даже применив некий вид аппаратной балансировки нагрузки, если в вашей сетевой среде имеется таковая. Таким образом вы можете выполнять один и тот же вебсайт NLS на множестве веб серверов и пребывать в уверенности, что ваши клиенты всё ещё будут работать надлежащим образом в случае отказа одного из веб серверов.

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

Хотя объединение двух аналогичных серверов воедино чтобы совместно использовать имеющуюся нагрузку обычно называется кластеризацией, и порой я слышу от администраторов ссылку на это в их мире DirectAccess, тем не менее, совместная балансировка нагрузки серверов DA в действительности не имеет ничего общего с Кластеризацией Windows. Когда вы устанавливаете оба свойства, и роль Удалённого доступа, и функцию Балансировки сетевой нагрузки на свои сервера удалённого доступа, вы уже снабдили их всеми необходимым частями и фрагментами которые им требуются для взаимодействия друг с другом и работать в совместной конфигурации Активный/ Активный. Сама операционная система применяет Windows NLB для перемещения обмена вперёд и назад соответствующим получателям, однако всё внутри NLB настраивается из Консоли управления Удалённым доступом. Это снабжает вас прекрасной визуальной консолью, которая может применяться для администрирования и управления такими настройками NLB прямо наряду с вашими прочими установками удалённого доступа.

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

Мы собираемся применить свой существующий сервер RA1, который уже исполняет DirectAccess. Он, и наш новый сервер, RA2, оба работают под управлением Windows Server 2016. Они оба имеют установленными роль Удалённого доступа (Remote Access) и свойство Балансировки сетевой нагрузки (Network Load Balancing). Оба подключены в наш домен и имеют необходимые им сертификаты (SSL и IPsec) установленными для применения их в DirectAccess. Причём на обоих серверах установлен один и тот же сертификат SSL; так как они намереваются разделять нагрузку и все запросы будут приходить к обоим на одно и то же общедоступное имя DNS, они могут совместно применять этот сертификат {Прим. пер.: должны!}.

Если ваги сервера DirectAccess являются виртуальными машинами, существует одно очень важное предварительное требование. Вы должны войти в настройки NIC своей ВМ и выбрать опцию Enable spoofing of MAC addresses (Включить перехват MAC адресов). Без пометки этого блока для каждого из этих NIC ваш сетевой обмен прекратит совместную работу когда вы создадите массив балансировки нагрузки.

Для целей настоящего рецепта мы собираемся предположить, что RA1 был настроен для применения Teredo, что означает, что у него имеется два общедоступных адреса IP назначенных для его Внешнего NIC. Мы применяем это в качестве примера, так как это наиболее сложная конфигурация, для её прохода при настройке NLB. Та же самая процедура применима и для отдельного IP на Внешнем NIC; это будет просто означать, что вам придётся настраивать только один VIP (Virtual IP ) вместо двух.

Пройдя добавление второго узла, я всегда возвращаюсь назад в свойства своих NIC обоих NIC на обоих серверах и проверяю что все ожидаемые IP адреса были добавлены правильно. Иногда я обнаруживаю, что мой мастер оказался не в состоянии заполнить все VIP и DIP, как это было перечислено в начале рецепта. Помимо таких DIP, Внешний NIC на каждом из серверов также должен перечислять оба Внешних VIP, а ваши Внутренние NIC на каждом из серверов должны перечислять ваши внутренние VIP. Ваши свойства TCP/IPv4 данных NIC, естественно, выглядят переполненными IP адресами, однако это всё нормально и хорошо для успешно осуществляющего балансировку нагрузки массива DirectAccess.

Возможность выполнения балансировки нагрузки серверов DA собранных воедино прямо из коробок Windows Server 2016 является невероятно прекрасным свойством. Избыточность является ключевой для хорошего решения, и настройка данного массива для отказоустойчивого варианта Активный/ Активный не является биномом Ньютона. Хотя ваши мастеры для включения NLB и являются централизованными прямо вместе со всеми прочими настройками DirectAccess, они определённо могут запутываться при прохождении через них в самый первый раз. Как и для любой системы, чьё задание состоит в повсеместном перемещении обмена вперёд и назад, правильное планирование адресов IP и маршрутизации является ключевым для успешного развёртывания вашего NLB DirectAccess.К счастью, данный рецепт помогает прояснить вопросы вокруг этой часто запрашиваемой задачи на наших удалённых серверах.

Следуя за созданием своего массива, вы заметите, что навигация по некоторым экранам внутри вашей Консоли управления Удалённым доступом слегка изменилась. Когда вы осуществляете доступ к таким экранам как Configuration для внесения изменений, Operations Status для проверки состояния своих серверов, или Remote Client Status для просмотра того, какие клиенты подключены, вы теперь можете отметить, что все узлы перечисляются отдельно. Вы теперь можете кликнуть по одному конкретному серверу из вашего массива, или вы можете кликнуть по словам Load Balanced Cluster (Кластер балансировки нагрузки) чтобы посмотреть информацию, которая разделяется между всеми участниками данного массива.

Ещё одно важное замечание. Теперь, когда у нас есть поднятый и работающий массив балансировки нагрузки, также стало гораздо проще добавить третий узел в данный массив! Ваш массив DirectAccess может расти по мере роста вашей компании, если такое требуется, вплоть до восьми серверов узлов. Просто добавляйте дополнительные сервера в этот массив, перемещаясь в задание Load Balanced Cluster | Add or Remove Servers.

Среди администраторов достаточно распространён выбор опции Deploy DirectAccess only при начале работы с новой ролью Удалённого доступа. Возможно этот блок замышлялся изначально как только для применения DA,или чтобы все соединения клиентов обрабатывались только данной ролью DA. Хотя это верно для некоторых организаций, достаточно широко принято получать преимущества от обоих методов, и DirectAccess, и VPN при настройке в качестве вашей входной точки удалённого доступа. Быть может, у вас имеются мобильные телефоны или персональные планшеты которые вы желаете подключать к своей корпоративной сети. Или, может быть, вы хотите предоставить такую возможность удалённого подключения домашним компьютерам, или даже Mac-ам. Существуют сценарии, выходящие за рамки DirectAccess, и требующие некоторой другой формы связи VPN.

Внесение существенных изменений в промышленные серверы может казаться запугивающим, и вы хотите быть уверенным в правильном выборе параметров. К тому же, адресация IP серверов удалённого доступа не всегда является парой пустяков, и поэтому достаточно естественно задуматься о подстройке сервера DirectAccess в сервер DirectAccess плюс VPN, чтобы можно было подключить некоторую дополнительную адресацию IP. Вы могли бы злиться на это последнее. VPN может разделять имеющийся общедоступный IP адрес уже настроенный и работающий для ваших клиентов DA, поэтому, к счастью, когда вы решите добавить VPN на своём сервере, вам в любом случае не придётся перенастраивать свои NIC. Так как у нас нет нужды делать вначале никакие изменения сетевой среды, давайте перепрыгнем сразу к работе с нашим промышленным сервером и добавлением к нему роли VPN.

Сейчас мы будем работать с нашим новым сервером DirectAccess, который является Windows Server 2016 с установленной на нём ролью Удалённого доступа.

Чтобы добавить функциональность VPN на существующий сервер Windows Server 2016 выполните следующее:

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

Действие по включению VPN на сервере DirectAccesss является отдельной операцией, однако без пары дополнительных шагов настройки такое включение VPN даст вам не так много. При помощи данного рецепта вы должны теперь получить информацию о том как вам нужно включать и настраивать VPN на вашем сервере удалённого доступа с тем чтобы получить эти машины связанными таким, образом, чтобы не отвечать обязательному требованию быть подключёнными DirectAccess. На практике я нахожу, что большинство компаний пытаются получить возможность связи большей части компьютеров через DirectAccess, поскольку это более простая технология для работы с нею со стороны клиентов и она лучше подходит для управления подключаемыми к домену системами. При столкновении с необходимостью подключения компьютеров, не являющихся Windows 7, 8 или 10, или не присоединённых к домену, хорошо знать, что традиционные опции связи VPN присутствуют прямо в самой операционной системе Server 2016.

DirectAccess имеет возможность применять сертификаты парой различных способов. В зависимости от того как вы настроили DA, существуют различные места в которых эти сертификаты могут или нет применяться, однако одной общей переменной во всех реализациях DirectAccess является IP-HTTPS. Именно эта технология всегда включена в сервере DA и ей для надлежащей работы необходим сертификат SSL. Обмен IP-HTTPS поступает из всемирного Интернета, и поэтому я всегда рекомендую чтобы для прослушивания IP-HTTPS применялся настоящий сертификат SSL, который следует приобрести в общедоступной организации сертификации CA.

Как и со всеми прочими сертификатами SSL, они действуют на протяжении определённого периода времени. Обычно эти сертификаты приобретаются на период на основе в одного-, двух- или трёх- лет. Это означает, что время от времени вам необходимо обновлять такой сертификат и определять каким образом заставлять DirectAccess распознавать и применять такой новый сертификат. IP-HTTPS применяет в качестве прослушивания веб внутри IIS и поэтому естественно предположить, что когда вам нужно изменить ваш сертификат, вы должны это делать внутри IIS. Это не верное предположение. Что ещё хуже, это то что вы можете в действительности раскопать свой сайт внутри IIS и изменить связывание данного сертификата, а при этом ещё и заставить его работать какое- то время. Это е правильное место для изменения данного сертификата! Если вы просто измените связывание внутри IIS, ваше изменение временно будет возвращено и он вернётся обратно к применению вашего старого сертификата. К сожалению, я достаточно постоянно получаю вызовы от потребителей выполнивших это и впоследствии получивших все разновидности невозможности пользователей осуществить удалённое соединение из- за того что такой сервер DA вернулся к применению старого сертификата, имеющего на текущий момент истекший срок применения.

Давайте вместе поработаем над данным рецептом чтобы настроить наш DirectAccess на применение нового сертификата, который был недавно приобретён и установлен на ваш сервер.

У нас имеется поднятый и работающий сервер DirectAccess на нашем сервере Удалённого доступа Windows Server 2016. Наш сертификат SSL, который мы применяем для IP-HTTPS имеет почти истекший срок и нам необходимо обновить его при помощи нашего CA. Новая копия сертификата уже выгружена и установлена на самом сервере, поэтому нам всего лишь осталось определить где его необходимо отрегулировать чтобы DirectAccess начал его применять.

Чтобы отрегулировать настройку DirectAcces для начала применения нового сертификата для вашего перехватчика IP-HTTPS, выполните следующие шаги:

Замена вашего сертификата SSL который применяется в IP-HTTPS является регулярной и необходимой задачей для любого администратора сервера DirectAccess, однако она возможно может наступать только раз в год. Это обычно означает, что ко времени, когда наступает дата истечения срока вашего сертификата, вы скорее всего уже забыли где были установлены данные установки в вашей настройке. Я надеюсь, что данный рецепт может стать альтернативой такому беспокойству.

Я всегда проверяю свой сертификат извне своей сетевой среды после внесения изменений, чтобы убедиться, что такой новый сертификат в действительности теперь работает в моей системе. Если вы возьмёте некий компьютер вне своей сетевой среды во всемирном Интернете, попробуйте просмотреть любой пробный сайт из вашей общедоступной записи DNS вашего сервера DirectAccess. Например, если общедоступная запись DNS которую вы применяете на своём сервере это directaccess.contoso.com, попробуйте просмотреть https://directaccess.contoso.com/test. Вы можете ожидать получить некую ошибку 404, так как данная запрошенная вами страница в действительности не существует, однако, когда вы получите ошибку 404, у вас имеется возможность (зависящая от того какой браузер вы применяете; для данной цели я предпочитаю Chrome) просмотреть какой именно сертификат применялся для подтверждения данного обмена. Кликните по просмотру подробностей данного сертификата и убедитесь, что это именно ваш новый сертификат с новыми датами срока его истечения действия. В дальнейшем, если вы будете встречаться с любым видом предупреждающих сообщений при попытке просмотра данного проверочного вебсайта это, скорее всего, будет означать что существует некий вид проблемы с данным сертификатом и вам, возможно, необходимо в дальнейшем внести некоторые инвестиции.

Одно из самых больших преимуществ которую привнёс Microsoft за стол самых новых версий своей роли удалённого доступа являются отчёты. В прошлом было трудно было сказать кто был соединён и ещё труднее было определить кто был соединён ранее. Исторические сообщения об удалённых сообщениях отсутствовали вовсе. Все эти изменения, которые мы имеем в самых новых редакциях, такие как имеющийся у нас теперь прекрасный интерфейс для отображения нам того кто подключён, как часто они подключались, а также некоторая информация о том, какими вещами они занимались при соединении. Здесь мы оглянем эти интерфейсы, и изучим некоторую доступную для получения информацию. Мы также проверим что вы знаете как включать исторические отчёты, так как они не доступны по умолчанию.

Вся работа в данном рецепте будет выполняться на сервере Удалённого доступа Windows Server 2016, который обслуживает оба вида клиентов, и DirectAccess, и VPN.

Чтобы ознакомиться с доступными в Server 2016 опциями отчётов вашего удалённого доступа выполните следующие шаги:

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