Глава 5. Информационные службы интернета

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

Для большинства задач в этой главе мы предполагаем, что роль для IIS уже установлена в вашем веб сервере. Эта роль конкретно называется Web Server (IIS) и существует множество дополнительных свойств, которые мы можем добавлять к IIS. Для всех наших рецептов нам нужны только добавления по умолчанию, которые выбираются автоматически при установке этой роли. Установка этой роли является единственной нужной вещью из коробки Windows Server 2016 чтобы обслуживать вебстраницы для пользователей, помимо небольших познаний в том как заставить сайт делать то, что вы от него ожидаете. Чтобы получить данную роль установленной надлежащим образом, не забудьте остановиться на рецепте Установка роли Веб сервера через PowerShell чтобы разместить этот компонент на его месте. Давайте ознакомимся с некоторыми общими задачами в IIS.

Если вы ещё пока не начали применять PowerShell для выполнения ряда своих постоянных задач Windows Server, сделайте это сейчас! PowerShell может применяться в Windows Server 2016 для выполнения любых задач настройки внутри этой операционной системы. Я громадный фанат применения своей клавиатуры вместо своей мышки при любых обстоятельствах, а также сохранения сценариев, которые можно применять снова и снова для сбережения времени в будущем.

В данном рецепте мы собираемся изучить cmdlet Install-WindowsFeature, который может применяться для добавления роли или ролей в ваш Server 2016. Поскольку в данной главе мы обсуждаем IIS, давайте возьмём наш только что созданный веб сервер и воспользуемся PowerShell для помещения на нём вашей роли Web Server (IIS).

У вас имеется новый веб сервер Windows Server 2016 в нашей среде с именем WEB2. Давайте воспользуемся на этой машине PowerShell чтобы установить роль IIS.

Чтобы добавить роль Web Server (IIS) на WEB2 через PowerShell, выполните следующие шаги:

Мы можем применять в PowerShell cmdlet Install-WindowsFeature для быстрого добавления ролей и свойств в свой сервер. Только это само по себе может сохранить нам много времени в сравнении с обходом этих параметров в графическом мастере. Например, если у нас имеется группа новых серверов, в каждом из которых необходимо выполнить одну и ту же задачу и по этой причине необходимо выполнять установку одного и того же набора ролей, вы можете выстроить одну отдельную команду для установки таких ролей и исполнить ей на каждом сервере. Совсем нет необходимости запускать Диспетчер сервера.

Вот некоторые ссылки по дополнительной документации TechNet по добавлению ролей в серверы и, в частности, для cmdlet Install-WindowsFeature. Не забудьте ознакомиться со всеми доступными опциями. Если вы начнёте применять эту команду, я сомневаюсь, что вы вернётесь к Диспетчеру сервера!

Это выглядит как достаточно логичный первый шаг; давайте запустим какой- нибудь вебсайт! На самом деле, у вас уже имеется один, однако он достаточно бесполезен в данный момент. Раз мы завершили установку своей роли IIS, стандартный вебсайт был запущен автоматически, следовательно вы могли убедиться, что всё работает как необходимо. Теперь мы хотим заменить такой вебсайт по умолчанию на один из своих собственных с тем, чтобы мы могли реально применять такой новый сервер.

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

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

Запуск нового вебсайта, вероятно, самая простая задача, которая может быть выполнена в IIS, однако она рисует портрет всего ядра функциональности данной роли. Цель работы IIS в первую очередь состоит в публикации вебсайтов. Важно понимать местоположение данной задачи и места, к которым вы можете получать доступ внутри вашей файловой системы {Прим. пер.: а также имеющихся у вас баз данных, хранилищ объектов и блочных устройств!} для изменения или создания ваших собственных веб сайтов. Не всё можно сделать в рамках вашего окна управления IIS.

Обычно, всякий раз когда вы осуществляете доступ к некоторому вебсайту, он работает по порту 80 или 443. Любой нормальный HTTP запрос проходит через порт 80, а зашифрованный HTTPS применяет порт 443. Внутри IIS очень просто изменить порт, который отслеживает вебсайт, если вам нужно это сделать. Вероятно, наиболее распространённая причина ввести изменение на некотором вебсайте состоит в сохранении его скрытым. Может быть, у вас имеется административный сайт и некоторого вида и желание обладать уверенностью, что никто не будет спотыкаться об него, или может быть, что ваш веб сервер ограничен в IP адресах и вам необходимо включить другую вебстраницу, однако все ваши IP уже исполняют сайты. Для такого нового сайта вы можете воспользоваться другим портом, а затем, возможно, исполнять два (или более) сайтов использующими один и тот же IP адрес, по одному сайту на каждый порт.

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

У нас имеется работающий сервер Windows Server 2016, который имеет установленную роль IIS. Также уже существует вебсайт выполняющийся на этом сервере. В настоящее время используется по умолчанию порт 80, однако мы хотим изменить этот порт на 81 и проверить доступ к нему с компьютера клиента.

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

Мы можем легко отрегулировать какой именно порт применяется для доступа к вебсайту внутри IIS сделав одно простое уточнение. После изменения номера порта в нашем связывании вебсайта, этот сайт немедленно переключится на прослушивание нового установленного порта и больше не проявляет активности по своему старому порту. Вместо изменения порта вы можете также добавить дополнительное связывание в том же самом окне чтобы заставить ваш вебсайт отвечать от множества портов в одно и то же время. Например, если вы хотите, чтобы ваш вебсайт работал одновременно и с HTTP для обычного доступа и с HTTPS для шифрованного доступа к страницам с чувствительной информацией, вы можете создать связывание для обоих портов, и для порта 80, и для порта 443.

Необходимо сделать одно важное замечание при изменении порта вашего вебсайта; выполнение этого означает, что ваши веб- ссылки для доступа к этому сайту будут теперь включать в себя этот особый номер порта в конце. Кроме того, если у вас в сетевой среде или на самом веб сервере работают межсетевые экраны (брандмауэры, firewalls), скорее всего вам будет необходимо отрегулировать настройки {Прим. пер.: добавить правила} в этих межсетевых экранах чтобы разрешить безопасное прохождение пакетов для этого нового порта.

Применение вебсайтов для передачи данных во всемирном Интернете является основной технологией, как мы это знаем сегодня. Установка даже самого простейшего нового инструмента или системы вероятно потребует от вас загрузки программного обеспечения или обновления, или регистрации вашей информации в вебсайте. Поскольку вы являетесь специалистом в ИТ, я надеюсь что вы знакомы с сопоставлением HTTP и HTTPS вебсайтов и важности различия между ними. Однако теперь, когда у нас имеется работающий вебсайт, как мы можем включить HTTPS в нём с тем, чтобы он мог защитить эти данные, которые перемещаются взад и вперёд между нашим веб сервером и соответствующими компьютерами клиентов?

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

У нас работает веб сервер Server 2016 на котором мы будем выполнять данную задачу. Существует также простой вебсайт, в настоящее время работающий внутри IIS на этом сервере. Часть нашего рецепта состоит в выборе сертификата SSL, который вы хотите видеть работающим на нашем вебсайте, поэтому данный рецепт предполагает, что такой сертификат уже установлен на вашем сервере. Если вам нужна помощь с получением самого такого сертификата, ознакомьтесь, пожалуйста, с рецептом Применение Запроса подписанного сертификата для получения вашего сертификата SSL.

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

В этом рецепте мы применяем консоль управления IIS для добавления второго связывания с нашим новым вебсвйтом. Это новое связывание предназначено для приёма обмена HTTPS. Мы пытаемся выполнять части этого вебсайта в виде HTTP, а некоторые наиболее чувствительные страницы как HTTPS. По этой причине мы создаём второе связывание, разрешая оба обмена, и HTTP, и HTTPS успешно проходить с этого сайта. На протяжении курса данного рецепта нам нужно выбрать соответствующий сертификат SSL, который этот вебсайт собирается применять для удостоверения своего происходящего обмена HTTPS. На нашем сервере уже был установлен некий SSL сертификат для нашего вебсайта; мы просто выбрали его из имеющегося списка.

При публикации некоторого вебсайта во всемирном Интернете, обычно на практике применяется сертификат SSL на том вебсайте, который вы получаете из общедоступного Центра Сертификации (CA, Certification Authority). Существуют большие субъекты выпуска сертификатов, такие как Entrust, Verisign, GoDaddy и тому подобные. Также допускается применение вашей собственной внутренней инфраструктуры PKI для выпуска сертификатов SSL, которые будут выставляться во внешний мир, однако могут возникнуть трудности с настройкой такой инфраструктуры сертификации должным и безопасным образом. На сколько бы дёшевы не были сертификаты SSL, это будет стоящим вложением - наличие безопасности в знании того, что применяемый на вашем вебсайте сертификат является единственным и исключительным сертификатом такого рода, и что никто кроме вас не имеет возможности получить в свои руки копию вашего сертификата и подменить ваш вебсайт. Современные браузеры также имеют предварительно построенный список общедоступных CA, которым они доверяют; они могут применять сертификаты из одного из этих общедоступных субъектов с ещё большей выгодой, так как ваши браузеры будут автоматически доверять этим сертификатам без какой- либо дополнительной работы с клиентской стороны.

Достаточно просто зарегистрироваться на одном из этих вебсайтов CA и приобрести некий новый сертификат, однако после этого начинается хитрая часть. Совершив покупку, вам необходимо пройти некоторые шаги и ввести информацию о своём сертификате. Достаточно просто; запрашивается некая информация о компании и конкретное название, которое планирует применяться для вашего сайта, естественно. Затем у вас просят CSR (Certificate Signing Request, Запрос на подпись сертификата - {Прим. пер.: не подписанный сертификат, передаваемый в центр сертификации, где он удостоверяется секретным ключом, после чего становится действующим сертификатом}) и вам выдаётся либо очень большой пустой блок для вставки в него, либо функция выгрузки, при помощи которой вы можете выгрузить свой CSR непосредственно им. Это именно то место, в котором я наблюдаю у многих молождых администраторов стремление перейти к их следующему шагу.

CSR является файлом, который должен быть создан на вашем веб сервере. Он содержит информацию, которую CA использует при создании вашего серификата. Когда они делают это, это связывает сам сертификат с информацией в вашем CSR, гарантируя что ваш сертификат построен специально для вашего веб сервера. Здесь мы, однако, собираемся генерировать CSR вместе, для того, чтобы вы были готовы обрабатывать этот экран, когда вы будете его проходить.

Мы собираемся применять IIS, который работает на нашем веб сервере Server 2016 для генерации CSR. Этот сервер является единственной частью инфраструктуры, которая нам нужна для выполнения данной задачи.

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

В данном рецепте мы запросили новый сертификат SSL из общедоступного Центра Сертификации (CA), которому мы отдаём предпочтение. Чтобы получить из него сертификат, мы должны выполнить с нашего сервера CSR. Когда мы создали свой CSR, мы просто копируем и вставляем его в веб интерфейс своего элемента CA, а он даёт нам на основании такого CSR новый сертификат. После загрузки этот новый сертификат можно импортировать назад в наш веб сервер, в котором он уже будет применён в целях нашего веб сайта.

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

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

У нас имеются в нашей среде две коробки с включёнными Windows Server 2016. Обе они предназначены для веб серверов, размещающих один и тот же вебсайт. На обеих установлен IIS. Необходимый нам сертификат был установлен на первичном сервере. Теперь нам нужно экспортировать этот сертификат оттуда и успешно экспортировать его на наш второй сервер.

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

Мы воспользовались консолью Диспетчера IIS для экспорта и импорта некоторого сертификата, что является достаточно ясной и простой задачей, если вы её выполнили хотя бы раз и поняли весь процесс. Критическим моментом является гарантирование того, что ваш экспорт содержит информацию необходимого частного ключа. Если это не так, подобные сертификат не будет в состоянии удостоверять надлежащим образом процесс обмена. Применение IIS для выполнения данной задачи является наилучшим вариантом для перемещения сертификатов. Вы также можете воспользоваться оснасткой MMC для сертификатов, однако это слегка сложнее. Если вы попытаетесь воспользоваться этой консолью, система спросит у вас желаете вы или нет экспортировать данный частный ключ. Опция по умолчанию установлена в значение No, do not export the private key (Нет, не экспортировать данный частный ключ). Распространённая ошибка состоит в оставлении данной настройки в её положении и удивлении в последующем: почему ваш сертификат не работает должным образом на прочих серверах, на которых вы его установили. Вы должны проверить что выбрали параметр Yes, export the private key (Да, выполнить экспорт частного ключа).

Срок действия сертификатов истёк; это всего лишь факт из жизни. Очень часто я обнаруживаю компании, приобретшие сертификаты SSL на основе очень короткого срока действия, обычно всего лишь на год. Это означает, что необходимо обновлять все сертификаты каждый год. Однако, загрузки новой копии сертификата и установки его на ваш веб сервер недостаточно чтобы он продолжал работу. Простое помещение такого нового сертификата на его место на вашем сервере не означает, что IIS собирается начать применять этот новый сертификат для подтверждения обмена на вашем вебсайте. Даже если вы удалите старый сертификат, отсутствует действие, которое было осуществлено внутри IIS чтобы сообщить, что этот новый сертификат, который внезапно появился является именно тем, который необходимо начать применять для вашего вебсайта. Поэто му нам всегда необходимо выполнять эти дополнительные изменения вручную. Всякий раз, когда вы заменяете некий сертификат, вы также проходите в IIS и изменяете связывание на этом вебсайте. Это выглядит особой головной болью, когда вы имеете автоматическое обновление сертификата через нечто подобное Autoenrollment (Автоматической компоновке). Вы ошибочно можете полагать, что вы рассмотрели эту функциональность один раз и больше не должны ничего предпринимать для обновления своих сертификатов, поскольку они будут обновяться автоматически на уровне сервера. Однако, увы, это не так; до сих пор нам приходилось переходить в IIS и изменять связывание вручную. Не бойтесь, будущее уже пришло...

Команда IIS внесла простое, но очень мощное изменение чтобы помочь с данной проблемой в новой версии IIS, которая поставляется с Windows Server 2016. На самом деле эта функция уже присутствовала в Windows Server 2012 R2 при первой итерации, однако я всё же не видел, чтобы кто- то пользовался ею, поэтому для основного народа это будет новым словом. Эта новая функция называется Certificate Rebind (Повторное связывание сертификата) и, когда установлена, вызывает автоматическое распознавание со стороны IIS установки нового сертификата и автоматическое повторное связывание соответствующего вебсайта на использование данной новой копии вместо оригинала с истекшим сроком действия. Давайте рассмотрим общий интерфейс с тем, чтобы вы знали как включать и выключать эту опцию. Ма даже слегка заглянем к ней под капот, чтобы вы понимали как эта функциональность работает.

Данная работа будет выполнена на нашем веб сервере Windows Server 2016. У нас имеется установленная IIS и мы имеем запущенный вебсайт HTTPS с уже привязанным к этому сайту сертификатом.

Для включения Certificate Rebind на вашем веб сервере IIS следуйте приведёнными ниже шагами:

Повторное связывание сертификата на самом деле простое действие по включению внутри IIS, однако оно может сделать разницу в том будет ли у вас в офисе хороший или плохой день. Будучи включённым, это свойство строит в расписании внутри Windows некую задачу, которая переключает команды для привязки нашего вебсайта IIS к его новому сертификату. Эта задача взводится событием,которое регистрируется в Windows при установке нового сертификата или обновлении существующего. При включённом Certificate Rebind и настройке вашего распространения набора сертификатов на автоматический режим при помощи Autoenrollment, вы теперь можете на самом деле автоматизировать обновление сертификатов в вашей сетевой среде!

Раскрутка веб сервера, реализация необходимой роли IIS и размещение некоторого вебсайта являются прекрасными первыми шагами. В зависимости от требующегося размера и важности вашего вебсайта вам могут понадобиться множество работающих веб серверов, которые будут обслуживать точные копии одного и того же сайта и иметь балансировку нагрузки, настроенную между множеством веб серверов. С другой стороны более вероятно, что ваш вебсайт в действительности будет недостаточно загружать ресурсы ваших серверов, нежели испытывать перегрузку, и, таким образом, вы сейчас создали свой новый веб сервер, размещающий одиночный вебсайт, который в действительности совсем не создаёт бремени. Существует ли способ, которым мы можем использовать такое дополнительное оборудование, которое в настоящее время простаивает? Возможно, у вас имеются дополнительные вебсайты или веб службы, которые нужно включить и для которых вы вы планировали раскрутить множество серверов. Хорошая новость состоит в том, что IIS имеет возможность размещения множества различных веб служб одновременно. Мы можем взять такой недозагруженный сервер и создать дополнительные прослушивания вебсайтов на нём, чтобы он мог обслуживать множество веб страниц с одного и того же физического сервера.

Существует пара различных способов, которыми мы можем размещать множество вебсайтов на одном и том же сервере IIS в одно и то же время, а именно, через использование множества портов или множества IP адресов, давайте уделим минутку чтобы попробовать оба способа.

Мы собираемся сейчас использовать IIS на нашем сервере WEB1 чтобы разместить множество вебсайтов. Нам также понадобится доступ к DNSчтобы создавать имена для этих вебсайтов.

Воспользуйтесь следующими шагами для создания множества вебсайтов на одном и том же сервере IIS:

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

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

Именно здесь в игру вступают заголовки хоста. Заголовки хоста могут быть настроены на ваших вебсайтах таким образом, чтобы такой сайт отвечал на определённый приходящий от клиента запрос. Такие запросы заголовка могут помочь веб серверу делать различие в обмене, направляя запросы пользователей на вебсайты для соответствующих им сайтов внутри IIS. Давайте поработаем вместе над настройкой двух вебсайтов внутри IIS и заставим их использовать один и тот же IP адрес и порт. Мы хотим, чтобы всё оставалось стандартным как раз уж оно поступает на этот порт, поэтому мы хотим чтобы они оба использовали порт 80, однако у нас имеется только один IP адрес доступный для настройки на нашем веб сервере.

Работа будет выполняться изнутри IIS на нашем веб сервере Server 2016. Мы также воспользуемся клиентским компьютером для проверки связи с этими вебсайтами когда мы закончим их настройку.

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

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