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

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

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

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

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

Большое число администраторов даже ещё не знают что такое 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) версию или даже SKU в стиле Premium Home для своих клиентских машин, а эти версии не содержат компоненты DirectAccess. Вот перечень операционных систем, которые точно поддерживают DirectAccess. В процессе своего планирования вам необходимо убедиться, что ваши мобильные компьютеры работают под их управлением:

Один большой вопрос, на который следует ответить даже до начала установки роли Удалённого доступа на вашем новом сервере - сколько 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. Может быть это нечто, что будет изменено в последующих версиях!

Теперь, когда вы определились с раскруткой двух 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 только когда удалённый ноутбук имеет реальный общедоступный адрес 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 использует 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 для своей аутентификации при построении туннелей 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 2016 полезна не только для установки частей и фрагментов вашего удалённого доступа, но также и для целей мониторинга и составления отчётов. Давайте заглянем вовнутрь этой консоли с тем, чтобы вы ознакомились с различными экранами с которыми вы будете взаимодействовать:

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

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

Инструментальная панель Удалённого доступа (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 был распространённым на протяжении очень длительного времени, что сделало его достаточно знакомой идеей для всех работающих в ИТ, и мы делали небольшое обсуждение DirectAccess уже в этой книге чтобы быстро посвятить вас в эту эволюцию так называемого корпоративного удалённого доступа. Теперь, когда вы знакомы с этими двумя великолепными решениями встроенными в Windows Server 2016 для возможности работы с мобильного рабочего места, какое из них лучше?

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

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

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

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

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

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

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

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

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

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

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

И DirectAccess, и VPN, обе являются замечательными технологиями удалённого доступа, а комбинируя обе вместе вы можете предоставить законченное решение удалённого доступа для вашей организации, причём без какой- бы то ни было необходимости платить за работу с решениями сторонних производителей. Что ещё лучше, в Windows Server 2016 присутствует ещё другой компонент роли 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 находящимся на этапе обучения хождению. В настоящее время он немного ходит, однако всё ещё в процессе обучения как выполнять новые вещи. Давайте обсудим некоторые улучшения, которые были осуществлены для WAP внутри Windows Server 2016.

Существует два различных способа, которыми пользователи могут выполнять аутентификацию для публикуемых 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 теперь доступен в разделе Configuration около самой верхней части слева на вашем экране: