Глава 6. Включение вашего мобильного рабочего пространства

Предоставление доступа пользователя к подключению VPN обычно означает предоставление ему особой связи сетевого подключения, которое вы можете запустить, введя параметры доступа для передачи аутентификации и затем оказаться подключёнными в их рабочих сетевых средах чтобы взаимодействовать с ресурсами компании. После запуска некого VPN пользователи могут открывать свою электронную почту, отыскивать документы, запускать свои бизнес- приложения или выполнять прочую работу так, как будто они работают тем же самым образом, как если бы они физически присутствовали в своём офисе. Кроме того, при подключении через некий VPN становится возможным управление их ноутбуками, что делает возможным успешный поток взаимодействия для таких систем как Групповые политики и SCCM. Подключения VPN привносят обратно в вашу сетевую среду великолепное подключение, но (помните, здесь мы обсуждаем традиционные, обычные VPN подключения) они работают только когда сам пользователь вручную запускает их и приказывает им работать. Всякий раз когда некий пользователь не подключён к своему VPN, он переходит обратно к интернету без обратного подключения к центру обработки данных своей компании. Это также означает, что некое традиционное VPN подключение очевидно не имеет никакого вида связи с экраном регистрации Windows, так как пока он не зарегистрируется в своём компьютере и не получит доступа к своему рабочему месту Windows, этот пользователь не имеет возможности запускать такой VPN туннель. Это означает, что всё что можно попробовать воспроизвести в данном экране регистрации, например, просмотр аутентификации в реальном времени, либо в процессе процесса регистрации подобном обработке Групповой политики или сценариев регистрации не будет работать через традиционный VPN.

AOVPN (Always On VPN), просто как вы это могли предвосхитить на основании самого названия, это всего лишь сама мысль создания некого подключения VPN непрерывным и обладающего автоматическим подключением. Иными словами, когда пользователь всякий раз обладая своим ноутбуком вне стен офиса подключается к интернету, автоматически устанавливается обратно и некий туннель VPN к его корпоративной сетевой среде, причём в идеале с нулевым вводом пользователя в данном процессе. Это позволяет пользователям совсем забывать про такой VPN, так как он просто всегда подключён к нему и готов его применять. Пользователи могут регистрироваться в своих машинах, запускают свои приложения и начинают работать. Это также означает что функции управления ИТ, такие как политики безопасности, обновления и пакеты установки, которые способны выполнять активную доставку на машины клиентов в большинстве случаев, поскольку мы больше не ожидаем что наш пользователь предпримет решение вернуться к работе; это происходит автоматически и почти во всех случаях.

На самом деле имеется три различных способа, которым Always On VPN может включаться на определённой машине клиента, причём ни один из них не предполагает вовлечение включения клиента в некое VPN подключение:

Поскольку очевидно, что вам нет нужды в подключении Always On VPN, когда ваш ноутбук располагается внутри вашей корпоративной сетевой среды, нам также требуется обсудить сам факт того, что AOVPN обладает достаточной интеллектуальностью для собственного отключения когда его пользователи пребывают вне стен офиса. Компьютеры с включённым AOVPN автоматически будут принимать решение когда они пребывают внутри своей сетевой среды и тем самым отключая компоненты VPN, а как только они покидают свою сетевую среду, им требуется запускать своё подключение через VPN туннель. Данный процесс определения именуется Trusted Network Detection (Определение Доверенной сети). Когда он настроен как положено, компоненты Always On VPN информированы что выступает в роли суффикса DNS вашей компании, а затем они осуществляют отслеживание вашего NIC и настроек профиля межсетевого экрана на предмет установления того был или нет данный суффикс назначен этим компонентам. Когда мы наблюдаем искомое соответствие, это трактуется как тот факт, что вы находитесь внутри своей сетевой среды и после этого AOVPN отключается.

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

Туннели пользователя

Наиболее распространённым способом создания AOVPN в дикой природе (до сих пор), состоит в аутентификации Туннеля пользователя на уровне определённого пользователя. Для вашего компьютера применяются сертификаты пользователя, выпускаемые неким внутренним PKI, причём эти сертификаты затем применяются как часть того процесса аутентификации, который происходит при подключении. Туннели пользователя обслуживают все имеющиеся машины и обмен пользователя, но очень важно обратить внимание на то, что Туннели пользователя не могут быть установлены пока сам компьютер располагается в своём экране регистрации, так как на этот момент времени пока не произошла аутентификация пользователя. Следовательно некий Туннель пользователя будет запущен только когда пользователь успешно зарегистрируется в этом компьютере. При наличии в деле только Туннеля пользователя, данный компьютер не будет иметь обратной связи со своей корпоративной сетевой средой для функций управления пока кто- нибудь не зарегистрируется в этом компьютере, а это также означает что вы также будете полагаться на кэшированные параметры доступа чтобы передавать через данное приглашение на регистрацию.

Туннели устройства

Некий Туннель устройства предназначен для заполнения промежутка, который остаётся при запуске только Туннеля пользователя. Некий Туннель пользователя аутентифицируется через какой-то сертификат машины, который также выпускается вашим внутренним PKI. Это означает, что такой Туннель устройства может самостоятельно устанавливаться даже не имея аутентификации пользователя. Иными словами, он работает даже когда Windows располагается на экране регистрации. Это делает возможными такие инструменты как Групповая политика и SCCM для их работы вне зависимости от ввода пользователя, а также допускает аутентификацию в реальном масштабе времени в контроллерах домена, позволяя пользователям регистрироваться в той рабочей станции, которая никогда там ранее не регистрировалась. Он также делает возможным сброс срока истечения действия пароля в реальном времени.

Некий Туннель пользователя может работать в почти всех машинах Windows 10, однако чтобы воспользоваться Туннелем устройства существуют некие фирменные требования. Чтобы раскрутить некий Туннель устройства вам необходимо соответствовать следующим требованиям:

Важно осознавать, что часть Always On из Always On VPN на самом деле относится к функциональности стороны клиента. Вы можете применять AOVPN на неком компьютере клиента чтобы подключаться ко многим различным видам инфраструктуры VPN в с обратной стороны. Мы вкратце обсудим это в разделе Компоненты сервера AOVPN.

В то время как создание обычных, выполняемых вручную, подключений VPN было возможно в операционных системах клиента Windows на протяжении 15 или 20 лет, Always On VPN является совершенно новым. Чтобы оно происходило, вашим работникам необходимо работать с Windows 10. А более конкретно, они должны работать с 1607 или более поздней версией Windows 10.

Вот поддерживаемые SKU:

Подождите - в этом нет никакого смысла. Зачем перечислять эти три элемента по отдельности если они включены один в другой? Это необходимо потому, что хотя технически говоря Always On VPN был официально введён в Windows 10 1607, в нём были проведены некоторые улучшения. Давайте перечислим их снова с кратким описанием того что изменилось за эти годы:

Независимо от того используете ли вы 1607, 1709, 1803 или 1809 - конкретное значение SKU не имеет значения. Ну, вряд ли это имеет значение. Always On VPN работает с Windows 10 Home, Pro, Enterprise и всеми прочими разновидностями. То есть Туннель пользователя работает с ними всеми.

Важно указать ещё раз: если вы желаете применять с Always On VPN Туннель устройства, требованием фирмы является использование подключаемого к домену SKU Windows 10 Enterprise или Education.

Подключение к домену

Как мы уже установили, если вы заинтересованы в применении Туннеля устройства AOVPN, ваши компьютеры клиентов должны быть подключёнными к домену. Тем не менее, если для AOVPN доступа вам хватает только туннеля пользователя, тогда нет никаких требований подключения к домену. Клиентам всё ещё требуется работать под Windows 10 1607 или новее, но они могут иметь любые SKU и могут быть даже домашними компьютерами {Windows 10 Home}, которые просто подключены к рабочим группам и им не требуется никакой домен.

Это подчёркивается во многих местах документации Microsoft, так как это делает возможным применение Always On VPN (до определённой степени) даже народом из BYOD (Bring Your Own Device, приносите своё собственное устройство). Хотя это и интересно в принципе, я не предвижу того чтобы вообще- то корпорации позволяли персональным компьютерам сотрудников подключаться к их VPN. Большинство организаций пытаются скромно обслуживать ранок BYOD предоставляя доступ к неким ресурсам через своё облачное решение, такое как Office 365 для обработки электронной почты или документов. Но подключать такие компьютеры и устройства обратно в вашу сетевую среду с полномасштабным туннелем VPN 3 уровня? Не думаю. Это привнесёт постоянные ночные кошмары персоналу администраторов по безопасности.

Предположим, у вас есть готовые к развёртыванию для подключения VPN все требуемые части и компоненты и вы на самом деле установили тот факт, что вы без проблем можете для своей инфраструктуры создавать для определённых целей обычные VPN подключения. Отлично! Похоже с точки зрения вашей инфраструктуры выглядит что вы готовы. Итак, что теперь требуется чтобы клиенты начали применять подключения Always On?

В настоящее время это слегка жёсткое требование для неких компаний. Сама по себе настройка установок политики Always On VPN не таит в себе ничего жутко страшного; вам просто потребуется ознакомиться с различными доступными вариантами, принять решение какие из них важны для вашего именно оснащения и собрать необходимый файл/ сценарий настройки. Хотя у нас и нет здесь достаточного места для подробного описания всех этих параметров, основной способ для совмещения всех этих настроек воедино обычно состоит в построении некого запускаемого вручную подключения VPN, его отладка для безопасности и установок аутентификации которые бы вы желали для своих работников, а затем в запуске некой утилиты, которая экспортирует данные настройки в некий файл конфигурации. Такие настройки профиля VPN входят в разновидности XML и PS1 (сценария PowerShell), и вам могут потребоваться оба этих файла для раскрутки этих установок для вашей рабочей силы. Вот великолепная отправная точка для работы с подобными конфигурациями.

После того как вы создали свои файлы настроек, после этого вы столкнётесь с задачей активной доставки этих настроек вашим клиентам. В идеале вам требуется иметь некое решение MDM (mobile device management, Мобильного управления устройствами) для раскрутки этих установок вашей рабочей силе. Хотя в качестве MDM можно рассматривать многие технологии из дикого мира, microsoft сосредоточен на SCCM (System Center Configuration Manager) и Microsoft Intune {Прим. пер.: а мы рекомендуем свой перевод 3 издания Полного руководства Ansible Джеймса Фримана и Джесса Китинга}.

Если у вас имеется на собственной площадке SCCM, отлично! Вы можете запросто настроить и накатить установки конфигурации на основе PowerShell в компьютеры своих клиентов и сделать у них возможным Always On VPN.

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

SCCM и Intune - это отлично, но не все работают с ними. Существует и третий вариант для раскрутки настроек Always On VPN через сценарии PowerShell. Хотя это и является планом Б от Microsoft (на самом деле они предпочитают раскручивать AOVPN через MDM), я предвижу что PowerShell будет на практике именно тем решением для большинства пользователей SMB, которые пожелают применять AOVPN {Прим. пер.: например, как мы уже отмечали, через Ansible.} Самым большим недостатком применения PowerShell для установки параметров AOVPN является то, что PowerShell необходимо запускать в режиме повышенных прав, а это означает что его труднее автоматизировать, поскольку вошедший в систему пользователь (у которого вам необходимо настроить VPN подключение) должен быть локальным администратором для верной работы данного сценария.

Я надеюсь на то, что это свершится и с нетерпением жду того дня, когда они заявят некий шаблон Групповой политики для развёртывания настроек Always On VPN, но до сих пор пока нет ни слова о том будет или нет такой вариант. Все применяют Групповые политики, но не все обладают MDM. Через какое-то время вы прочтёте что развёртывание параметров подключения Microsoft DirectAccess (альтернативы AOVPN) осуществляется при помощи Групповой политики, которая невероятно проста для освоения и управления. Насколько мне известно, на момент написания данных строк DirectAccess имеет большое преимущество перед AOVPN в том, что он обрабатывает развёртывание настроек на стороне клиента, но не забудьте заглянуть в интернет-ресурс Microsoft Docs чтобы ознакомиться с самой последней информацией относительно данного вопроса, так как AOVPN непрерывно совершенствуется и, скорее всего, в этой области технологии произойдут некие изменения.

Теперь, когда мы понимаем что необходимо иметь на стороне клиента для того чтобы осуществить Always On VPN, какие части и фрагменты необходимы на стороне сервера/ инфраструктуры чтобы допускать возможность таких подключений? Что интересно, так это то, что компонент Always On в AOVPN ничего не делает в серверной инфраструктуре; часть Always On целиком обрабатывается на стороне клиента. Поэтому всё что вам требуется, так это убедиться что мы можем получать входящие подключения VPN. Если в настоящее время у вас имеются работники, которые применяют успешные VPN подключения, то с большой долей вероятности у вас уже имеется та инфраструктура сервера, которая необходима для внедрения AOVPN в вашей среде.

Сервер удалённого доступа

Очевидно, что вам требуется некий сервер VPN способный размещать подключения VPN, так? Ну, не совсем очевидно. В Windows Server имеется та роль, в которой размещаются подключения VPN, AOVPN и DirectAccess с названием роли Удалённого доступа (Remote Access), но в действительности вы можете получать работающим Always On VPN и без Windows Server в качестве своего Сервера удалённого доступа (RAS). Так как часть Always On является функциональностью стороны клиента, которая допускает инфраструктуры стороны сервера VPN для размещения сторонними производителями. Даже хотя технически точно говоря, это на самом деле не совсем то, чего ожидает Microsoft; тем не менее именно это я наблюдаю в данной области. На практике, те из нас, кто заинтересован в использовании Microsoft Always On VPN будут применять Microsoft Windows Server, чтобы размещать роль Удалённого доступа, являющейся системой входа к которой будут подключаться наши удалённые клиенты.

Многие люди автоматически полагают что AOVPN состоит в браке с Windows Server 2019, так как это совершенно новая технология, а Server 2019 был только что выпущен, но на самом деле это вовсе не так. Вы можете разместить свою инфраструктуру VPN (роль Удалённого доступа) на Server 2019, Server 2016 или даже Server 2012 R2. Она работает на тех же самых серверах, предоставляя клиентам возможность подключения к своим VPN- соединениям.

После установки в своём новом Windows Server роли Удалённого доступа вы обнаружите что основные настройки вашего VPN происходят в имеющейся консоли RRAS (Routing and Remote Access, Маршрутизации и Удалённого доступа). При настройке своего VPN вы обнаружите наличие доступными к применению большого числа протоколов для установления VPN подключения между клиентом и сервером, а следовательно вам потребуется по крайней мере краткое понимание того чем эти различные протоколы являются. Я перечислю их в порядке строгости и большей безопасности, вплоть до тех, к которым даже не прикасайтесь!

IKEv2

IKEv2 это самый новый, надёжный и в целом наилучший способ подключения клиентских компьютеров через VPN или AOVPN, причём это единственный способ подключения Туннеля устройств AOVPN. IKEv2 требует для аутентификации выдачи сертификатов компьютера вашим клиентским компьютерам. Как правило, это означает, что если вы желаете чтобы клиенты подключались через IKEv2, эти клиенты будут подключены к домену. Очень важно отметить, что для установления соединения IKEv2 применяет порты UDP 500 и 4500.

SSTP

Считается, что это резервный метод для подключения AOVPN- соединений, SSTP применяет для подключения через SSL. По этой причине ему необходим некий установленный сертификат SSL в вашем Сервере Удалённого доступа, но он не требует машинных сертификатов на ваших компьютерах клиентов. SSTP применяет порт TCP 443, и поэтому он способен подключаться даже из очень ограниченных сетей, в которых IKEv2 может отказывать (по причине зависимости IKEv2 от UDP).

L2TP

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

PPTP

Несмотря на то, что в RRAS всё ещё имеется работающий вариант такой настройки, держитесь подальше от такого парня! PPTP, по- существу, был взломан, а если вам всё ещё требуются рабочие подключения на PPTP, вам, в принципе, следует считать такие потоки обмена не зашифрованными и с открытым в Интернете текстом.

CA (Certification Authority)

Сертификаты машины, сертификаты пользователей, сертификаты SSL... О мой бог! Очевидно, вам необходимо быть знакомым с работой с сертификатами и их развёртыванием чтобы воспользоваться Always On VPN. Они становятся всё более и более распространёнными с появлением новых, хорошо защищённых и на любой вкус технологиями. Основным требованием здесь является то, что вам необходимо иметь PKI внутри вашего окружения и хотя бы один сервер Windows CA для выдачи требуемых сертификатов. Ниже перечисляются те места, в которых могут применяться сертификаты инфраструктурой AOVPN:

NPS (Network Policy Server)

NPS - это в целом определённый метод аутентификации для VPN соединений. Когда поступает некий запрос на VPN соединение, ваш Сервер Удалённого доступа передаёт этот запрос на проверку подлинности серверу NPS чтобы удостовериться кто этот пользователь, а также убедиться что у этого пользователя имеются разрешения на регистрацию через данный VPN.

Чаще всего при работе с соединениями Microsoft VPN мы настраиваем NPS таким образом, чтобы он разрешал доступ только пользователям, которые являются частью определённой Группы безопасности Active Directory. Например, если вы создаёте некую группу с названием VPN Users и затем указываете NPS эту группу, он буде позволять выполнение успешных VPN подключений только тем пользователям, которые помещены в эту группу.

NPS является другой ролью Windows Server, которая может размещаться в собственной системе или быть распределённой между несколькими серверами для предоставления избыточности. Как и в случае самой роли Удалённого доступа, для NPS не требуется Server 2019. Вы также имеете возможность её развёртывания на предыдущих версиях Windows Server.

В небольших средах, в которых имеется только один сервер Удалённого доступа, он обычно совмещает и необходимую роль NPS прямо на том же самом сервер, который обеспечивает соединение VPN.

На протяжении наше обсуждения Always On VPN я пару раз уже упоминал Microsoft DirectAccess. DirectAccess является другим видом автоматического подключения аналогичного VPN, но он применяет отличный от Always On VPN подход. В то время как AOVPN применяет ожидаемые хорошо известные протоколы VPN и использует некие хитрые приёмы для автоматического запуска этих традиционных VPN- туннелей, туннели DirectAccess являются отчасти проприетарными. Туннели защищены IPsec и по- существу непробиваемые и обезличенные. Я полагаю, что командам безопасности нравятся имеющиеся защищённость и сложность вызываемая туннелями DA, так как злоумышленники понятия не имеют как вмешиваться в них и как их реплицировать.

В моей практике Microsoft DirectAccess является наиболее распространённой причиной для развёртывания роли Удалённого доступа (Remote Access) администраторами. Самый простой способ представления себе DirectSAccess это рассматривать его в качестве автоматического VPN. Аналогично VPN, его цель состоит в в подключении компьютеров пользователей к корпоративной сетевой среде когда они находятся вне своего офиса. Отличие от VPN, однако, однако, в самом методе, которым пользуются сотрудники чтобы сделать такое соединение возможным. DirectAccess не является неким отдельным программным компонентом, это серия компонентов, которые уже приготовлены в операционной системе Windows и работают в тандеме для предоставления бесшовного доступа пользователя. Что я имею в виду под бесшовностью? Тем же самым способом как подключается AOVPN без какого бы то ни было вмешательства пользователя, этому пользователю ничего не нужно делать чтобы осуществить соединение DirectAccess. Он всё выполняет сам. Как только мобильный компьютер получает интернет- соединение, будь то соединение домашнего Wi-Fi, публичного Интернета в кофейне, или сотовый телефон в стиле Wi-Fi соединения, DirectAccess автоматически строится и применяет любое существующее соединение Интернет без каких- либо требований к вводу со стороны пользователя.

Будете ли вы применять Always On VPN или DirectAccess, когда ваш компьютер подключается автоматически, это сохраняет ваши время и деньги. Время сохраняется потому, что пользователю больше не нужно запускать соединение VPN. Деньги сохраняются потому что время эквивалентно деньгам, а ещё потому, что наличие всегда включённого DirectAccess соединения означает, что исправление ошибок, политики безопасности и управление такими удалёнными компьютерами всегда происходит, даже когда данный пользователь работает удалённо. Вам больше нет нужды дожидаться пока пользователи вернутся назад в офис или чтобы они выбрали запуск своего VPN чтобы запихнуть новые настройки и политики на их компьютеры, всё это происходит где бы они не находились, как только у них появляется доступ к Интернету. Очевидно, что с появлением двух различных технологий удалённого доступа, которые обе ориентированы на автоматическое подключение удалённых пользователей, Microsoft открывает путь для большей производительности рабочих ресурсов. Термины дружественный пользователю и VPN ранее никогда не шли рука- об- руку, но в последних версиях операционных систем Windows именно это и составляет основную цель.

DirectAccess уже присутствовал у нас уже начиная с редакции Windows Server 2008 R2, но я всё ещё регулярно натыкаюсь на людей, которые никогда о нём не слышали. На раннем этапе было достаточно сложно развёртывать и и следовать большому числу весьма скупых ограничений (требований), однако многое изменилось за последние несколько лет и DirectAccess теперь проще в развёртывании и приносит гораздо больше преимуществ при работе в вашей среде.

Одним из требований скупости, которое я упоминал ранее для использования состоит в необходимости IPv6 внутри вашей сетевой среды. Для самой первой версии DirectAccess это было неуместное требование. Я говорю неуместное, потому что и сегодня, в 2019, почти никто не работает с IPv6 внутри своей корпоративной сетевой среды, а теперь давайте представим что было много лет тому назад, когда эта технология была выпущена - большое число администраторов даже ещё не знают что такое IPv6. К счастью, обязательные требования для IPv6 внутри вашей сетевой среды ушли в прошлое. Я повторю, просто для того варианта, что кто- то не уделил этому значительного внимания, или прочитал старые, утратившие силу документы TechNet - у вас нет необходимости в IPv6 для применения DirectAccess! Почему я кричу? Потому что я видел слишком много случаев в которых DirectAccess рассматривался компаниями, но этот проект отставлялся в сторону, потому что прочитав TechNet, они делали вывод что требуется IPv6 и поскольку пока ещё никто не использует IPv6 в их сетевой среде, они отклоняли DirectAccess, как нечто, что не будет работать. Вам абсолютно не нужно наличие работающего IPv6 в вашей сетевой среде чтобы сделать DirectAccess функционирующим, однако важно понимать как DirectAccess использует IPv6, потому что вы начнёте встречать его, раз ваше решение пойдёт этой дорогой.

Когда я сижу дома и работаю на своём ноутбуке компании, DirectAccess соединяет меня с моей корпоративной сетевой средой. Моя внутренняя сетевая среда на работе абсолютно не является IPv6 внутри себя, на данный момент у нас имеется полностью IPv4 сетевая среда. Это так для большинства компаний в наши дни. Однако, когда я открываю приглашение командной строки и запускаю ping к одному из своих серверов со своего ноутбука DirectAccess, вот что я вижу - мои извинения за подчищенный вывод данного экранного снимка:

Что это, чёрт возьми! Для меня выглядит как IPv6. Именно здесь вступает в игру IPv6 с DirectAccess. Весь обмен, который осуществляется между находящейся во всемирном Интернете частью моего соединения, а именно между моим ноутбуком и сервером DirectAccess, расположенным в моём центре обработки данных, это обмен IPv6. Моя внутренняя сетевая среда это IPv4, причём мой сервер DirectAccess имеет в ней только адреса IPv4, и тем не менее, мой туннель DirectAccess переносит мой обмен с применением IPv6. Это сердцевина того, как работает DirectAccess, и она не может быть изменена. Ваш DA ноутбук отправляет шифрованные IPsec IPv6 пакеты через Интернет в ваш сервер DA и когда сервер DA принимает эти пакеты, он имеет возможность раскрутить их обратно в IPv4 чтобы отправить их серверу получателю внутри вашей корпоративной сетевой среды. Например, когда я открываю свой Outlook и пытаюсь соединиться со своим сервером Ecxhange, мои пакеты Outlook проходят через туннель DirectAccess в качестве IPv6. Когда эти пакеты попадают в мой сервер DirectAccess, этот сервер обращается к серверу DNS чтобы определить, является ли Exchange сервер IPv4 или IPv6. Если вы на самом деле работаете во внутренней среде с IPv6, и сервер Exchange доступен через IPv6, сервер DA просто отправляет пакеты IPv6 дальше серверу Exchange.

Соединение выполнено! Если, с другой стороны, вы работаете с IPv4 внутри своей сетевой среды, ваш сервер DA видит только отдельную запись хоста "A" в DNS, что означает, что ваш сервер Exchange является только поддерживающим IPv4. Ваш сервер DirectAccess затем обрабатывает такой пакет IPv6, заменяя его обратно на IPv4 и отправляет его своим путём в ваш сервер Exchange. Имеются две технологии, которые выполняют такие манипуляции с пакетами и они называются DNS64 и NAT64, с которыми вы возможно уже сталкивались в какой- либо документации если вы что-то читали про DirectAccess в Интернете. Цель этих технологий состоит в изменении входящего потока IPv6 в IPv4 для тех сетевых сред, в которых это необходимо - чем являются практически все сети на текущий момент - и инкапсулировать (вкручивать) возвращаемый обмен из IPv4 назад в IPv6 с тем, чтобы он мог преодолеть обратный путь в компьютер клиента DirectAccess через туннель IPsec на основании IPv6, который соединяет вашего клиента DA с серверов DA через Internet.

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

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

Подключение к домену

Самое первое большое требование состоит в том, что вовлекаемая в DirectAccess система должна быть подключена в домен. Ваш сервер или сервера DA должны быть присоединены к вашему домену и все клиентские компьютеры, которые вы хотите иметь подключёнными к DA также должны входить в состав домена. Участие в домене является необходимым для целей аутентификации, а также потому, что настройки клиента DirectAccess, которые должны быть применены к таким мобильным компьютерам возвращаются назад в эти компьютеры через Групповую политику. Я всегда намеренно указываю это требование на ранней стадии процесса планирования, так как оно означает, что пользователи, которые приобретают свои собственные ноутбуки в розничной продаже обычно не имеют возможности применять DirectAccess - пока они не каким- либо образом не получат возможность добавления своих компьютеров в ваш домен - и таким образом DA является технологией, которая в действительности разработана для управления соединения ваших корпоративных активов, которые вы можете подключать к своему домену. Также важно осознавать это требование с точки зрения проблем безопасности, так как ваш сервер или сервера DirectAccess обычно размещаются на границе вашей сетевой среды. Это обычное явление для внешних NIC на сервере DA располагаться внутри зоны DMZ, но они также должны быть подключёнными к домену, что может быть не совсем тем, что вы применяете для систем в пограничной сетевой среде (сетевой среде периметра).

Поддерживаемые операционные системы клиента

Не все операционные системы клиента Windows содержат все необходимые компоненты, которые требуются чтобы сделать DirectAccess работающим. Корпоративные (Enterprise) версии соответствуют этому, что в основном покрывает крупный бизнес, который владеет операционными системами Microsoft, однако это несомненно не включает всех. Я видел множество небольших компаний, которые применяют Профессиональную (Professional) версию или даже Home SKU для своих клиентских машин, а эти версии не содержат компоненты DirectAccess. Вот перечень операционных систем, которые точно поддерживают DirectAccess. В процессе своего планирования вам необходимо убедиться, что ваши мобильные компьютеры работают под их управлением:

Серверы DirectAccess получают один или два NIC?

Один большой вопрос, на который следует ответить даже до начала установки роли Удалённого доступа на вашем новом сервере - сколько NIC необходимо для этого сервера? Существует два поддерживаемых метода для реализации DirectAccess.

Режим с одним NIC

Ваш сервер DirectAccess может быть настроен всего с одним NIC. В этом случае вы обычно подключаете своё сетевое соединение напрямую в свою внутреннюю сетевую среду с тем, чтобы она имела доступ ко всем внутренним ресурсам, с которыми такие компьютеры клиентов будут взаимодействовать в процессе своих пользовательских сеансов DA. Чтобы получить обмен от Интернета к вашему серверу DirectAccess, вам необходимо установить NAT (Network Address Translation, Трансляцию сетевых адресов) из общедоступных адресов IP в какие- либо внутренние IP адреса, которые вы должны назначит своему серверу DA. Многие администраторы сетевой безопасности не любят этот метод, так как он означает создание NAT, что приводит к обмену корпоративной сетевой среды с Интернетом напрямую без протекания через какую- либо DMZ.

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

Сдвоенный NIC

Здесь у нас имеются два сетевых адаптера в нашем сервере DirectAccess. Внутренний NIC обычно подключается напрямую в нашу корпоративную сетевую среду, а расположение вашего Внешнего NIC может меняться в зависимости от вашей организации. Мы обсудим все за и против для того куда помещать Внешний NIC в идущих сразу далее разделах данной главы. Граничный режим с двумя NIC является вариантом, при котором DirectAccess работает наилучшим образом. Как вы вероятно помните с самого начала данной книги, реализация Windows Server со множеством NIC, означает, что у вас будет Групповой сервер (multihome) и вам необходимо выполнить надлежащим образом сетевые настройки. При использовании сервера Удалённого доступа ваш Внутренний NIC всегда будет тем, который получает настройки Шлюза по умолчанию, поэтому вам необходимо проверить это и следовать таком правилу с тем, чтобы не настраивать Шлюз по умолчанию (Default Gateway) в свойствах Внутреннего NIC. С другой стороны вы хотите на самом деле настроить адреса DNS сервера в своих свойствах Внутреннего NIC, но при этом вы не хотите настраивать сервера DNS для своего Внешнего NIC. Так как данный сервер является Групповым (multihomed), вам скорее всего потребуется создать некоторые операторы для маршрутизации чтобы добавить ваши корпоративные подсети в таблицу маршрутизации Windows этого сервера прежде чем он сможет успешно отправлять и принимать сетевой обмен. Единственные сети, которые следует размещать для добавления статических маршрутов, должны быть небольшими сетями, причём все ваши внутренние устройства должны быть в отдельной подсети. Если это имеет место, тогда вам необходимо ввести статическую таблицу маршрутов. Однако большинство корпоративных сетевых сред занимает множество подсетей и в этом случае вам следует вернуться назад к разделу, в котором мы обсуждали Групповые сервера и то, как строить такие операторы маршрутов.

Более двух NIC

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

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

Делать NAT или нет?

Теперь, когда вы определились с раскруткой двух NIC в своём сервере DirectAccess, куда нам нужно подключать свой Внешний NIC? Существует два распространённых места, куда можно подключить такие Внешние сетевые интерфейсы, однако в зависимости от того, что вы выберете, результат вашей сетевой среды DirectAccess может быть совершенно различным. Перед тем как мы начнём обсуждать реальное размещение NIC, я бы хотел определить пару протоколов, которые будут важны для понимания, потому что они имеют отношение к очень большому множеству ответов на этот вопрос о размещении NIC. Когда ваш ноутбук DirectAccess выполняет соединение с вашим сервером DirectAccess, он применяет три перехода протоколов туннелирования IPv6. Этими протоколами являются 6to4, Teredo и IP-HTTPS. Когда клиент DA соединяется с его туннелями DA, он автоматически выбирает какой из этих протоколов лучше применять, основываясь на общем числа пользователей текущего соединения Интернет. Все эти три протокола выполняют одну и ту же функцию для соединения DirectAccess; их задание состоит в захвате всего потока пакетов IPv6 приходящих от вашего ноутбука и инкапсулирование их внутри IPv4 с тем, чтобы такой обмен мог успешно осуществляться в Интернете IPv4. Когда такие пакеты поступают в ваш сервер DirectAccess, у них меняется заголовок с тем, чтобы сервер DA мог обрабатывать такие пакеты IPv6.

6to4

Клиенты DA будут пытаться установить соединение при помощи 6to4 (IPv6-to-IPv4) только когда удалённый ноутбук имеет реальный общедоступный адрес IP Интернета. Это редко имеет место в наши дни, когда испытывается голод в адресах IPv4, поэтому 6to4 обычно не применяется никакими компьютерами клиентов DirectAccess. На самом деле, это может представлять свой собственный набор проблем в случае, когда пользователи соединяются со своих карт мобильных телефонов в их ноутбуках и поэтому общим выбором является запрет данного адаптера 6to4 в компьютерах клиентов в качестве наилучшей практики.

Teredo

Когда клиенты DA соединяются с Интернетом при помощи неких частных IP адресов - так как это происходит в домашнем маршрутизаторе или общедоступном Wi-Fi маршрутизаторе - они пытаются соединиться при помощи протокола Teredo. Teredo использует поток UDP для инкапсуляции подобных пакетов и, пока соединение пользовательского Интернет не запрещает исходящий UDP 3544, Teredo будет обычным соединением и будет предпочтительным протоколом передачи для соединения DirectAccess.

IP-HTTPS

Если нет возможности соединения Teredo, например, когда пользователь пользуется сетевой средой, которая блокирует исходящий UDP, тогда DirectAccess вернётся назад к применению IP-HTTPS, произносимому как IP over HTTPS (IP поверх HTTPS). Этот протокол инкапсулирует ваши пакеты IPv6 в IPv4, однако затем обёртывает их вовнутрь заголовка HTTP и шифрует при помощи TLS/SSL перед отправкой этого пакета через всемирный Интернет. Это на самом деле делает соединение DirectAccess потоком SSL, в точности как когда вы просматриваете некий вебсайт HTTPS.

Установка истинного контура - в Интернет

Установка истинного контура - в Интернет

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

Установка позади NAT

Более распространённым действием для вашей сетевой команды будет пожелать разместить внешний NIC вашего сервера DirectAccess позади межсетевого экрана внутри DMZ. Это обычно означает создание некоторой NAT для привнесения обмена на ваш сервер. Хотя это полностью возможно и лучше защищает сам сервер DirectAccess от всемирного Интернета, оно поступает с большой обратной стороной. Когда вы устанавливаете свой сервер DA позади NAT, Teredo больше не работает. В действительности мастер настройки DirectAccess распознает случай, когда у вас нет некоего частного адреса IP перечисленным на внешнем NIC и он даже не будет пытаться включить Teredo.

Когда Teredo недоступен, все ваши клиенты DirectAccess будут соединяться при помощи IP-HTTPS. Так зачем нам упоминать про Teredo, если он недоступен? Потому что он является более эффективным протоколом, нежели IP-HTTPS. Когда Teredo туннелирует пакеты, он просто заключает IPv6 вовнутрь IPv4. Сам поток обмена DirectAccess уже и всегда зашифрован IPsec поэтому для протокола Teredo нет необходимости выполнения какого- либо дополнительного шифрования. С другой стороны, когда IP-HTTPS туннелирует пакеты, он берёт уже зашифрованный поток обмена IPsec и шифрует его второй раз при помощи SSL. Это означает, что все все приходящие пакеты являются предметом дополнительной обработки и циклов ЦПУ и это работает в сторону замедления соединения. Это также создаёт дополнительную аппаратную нагрузку на сам сервер DirectAccess, так как он теперь дважды обрабатывает процесс шифрования.

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

В Windows 8 и Windows 10 были добавлены некие меры противодействия, которые помогают такому несоответствию в скорости. Эти более новые операционные системы достаточно интеллектуальны чтобы быть в состоянии отклонять часть SSL своего туннеля IP-HTTPS применяя нулевой алгоритм шифрования, что означает, что IP-HTTPS не выполняет повторное шифрование и его производительность намного ближе к производительности Teredo. Однако, это работает только с новыми клиентскими операционными системами и всё ещё не работает в определённых случаях. Например, когда вы включаете свой сервер DirectAccess также и для поддержки связей VPN, или если вы выбираете применение системы одноразовых паролей (OTP, One-Time-Password) наряду с DirectAccess, тогда нулевой алгоритм будет отключён, потому что в данной ситуации это может представлять некий риск для безопасности и, следовательно, даже ваши компьютеры Windows 8 и Windows 10 будут выполнять двойное шифрование когда вы соединяетесь через IP-HTTPS. Как вы можете видеть, было бы существенным преимуществом иметь Teredo включённым и поэтому делайте его доступным для всех компьютеров которые могут осуществлять такое соединение через Teredo.

Чтобы просуммировать, вы несомненно можете установить внешний NIC своего сервера DirectAccess позади NAT, однако имейте в виду, что все ваши компьютеры клиентов будут соединяться с применением протокола IP-HTTPS, и важно понимать все стороны реализации такого варианта.

Сервер сетевой локации

Этот основной компонент в инфраструктуре DirectAccess является чем- то, что даже не существует в самом сервере DA, или, по крайней мере, не должен, если вы настраиваете вещи должным образом. NLS (Network Location Server, Сервер сетевой локации) это просто вебсайт, который работает внутри вашей корпоративной сетевой среды. Этот сервер не должени иметь возможности доступа через Интернет, его на самом деле не должно быть. NLS применяется как часть механизма определения внутри/ за пределами в ваших компьютерах клиента DirectAccess. Всякий раз, когда клиент DA получает некое сетевое соединение, он начинает поиск такого вебсайта NLS. Если он может видеть этот сайт, тогда он знает что он находится внутри своей корпоративной сетевой среды и DirectAccess не требуется, поэтому он выключает себя. Однако если контакт с вашим NLS невозможно установить, это означает, что вы находитесь вовне своей корпоративной сетевой среды и ваши компоненты DirectAccess начнут свою подстройку.

Эту предпосылку легко удовлетворить - всё что вам нужно сделать, это развернуть некую ВМ и установить службу IIS на неё чтобы разместить такой новый вебсайт или же можете просто добавить новый вебсайт на существующем веб сервере в вашей сетевой среде. Существует только два момента, на которые стоит обратить внимание при настройке вашего вебсайта NLS. Первая это то, что он должен быть сайтом HTTPS, и поэтому ему необходим некий сертификат SSL. Мы будем обсуждать применение сертификатов в DA, включая и этот в нашем следующем разделе этой главы. Кроме того, чтобы убедиться, что данный вебсайт доступен через HTTPS вы также должны обеспечить чтобы такое имя DNS, которое вы применяете для взаимодействия с данным вебсайтом является уникальным. Вы определённо пожелаете сделать это, поскольку всякий раз когда вы выбираете имя для этого вебсайта NLS, оно не должно разрешаться когда компьютер клиента находится вне пределов вашей корпоративной сетевой среды. Это должно быть заложено в проекте, потому что вы очевидно не желаете чтобы ваши клиенты DA были в состоянии успешно взаимодействовать с вашим вебсайтом NLS когда они работают удалённо, так как это выключит затем их соединение DirectAccess.

Соображение, по которому я ввожу такое уникальное имя DNS состоит в том, что я зачастую наблюдаю администраторов DirectAccess, применяющих существующее внутренний вебсайт в качестве своего вебсайта NLS. например, если у вас имеется https://intranet исполняющийся в качестве сайта SharePoint, вы можете просто применять его в настройке DA в качестве определения для своего сервера NLS. Однако, если вы настроете его таким образом, вы быстро обнаружите, что никто из удалённо работающих не может осуществлять доступ к вашему вебсайту https://intranet. Это происходит по причине, заложенной в архитектуре, так как ваша среда DA рассматривает ваш вебсайт intranet как являющийся сервером NLS и вы не можете разрешить его имя, работая мобильно. Каково решение этой проблемы? Убедитесь что вы выбрали новое имя DNS для его применения в качестве такого вебсайта NLS. Подойдёт что- то навроде https://nls.contoso.local.

Наиболее важная часть про ваш Сервер сетевой локации на которой я хочу сделать ударение состоит в том, что вам абсолютно необходимо реализовывать этот вебсайт на некотором сервере в вашей сетевой среде, который не является самим вашим сервером DirectAccess. Когда вы работаете под управлением своего мастера настройки DA, вы встречаете экран в котором мы определяем NLS, что рекомендуется выполнить, однако он также предоставляет возможность самостоятельно разместить этот вебсайт NLS прямо на самом вашем сервере DirectAccess. Существует множество плохих вещей, которые могут произойти когда вы совместно размещаете NLS на вашем сервере DA, поэтому держитесь от этого подальше. Выполнение NLS на вашем сервере DA также ограничит ваш потенциал DirectAccess в будущем, так как некоторые расширенные настройки DA требуют от вас в любом случае удалить NLS с вашего сервера DA, поэтому вы можете сделать это правильно сразу при самой первой установке. Изменение вашего вебсайта после того как у вас работает DA в промышленной реализации может быть очень коварным и часто выходит боком. Мне приходилось помогать множеству компаний перемещать их вебсайт NLS после того, как они осознавали что они не могут выполнять совместное размещение NLS на своём сервере DA если и когда они пожелали добавить некий второй сервер DirectAccess для роста или избыточности. Вот экранный снимок того раздела в вашем мастере настройки DA, в котором вы выбираете местоположение NLS, проверьте что вы остались с верхним выбором!

Применяемые в DirectAccess сертификаты

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

Основное предварительное требование состоит в том, что у вас где- то в вашей сетевой среде должен присутствовать сервер CA Windows. Качество реализации вашего PKI не так важно для DirectAccess. Нам просто необходима возможность выпуска сертификатов для вашего сервера DA и клиентов. Существует три места, в которых применяются сертификаты в DirectAccess, причём два из них это сертификаты SSL.

SSL сертификат веб- сервера NLS

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

SSL сертификат сервера DirectAccess

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

Сертификаты машин на сервере DA и все клиенты DA

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

Во всех серверах CA Windows существует встроенный шаблон с названием Computer, и именно этот шаблон имеется в точности тем, что нам нужно сделать для DirectAccess, поэтому зачастую мы просто устанавливаем некоторую политику для выпуска сертификатов компьютера всем своим машинам DA. Если вы не хотите применять предварительно построенный шаблон по какой- то причине, вы определённо можете создать свой собственный персональный шаблон сертификата для этой цели. Когда вы настроите свой собственный шаблон сертификата, просто проверьте что он соответствует следующим критериям:

Я должен здесь отметить, хотя я на самом деле не хочу этого делать, что выпуск таких сертификатов совершенно не является обязательным, чтобы заставить работать DirectAccess. Если у вас на стороне клиента находится Windows 8 или более новая версия, тогда существует возможность получить работающий DA без сертификатов машины. Вместо этого они могут использовать нечто под названием Kerberos proxy для своей аутентификации при построении туннелей IPsec, однако я настоятельно рекомендую оставаться с сертификатами. Применение сертификатов как части процесса аутентификации делает соединение более стабильным и более безопасным. Кроме того, как и в случае с размещением NLS, если вы собираетесь выполнять некие дополнительные функции при помощи DirectAccess, например, балансировку нагрузки или Множественный сайт, или даже просто желаете чтобы некоторые компьютеры Windows 7 продолжали соединяться через DA, тогда вам в любом случает потребуются сертификаты. Поэтому просто следуйте практическому опыту в самом первом месте и выпускайте такие сертификаты даже до того, как вы начали проверять DirectAccess.

После выбора необходимых проектных решений и реализации предварительных требований, о которых мы говорили только что, наконец настало время установить вашу роль Удалённого доступа (Remote Access) на ваш новый сервер DirectAccess! После того, как вы установите эту роль, подобно тому как это происходит для большого числа ролей в Windows Server 2016, вы будете приглашены к тому, чтобы выполнились дополнительные настройки необходимые для применения в этой роли. На самом деле, если вы следуете жёлтому маркеру восклицания внутри Диспетчера сервера, единственный предоставленный вам вариант это Open the Getting Started Wizard. Ага! Это именно то, на что вам не следует нажимать.

Вашим домом для настроек является Remote Access Management Console (Консоль управления Удалённым доступом), которая теперь, когда наша роль Удалённого доступа установлена, достижима изнутри меню Диспетчера сервера Tools. Пройдите вперёд и теперь нам предоставляется некий выбор:

Не кликайте по Run the Getting Started Wizard! GSW является ярлыком для реализации DirectAccess, разработанный исключительно для получения DirectAccess работающим настолько быстро, насколько это возможно, возможно для быстрого доказательства работоспособности самой концепции. Однако не существует никаких обстоятельств для того чтобы вы доверили GSW своё производственное окружение DA, так как в своих усилиях сделать настройку быстрой и простой многие принимаемые для вас решения конфигурации не являются практичными.

Вы можете пожелать проверить всё и вместо этого кликаете на Run the Remote Access Setup Wizard, когда вы получаете первое приглашение в данной консоли, что выполнит полный набор экранов настройки DirectAccess. Вся настройка DA состоит из четырёх различных шагов, причём каждый содержит небольшое число экранов, по которым вы можете перемещаться для выбора соответствующих вам опций настройки. Существует хорошая детализация этих экранов для того чтобы представить что каждый из них подразумевает и какими являются ваши варианты, поэтому не бойтесь погрузиться в них и настроить надлежащим образом. Если вы уже настроили DirectAccess и при этом воспользовались Getting Started Wizard, DA может у вас и работать, но при этом это может оказаться не столь эффективным и безопасным. Ниже приведён короткий перечень тех причин почему именно Getting Started Wizard не может представлять для вас интереса. Существуют некоторые вещи, которые напрямую идут вразрез с практическим опытом установки DirectAccess:

Вы в хорошем состоянии преодолеваете свой путь предоставления пользователям возможностей удалённого доступа с этого нового сервера. Как и со многими сетевыми устройствами, когда вы установили все свои настройки на некотором удалённом сервере, достаточно распространено для системных администраторов отойти в сторону и дать ему работать. Не существует потребности в выполнении сопровождения или изменения настроек, раз он работает хорошо. Однако, Remote Access Management Console (Консоль управления Удалённым доступом) в Windows Server 2019 полезна не только для установки частей и фрагментов вашего удалённого доступа, но также и для целей мониторинга и составления отчётов. При работе через DirectAccess это ваш дом практически для всего: для настройки, управления и мониторинга. На стороне VPN/ AOVPN вашего инструментария удалённого доступа вы будете производить многие решения относительно настройки внутри RRAS, но RAMC является тем местом, в которое следует проходить при проверке мониторинг стороны сервера, мониторинг подключений клиентов и статистические отчёты. При использовании DA, VPN или некого сочетания их обоих, RAMC является тем инструментом, с которым вам удобно.

Давайте заглянем вовнутрь этой консоли с тем, чтобы вы ознакомились с различными экранами с которыми вы будете взаимодействовать:

Экран настроек достаточно хорошо объясняет себя сам, это именно то место, которое вы захотите посетить чтобы создать свою начальную конфигурацию Удалённого доступа и в котором вы будете обновлять все настройки в будущем. Как вы можете обнаружить в приведённом снимке экрана, у вас есть возможность настраивать DirectAccess, VPN и Web Application Proxy прямо в данной Remote Access Management Console.

Существует не так много настроек как это происходит в VPN, в действительности у вас имеется только один экран параметров, в котором вы определяете какой тип адресов IP передаётся вниз клиентам, соединяющимся через VPN и как обрабатывать аутентификацию VPN. Из данного окна это не очевидно, поэтому я хочу указать это отдельно. Внутри раздела DirectAccess and VPN вы кликаете кнопку Edit…, приведённую на Step 2, это запустит минимастер Шага 2. Самый последний экран этого минимастера называется VPN Configuration. Это именно тот экран, в котором вы можете настроить данные настройки IP адресов и аутентификации для своего соединения VPN:

Инструментальная панель Удалённого доступа (Remote Access Dashboard) предоставит вам 30 000 футов обзора состояния вашего сервера Удалённого доступа. У вас имеется возможность быстрого просмотра состояния компонентов работающих на данном севере, были или нет накачены самые последние изменения настроек и некоторые суммарные значения ближе к концу о том сколько соединений DirectAccess и VPN было установлено.

Если у вас имеется желание углубиться ещё в то что происходит на стороне сервера при соединении, именно страница Operations Status предоставит вам информацию об этом. Здесь вы сможете увидеть немного больше подробностей по каждому из компонентов, работающих под капотом ваших произошедших соединений DirectAccess и VPN. Если какие-то из них имеют проблему, вы можете кликнуть по определённой компоненте и для получения некоторой дополнительной информации. Например, в качестве проверки, я выключил свой веб сервер NLS в сетевой среде своей лаборатории и могу обнаружить на своей странице Operations Status, что NLS помечается флагом ошибки.

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

Важно отметить, что ваш экран Remote Client Status отображает только работающие, активные соединения. Здесь не существует никакой сохраняемой информации.

Как вы уже догадались, именно этот экран вам стоит посетить если вы хотите посмотреть историческую информацию об удалённых соединениях. Этот экран почти в точности повторяет ваш экран Remote Client Status, за исключением того, что он имеет возможность создавать отчёты для истории данных выбираемых из выбранного вами диапазона дат. Когда эти данные отображены, у вас также имеются точно такие же возможности поиска и фильтрации, которые у вас имеются в экране Remote Client Status.

По умолчанию составление отчётов отключено, однако вам просто нужно переместиться на страницу Reporting и кликнуть Configure Accounting. Как только они включены, вам будут предоставлены возможности по сохранению исторической информации. Вы можете выбирать сохранение своих данных в локальном WID или на удалённом сервере RADIUS.

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

Последняя панель окнаRemote Access Management Console на которую я хочу обратить внимание это полоса Tasks (Средства, задачи), в правой стороне вашего экрана. Действия и варианты, которые отображаются в этой полосе задач изменяются в зависимости от той части консоли, по которой вы перемещаетесь. Не забудьте обратить внимание на эту сторону вашего экрана для настройки некоторых дополнительных функций. Некоторыми примерами доступных задач являются создания используемых отчётов, обновление вашего экрана и настройка конфигураций блансировки сетевой среды или Множественных сайтов если вы работаете с несколькими серверами удалённого доступа.

VPN был распространённым на протяжении очень длительного времени, что сделало его достаточно знакомой идеей для всех работающих в ИТ. Несомненно, Always On VPN привносит свой совместный ресурс и новые возможности, но то, что находится под капотом AOVPN это запуск традиционно настраиваемого подключения VPN, а следовательно сам поток подключения аналогичен тому что нам уже известно. В этой главе мы также немного обсуждали DirectAccess, чтобы быстро посвятить вас в эту эволюцию так называемого корпоративного удалённого доступа. Теперь, когда вы знакомы с этими двумя великолепными решениями встроенными в Windows Server 2019 для возможности работы с мобильного рабочего места, какое из них лучше?

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

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

В таких видах ситуаций, когда используются домашние или приобретённые персонально компьютеры, VPN может лучше соответствовать вашим задачам. Вы можете подключать VPN (в том числе и Always On VPN) с не подключённой к домену машины Windows 10, и вы даже можете установить соединения с VPN для множества устройств, не поддерживающих Microsoft. iOS, Android, Windows Phone и даже Mac - все эти имеющие клиента VPN платформы могут применяться для подключения к прослушивающему VPN серверу Удалённого доступа Windows Server 2019. Если DirectAccess ваше единственное решение для удалённого доступа, у вас не будет возможности осуществлять связь с платформой для не подключённых к домену устройств.

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

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

Тем не менее, Always On VPN привносит автоматизацию и бесшовность в существующий мир VPN. AOVPN паочти также бесшовен как и DirectAccess. Я сказал почти, потому что на момент написания этих строк сложно представить себе в достаточной степени мир Туннеля устройств. Это означает, что большинство компаний раскатывают AOVPN применяя только Туннель пользователя. При сценарии туннеля пользователя сам VPN запускается автоматически, но только после того как сам пользователь уже прошёл свой экран регистрации. Это означает, что в такой ситуации DirectAccess всё ещё сохраняет преимущество над AOVPN, так как DA подключается бесшовно и для экрана регистрации. Это делает возможным для подключаемых через DA машин сбросы пароля и регистрацию новых пользователей домена. Я надеюсь, что последующие улучшения позволят устройствам AOVPN и Туннелям пользователя хорошо сосуществовать, что обеспечит истинное постоянное подключение клиентов AOVPN.

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

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

DirectAccess и Always On VPN являются встроенной сущностью. Он находится внутри вашей операционной системы. Нет никакого программного обеспечения для установки, никакого программного обеспечения для обновлений, никакого программного обеспечения для повторной установки в случае падения. Всё что нужно DA и AOVPN уже находится в Windows сегодня, вам нужно просто воспользоваться этим. О, да, и он бесплатен, хорошо, его стоимость в любом случае включена в вашу лицензию Windows. Нет никаких пользовательских CAL, никаких дополнительных обязанностей доплаты за лицензии связанные с реализацией одной из технологий удалённого доступа Microsoft.

Если ваши рабочие ресурсы состоят из машин Windows 10, Microsoft DirectAccess или Microsoft Always On VPN являются очевидными победителями при сопоставлении с любым решением подключения VPN стороннего разработчика.

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

Каково решение проблем с паролем для VPN? Сбросить пароль пользователя и затем заставить пользователя прийти в ваш офис чтобы выполнить его работу на его ноутбуке. Да, такие виды телефонных вызовов случаются каждый день. Это засада, но на самом деле потенциальная проблема в самом VPN.

Что является хорошей новостью? Новые решения Удалённого доступа Microsoft не имеют таких проблем! Так как DA и AOVPN являются частью операционной системы, они имеют возможность соединяться всякий раз, когда включён Windows. Это включает и окно регистрации! Даже если я нахожусь в окне регистрации или в заблокированном экране, а система ожидает моего ввода имени пользователя и пароля, поскольку у меня имеется доступ в Интернет, у меня также имеется и туннель DirectAccess или некий Туннель устройства Always On VPN. Это означает, что я могу активно выполнять задачи управления паролем. Если срок действия моего пароля истёк, и мне нужно его обновить, это работает. Если я забыл свой пароль и не могу войти в свой ноутбук, я могу связаться со службой поддержки и просто попросить их сбросить мой пароль. Затем я могу немедленно зарегистрироваться в своём ноутбуке DirectAccess или AOVPN с новым паролем прямо из своего дома.

Другая крутая функция, которую делает возможным такая бесшовность состоит в возможности регистрации с новой пользовательской учётной записью. Вы когда- нибудь регистрировались в своём ноутбуке с другой учётной записью пользователя чтобы что- нибудь проверить? Да, это прекрасно работает в DirectAccess и AOVPN. Например, я сидел дома и мне было нужно помочь парням из отдела продаж решить проблему определённого вида с полномочиями на файл. Я предположил, что если я что- то буду делать с их учётной записью я смогу что- то понять, поэтому у меня возникло желание зарегистрироваться в своём ноутбуке под их именем чтобы проверить это. Проблема состояла в том, что их пользовательская учётная запись никогда ранее не подключалась к моему компьютеру. При наличии VPN у вас нет никаких шансов. Это никогда не будет работать. При наличии DirectAccess это плёвое дело! Я просто завершаю сеанс, набираю их имя пользователя и пароль, и - ура! Я зарегистрировался, хотя всё ещё нахожусь дома в своей пижаме.

Одним из самых распространённых связанных с VPN вызовов группы поддержки всегда был Я не могу подключить VPN из этого отеля. К сожалению, большинство применяемых для соединения VPN протоколов не дружат с межсетевыми экранами. Скорее всего ваш домашний маршрутизатор пропускает весь исходящий обмен, поэтому при подключении по некому протоколу VPN из вашего домашнего подключения к интернету всё будет шито- крыто. Но возьмите тот же самый ноутбук и подключите его через общедоступное соединение в кофейне, гостинице или аэропорте и внезапно ваш VPN отказывает в подключении со странными ошибками. Как правило это происходит из- за того, что общедоступное интернет- подключение пропускает свой обмен через межсетевой экран с ограничением портов. Такие межсетевые экраны ограничивают исходящий доступ, часто блокируя, например, ICMP и UDP, что может оказывать воздействие на VPN подключения. В наиболее серьёзных ситуациях эти межсетевые экраны могут разрешать всего лишь два исходящих порта: TCP 80 для HTTP и TCP 443 для HTTPS чтобы выполнять веб обмен. А далее они блокируют всё прочее.

В том случае, когда вы всё- таки пребываете за межсетевым экраном с ограничением портов, как наши новые технологии удалённого доступа отрабатывают подключение?

DirectAccess построен так чтобы отрабатывать подобный сценарий сразу после установки. Помните те различные протоколы, которые может применять DA для подключения? Резервный вариант имеет название IP-HTTPS и он пропускает свой обмен внутри TCP 443. Поэтому, даже располагаясь за большинством требовательных межсетевых экранов DA продолжит без колебаний обычные подключения в автоматическом режиме.

Always On VPN обычно развёртывается (как это и должно быть) с учётом передового опыта, который содержит приоритет для IKEv2 в качестве протокола подключения VPN. Фактически, некие компании применяют AOVPN исключительно с IKEv2. Для этих парней межсетевые экраны с ограничением портов будут причинять вред, так как для таких подключений VPN пользователей для соединения применяются порты UDP. Это не сработает. Итак, надеемся, что главное что вы извлекаете из этого состоит в том, что при настройке AOVPN вам надлежит убедиться что вы предприняли необходимые шаги чтобы также включить и соединения SSTP VPN в качестве резервного метода. SSTP также допускает обмен внутри TCP 443, который затем может получать обмен даже через жёсткие межсетевые экраны.

На самом деле, я недавно работал кое с над в точности таким сценарием, когда они пытались решить что им стоит установить для своих удалённых компьютеров: DirectAccess или Always On VPN. Это была компания, которая управляет компьютерами для большого числа больниц и кабинетов врачей, причём у них не было подключений WAN для таких офисов. Однако в офисах имелся доступ к интернету, а потому нам требовалась возможность постоянного автоматического подключения таких компьютеров к главному центру обработки данных. До этого момента либо DirectAccess, либо Always On VPN мог бы отвечать всем требованиям. Затем во время тестирования мы выяснили, что многие сетевые среды больниц ограничивают исходящий доступ в интернет. Единственным способом подключения для DirectAccess был IP-HTTPS, а для AOVPN единственным вариантом было соединение через SSTP. Нет проблем, так? За исключением того что не так. Видите ли, эти удалённые рабочие станции зачастую рассматривались как киоски, переносные машины, с которых могут работать десятки различных сотрудников, способные подойти в любой момент. Зачастую это означает, что в этих машинах могут регистрироваться пользователи, которые раньще никогда не заходили в них и, следовательно, у них нет кэшированных учётных данных в данных компьютерах.

Если вы ещё не поняли, у нас не оставалось никакого иного выбора, кроме как воспользоваться при подобном сценарии DirectAccess. DA всегда подключён уже на экране входа в систему, даже когда он применяет свой "резервный" метод IP-HTTPS. Always On VPN, тем не менее, пребывая в экране регистрации может работать только с IKEv2, поскольку Туннель устройства требует IKEv2. Он применяет UDP и блокировался имевшимися межсетевыми экранами, а следовательно единственный способ, которым AOVPN имел возможность подключаться, это было соединение по SSTP, однако это не было возможным пока не будет запущен Туннель пользователя, который становился доступным только после регистрации пользователя в данной машине. Это оказался чрезвычайно занимательный вариант применения в реальном мире, который помог пролить некий свет на процесс принятия решений, которые вам, возможно, придётся принимать для вашей собственной среды.

Если вы ещё пока окончательно не убедились что традиционные VPN старой школы являются новостями вчерашнего дня, давайте добавим вам ещё одно соображение. Когда вы применяете VPN, который требует от пользователя запуска подключения вручную, вы полагаетесь на то, что сам пользователь поддерживает данный компьютер в рабочем состоянии, исправляет его и обновляет. Конечно, у вас могут иметься автоматизированные системы, которые за вас выполняют эти функции, например, WSUS, SCCM и Групповая политика. Но когда конкретный ноутбук находится вне дома и пребывает в роуминге вдали от локальной сетевой среды, такие системы управления смогут выполнять свою работу только после того как пользователь решит установить некое подключение VPN. Может так произойти, что некий ноутбук способен провести несколько недель вне пределов корпоративной сети, выполняя подключение из десятков небезопасных точек доступа, пока этот сотрудник путешествует по Карибскому морю на круизном судне. После нескольких недель вечеринок и Netflix, он затем снова подключается к своей локальной сети или через VPN чтобы выполнить какую- то работу, а разве вы не знаете, что так как эта машина была отключена столь долго, она приобрела все возможные разновидности забавного и творческого программного обеспечения, с которым вам придётся иметь дело.

Это не так в случае инструментов удалённого доступа Microsoft! Предоставление варианта автоматического подключения, такого как Always On VPN или DirectAccess означает, что такой ноутбук всё ещё был бы подключённым и получал бы все свои политики безопасности и исправления на протяжении всего такого отпуска.

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

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

К сожалению, эти возможности не перенесены (пока, по крайней мере) в мир Microsoft VPN. Независимо от того, подключаете ли вы клиентов Windows 7 через традиционные соединения VPN или намерены применять клиентов Windows 10 для соединений с помощью Always On VPN, базовая инфраструктура VPN RRAS одна и та же и не имеет встроенного размещения для множества серверов или площадок. Безусловно, это можно сделать, выполнив систему VPN избыточной, но для этого потребуется самостоятельно настраивать её с помощью внешних балансировшиков нагрузок, а зачастую это требует применение глобальных балансировщиков нагрузки площадки/ сервера чтобы обмен проходил надлежащим образом.

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

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

Я искренне надеюсь что мы в будущем увидим добавленным вариант распространения Групповой политики для раскрутки настроек Always On VPN. Если бы такая возможность была бы введена, я абсолютно уверен что она немедленно превратится в самый популярный способ развёртывания настроек AOVPN.

Чтобы суммировать всю тему целиком, при сопоставлении DirectAccess с традиционным, ручным запуском VPN, несомненно DA берёт первый приз. Это никак нельзя сравнивать. Теперь, когда у нас имеется в распоряжении Always On VPN, преимущество одного над другим (DA или AOVPN) становятся достаточно призрачными. Оба выполняют одно и то же, но по- разному. На данный момент основными решающими факторами для большинства клиентов являются возможности развёртывания на стороне клиента вне зависимости от того, имеют ли они доступ к решению MDM и насколько для них важно подключение к Туннелю устройств. Цель Microsoft состоит в том, чтобы у AOVPN имелся паритет функций с DirectAccess, и это не за горами. Always On VPN также имеет некоторые расширенные функции проверки подлинности, которые отсутствуют в DirectAccess, например, интеграция с Windows Hello for Business или Azure MFA.

И DirectAccess, и VPN, обе являются замечательными технологиями удалённого доступа, а комбинируя обе вместе вы можете предоставить законченное решение удалённого доступа для вашей организации, причём без какой- бы то ни было необходимости платить за работу с решениями сторонних производителей. Что ещё лучше, в Windows Server 2019 присутствует ещё другой компонент роли Remote Access, доступный для применения. Эта третья часть истории удалённого доступа является WAP (Web Application Proxy ). По существу, это механизм обратного посредника (прокси), предоставляющий вам возможность иметь некие приложения HTTP и HTTPS, которые размещаются внутри вашей корпоративной сетевой среды и безопасно публиковать их во всемирный Интернет. Всякий из вас, кто работал с технологиями Microsoft в пограничном сетевом пространстве на протяжении последних лет вероятно узнает продукт с названием Унифицированный шлюз доступа Переднего края (Forefront Unified Access Gateway, UAG), который выполняет аналогичные функции. UAG является комплексным решением SSLVPN, также разработанным для публикации внутренних приложений вовне, в Интернет через SSL. Он рассматривается как обладающий большими возможностями в сравнении с Обратным посредником (прокси, reverse proxy), включая в себя такие компоненты, как предварительная аутентификация, SSTP VPN и также шлюз RDS, а DirectAccess сам по себе может даже работать через UAG.

Если ваши мобильные сотрудники осуществили доступ запустив либо DirectAccess, либо VPN, после этого они, скорее всего не будут иметь никакого использования навроде WAP. Однако, по мере роста образа мыслей облачных технологий, для пользователей становится совершенно обычным ожидать, что они могут открыть веб- браузер с любого компьютера, причём откуда угодно, и получить доступ к некоторым из их приложений. Доступ к документам теперь зачастую предоставляется веб- службами подобными SharePoint. Доступ к электронной почте может осуществляться удалённо, с любого компьютера, осуществив подключение к Outlook Web Access.

Очень много приложений и очень много данных могут быть доступными всего лишь через веб- браузер, а это делает возможным сотрудникам осуществлять доступ к таким данным без необходимости установления полностью раздутого корпоративного туннеля навроде VPN. Итак, что является применением реальности для WAP? Домашние компьютеры, которым не требуется полноценное VPN соединение. При таком подходе у вас нет необходимости сильно беспокоиться о работоспособности и состоянии находящихся во владении пользователя компьютерах, так как единственное взаимодействие , которое они имеют с вашей компанией осуществляется через веб- браузер. Это ограничивает потенциал для злонамеренной активности перетекающей в вашу сетевую среду из их компьютеров. Как вы можете видеть, подобные WAP технологии несомненно имеют своё место на рынке удалённых приложений.

Я надеюсь, что со временем WAP станет истинной заменой для Унифицированного шлюза доступа. UAG работает на серверах Windows, начиная с Server 2008 R2, и в настоящее время официально исключены из перечня официально поддерживаемых продуктов Microsoft. Официальной заменой для UAG от Microsoft является роль WAP. Она пока ещё не является всеобъемлющей, однако они работают над этим. В настоящее время WAP полезен для публикации доступа к простыми приложениям веб. Вы также можете публиковать доступ для обладающих большими запросами клиентов, которые применяют в основе HTTP, например, ActiveSync. К тому же включение его является возможностью для публикации данных клиентам, которые применяют MSOFBA, например, когда пользователи пытаются разобрать корпоративные данные из своих приложений Word или Excel, работающих на их локальных компьютерах.

WAP может применяться для удалённого доступа с обратным посредником (прокси, публикатором) к предметам подобным средам Exchange и SharePoint. И это имеет не малое значение, так как это технологии, которые применяют почти все. Таким образом, это может быть несомненно сулящим преимущества для вашей компании реализовать безопасный доступ к подобным ресурсам. Это может быть лучше, нежели прямой NAT доступ к вашему серверу Exchange.

Другой полезный вариант применения вами сервера WAP состоит в настройке в вашей сетевой среде AD FS (Active Directory Federation Services). AD FS является технологией, разработанной для включения отдельной подписи для пользователей и объединения с другими компаниями, а также поскольку она включает в себя обмен, поступающий из Интернета в вашу внутреннюю сетевую среду. Обычно присутствовал серверный компонент, имевший название Прокси AD FS, который вы устанавливали на границе своей сети для обработки подобного обмена, однако теперь у вас имеется выбор. Вы всё ещё можете продолжать использовать отдельный сервер Прокси AD FS, либо же вы можете вместо этого предоставлять возможности Прокси AD FS из своего сервера WAP. Это лучше унифицирует решения удалённого доступа, в результате чего ваш входящий обмен AD FS проходит сквозь официальный сервер удалённого доступа вместо необходимости отдельного сервера Прокси AD FS.

К сожалению, возможность применять Web Application Proxy поставляется с достаточно прижимистым требованием. Вы должны иметь установленным AD FS в своей среде чтобы иметь возможность его использовать. Даже чтобы проверить его, так как настройка WAP хранится внутри AD FS. Никакая информация настроек WAP не хранится в самом сервере удалённого доступа, что сделано для облегчения сервера, который можно легко перемещать, изменять или добавлять. Обратной стороной этого является то, вы должны иметь в своей среде работающий AD FS с тем, чтобы WAP мог иметь пространство для хранения такой конфигурационной информации.

Хотя тесная интеграция с AD FS действительно означает, что у нас имеются лучшие возможности аутентификации, и что пользователи могут получать преимущества такого однократного предъявления пароля для своих приложений, которые публикуются через WAP, что до сих пор считалось огромным препятствием на пути реализации для компаний меньшего размера. Многие пользователи ещё пока не работают с AD FS, и если единственная причина по которой они заинтересованы в реализации AD FS это то, что они смогут публиковать несколько веб- приложений в Интернет - они, скорее всего, не собираются тратить своё время и усилия только чтобы это произошло.

Один момент, который стоит иметь в виду если вы заинтересованы в использовании WAP и, тем самым ищите требования для AD FS, состоит в том, что AD FS несомненно можно применять для прочих функций. На самом деле, одно из наиболее частых применений его в настоящее время это интеграция с Offise 365. Если вы планируете или размышляете над включением office 365 в свою среду, AD FS является великолепным инструментом, который может расширить возможности аутентификации для подобного обмена.

Web Application Proxy был представлен в Server 2012 R2 и имел множество улучшений в выпуске Windows Server 2016. С тех пор не было никаких серьёзных изменений, но всё же важно указать на последние преимущества этой функции чтобы показать что она всё ещё продолжает учится делать нечто новое. Далее приводятся некоторые улучшения, которые были сделаны, если вы не рассматривали WAP с момента его первой итерации.

Существует два различных способа, которыми пользователи могут выполнять аутентификацию для публикуемых Web Application Proxy приложений: Предварительная аутентификация (Preauthentication) и пробрасываемая (pass-thru) аутентификация. При публикации некоторого приложения с Предварительной аутентификацией это означает, что пользователи должны быть остановлены интерфейсом AD FS для их аутентификации перед тем, как им будет дозволено применять само это приложение. В моих глазах Предварительная аутентификация является критически важным компонентом для любого Обратного прокси и я должен бы был находиться между молотом и наковальней при внешней публикацией некоторого приложения, которое не требует предварительной аутентификации. Однако, существует второй вариант аутентификации, а точнее Пробрасываемая (pass-thru) аутентификация, именно она на самом деле осуществляет это. Когда вы публикуете доступ к приложению и выбираете Пробрасываемую аутентификацию, всё что делает WAP, это круговорот пакетов из всемирного Интернета к серверу приложений. Такие пользователи способны получить данные веб приложения без аутентификации, поэтому теоретически любой может зайти в интерфейс вебсайта вашего приложения. Начиная с этого момента, само приложение, скорее всего, потребует подобного пользователя выполнить аутентификацию, однако если не существует никакой защиты от злоумышленника посредине, такое веб- приложение доступно для публичного просмотра. Как вы можете сказать, я не рекомендую выбирать этот путь.

Мы уже знаем, что WAP имеет возможность выполнять аутентификацию веб приложений, однако в предыдущих версиях он не мог выполнять ни в каком виде предварительную аутентификацию приложений на основе HTTP. Такая неспособность оставляет ActiveSync слегка черезчур открытой для внешнего мира и является угрозой для безопасности. К счастью, это изменено в Windows Server 2016, так как теперь вы можете предварительно аутентифицировать потоки обмена, которые применяют базовый HTTP.

Пользователи не любят сворачивать с проторённых дорог или тратить время на запоминание того, что им требуется вводить HTTPS:// в начале своего URL при их доступе к приложению. Им будет гораздо проще запомнить email.contoso.com. Невозможность WAP выполнять перенаправлнение HTTP в HTTPS была до сих пор раздражающей и строящей помехи для принятия, однако это, наконец, изменено. WAP внутри Windows Server 2016 привнёс возможность WAP самостоятельно обрабатывать перенаправление HTTP в HTTPS, что означает, что пользователям теперь не нужно набирать "HTTPS" в своей адресной строке браузера, они просто могут вводить само имя DNS необходимого сайта и позволить WAP обработать трансляцию.

В мире Обратных прокси и SSLVPN мы порой порой выполняем приложения, которым требуется знание локального адреса IP клиента. Хотя такое требование и не возникает очень часто, и обычно выделяется для того, что мы бы назвали унаследованными приложениями, это всёже встречается. Когда серверному приложению нужно знать каков адрес IP его клиента, это представляет сложную задачу для решений Обратного посредника (прокси). Когда обмен пользователя осуществляется сквозь WAP или любой другой Обратный прокси, это аналогично NAT, при котором информация об источнике IP в данных пакетах подменяется. Серверные приложения не способны определять собственный IP адрес их клиента, что в результате представляет проблему. Web Application Proxy теперь имеет возможность пропускать адрес IP стороны клиента в сторону конечного сервера приложений, смягчая данную проблему.

Один из элементов, который UAG обычно применял, это публикующий доступ к Службам RD (RDS, Remote Desktop Services). UAG по существу был сам по себе Шлюзом RD (RDG, Remote Desktop Gateway), который давал вам возможность публиковать доступ к серверам RDSH, индивидуальные соединения RDP к компьютерам рабочих мест, например, в реализациях VDI, и даже осуществлять доступ к приложениям RemoteApp. К сожалению, WAP не может делать ничего из этого, даже в самой новой версии, однако тот факт, что они добавили немного функциональности здесь означает движение в верном направлении.

То что было улучшено в отношении WAP и Remote Desktop, так это то, что вы теперь можете публиковать доступ к самому серверу Шлюза RD (Remote Desktop Gateway). Обычно Шлюз RD расположен на границе вашей сетевой среды и соединяет внешних пользователей с внутренними серверами Удалённых рабочих мест (RD). Размещение WAP перед Шлюзом RD делает возможной строгое выполнение Предварительной аутентификации для служб RD и создаёт большее разделение между внутренней и внешней сетевыми средами.

Все мои пальцы скрещены в предверии того, что мы продолжим наблюдать улучшения в этой области и что WAP может быть расширен на обработку обмена подобного натуральному RD, даже без необходимости в смеси с RD Gateway.

Первоначальную версию WAP внутри Windows Server 2012 R2 было лучше обслуживать для её реализации при помощи PowerShell. Несомненно, вы всё ещё можете применять PowerShell чтобы создавать свои правила публикации, если уж вы так выбрали, однако Консоль управления Удалённым доступом (Remote Access Management Console) теперь была улучшена в том, что относится к Web Application Proxy. Прежде чем вы сядете за эту консоль, вам необходимо удостовериться, что был отмечен соответствующий блок в процессе установки роли Удалённого доступа (Remote Access). Если вы не выбрали Web Application Proxy когда вы выполняли впервые установку этой роли, посетите ещё раз Диспетчер сервера для добавления функции Ролей add/ remove чтобы добавить WAP к этому серверу:

Так как мы теперь имеем унифицированную платформу управления для настройки всех сторон нашей среды удалённого доступа, просто посетите тот же самый инструментарий Управления удалённым доступом (Remote Access Management), который вы применяли для настройки DirectAccess и VPN, и вы обнаружите что Web Application Proxy теперь доступен в разделе Web Application Proxy Configuration Wizard около самой верхней части слева на вашем экране:

Современные технологии требуют того, чтобы большинство компаний позволяло своим сотрудникам работать из любой точки мира. Всё больше и больше организаций нанимают рабочую силу для работы на дому, и им требуется безопасный, стабильный и действенный способ предоставления корпоратвных данных и приложений для таких мобильных работников. Роль Удалённого доступа (RA, Remote Access) в Windows Server 2019 разработана в точности под это. Обладая тремя различными способами предоставления удалённого доступа к корпоративным ресурсам, департаменты ИТ никогда не обладали на кончиках пальцев таким доступным громадным объёмом технологий удалённого доступа, причём выстраиваемых прямо в операционной системе Windows, которой они и так уже обладают. Если вы всё ещё поддерживаете наследуемые системы VPN стронних разработчиков, вам несомненно стоит исследовать те новые возможности, которые предоставляются здесь и изучить насколько они способны уберечь ваш бизнес.

DirectAccess и Always On VPN выступают особенно впечатляющими и привлекательными вариантами подключения - новым взглядом на удалённый доступ. Автоматическое подключение содержит всегда включённые машины, которые непрерывно вносят поправки и обновления по той причине, что они всегда подключены к вашим серверам управления. Вы можете улучшать производительность пользователей и сетевую безопасность одновременно. Эти два момента обычно выступают сочетанием несовместимого в современном ИТ мире, но при наличии стека удалённого доступа Microsoft они держатся за руки и вместе поют песни.

Далее мы намерены рассмотреть некоторые встроенные в ваши операционные системы Windows Server 2019 функции безопасности, а также некие пути, которыми ваши серверы способны быть упрочнёнными для предоставления ещё лучшец безопасности, которая получается сразу после установки.