Iis об определении адресов по именам


Содержание

Iis об определении адресов по именам

Назначение: Windows Server 2008, Windows Server 2008 R2

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

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

Предварительные требования

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

Исключения из требований

Чтобы настроить ограничение IPv4-адресов для службы управления

Откройте Диспетчер IIS. Сведения об открытии Диспетчер IIS см. в разделе Открытие диспетчера IIS (IIS 7).

На панели Подключения щелкните узел сервера в дереве.

В представлении Просмотр возможностей дважды щелкните пункт Служба управления.

На панели Действия страницы Служба управления нажмите кнопку Остановить, чтобы остановить службу управления.

Установите флажок Разрешить удаленные подключения.

В разделе Ограничения для IPv4-адреса выполните одну из следующих процедур:

    Нажмите кнопку Разрешить, чтобы разрешить подключение к службе управления с одного IPv4-адреса или из диапазона IPv4-адресов.

Нажмите кнопку Запретить, чтобы запретить подключение к службе управления с одного IPv4-адреса или из диапазона IPv4-адресов.

В диалоговом окне Добавить правило, разрешающее подключения или в диалоговом окне Добавить правило, запрещающее подключения выполните одну из приведенных ниже процедур и нажмите кнопку ОК:

    Чтобы разрешить или запретить определенный IP-адрес, щелкните пункт Конкретный IPv4-адрес и введите в поле IPv4-адрес.

Чтобы разрешить или запретить диапазон IP-адресов, щелкните пункт Диапазон IPv4-адресов, введите в поле IPv4-адрес и маску подсети в поле Макса подсети.

На панели Действия нажмите кнопку Применить, а затем нажмите кнопку Пуск.

Iis об определении адресов по именам

DNS прописан типа тест.рф по другому не берет (типа xn--e1aybc.xn--p1ai ) и работает нормально.

В IIS xn--e1aybc.xn--p1ai прописать так можно, но запустить нельзя ругается, можно только Вида: тест.рф.

Windows Server 2008 R2 Standart.

http://piccy.info/view3/1085446/eedc33d5cdf8e3433047de05afb73b2c/ — Скриншот ошибки.

Alex1_D, это вообще-то странно, что dns у Вас заработал с кириллическим доменом — у меня получилось только как раз наборот с пуникодом. Как проверяли, что разрешение корректно работает?

А вот на IIS7.5 прописывал именно кириллическую привязку типа Вашего тест.рф — заработало. Проверьте, на всякий случай, applicationHost.config у Вас в UTF-8 хранится, и попробуйте привязку прописать в самом xml, а не из консоли.

Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется «как есть» без каких-либо гарантий.

Лекция 8

Определение имен узлов DNS

Каждый узел в Интернет имеет свой собственный, уникальный адрес. Эти уникальные адреса дают возможность связываться с любым другим адресом и посылать ему сообщение. Однако человеку обычно трудно запомнить эти 32-х битные адреса, ему проще ориентироваться по именам. Именно для этого в Интернет используется гибкая и масштабируемая система доменных имен DNS ( Domain Name Service ), когда каждому узлу присваивается уникальное символическое имя FQDN ( Fully Qualified Domain Name ), ассоциированное с его IP -адресом . Кроме того, имена узлов удобны еще и потому, что не зависят от физического расположения, в то время, как IP -адрес компьютера соответствует его физическому расположению в сети. Если компьютер перемещается из одной сети в другую, то его IP -адрес должен быть изменен, в то время как доменное имя остается прежним. Например, просматривая информацию об Экономико-аналитическом институте МИФИ на сервере eai . mephi . ru , Вы не знаете его конкретный IP -адрес, и миграция сервера не влияет на предоставление доступа к информации.

Существуют стандарты, публикуемые как RFC ( Request for Comments ), на правила именования FQDN . Стандарт RFC 1123 определяет, что


  • имена доменов имеют иерархическую структуру, уровни иерархии отделяются друг от друга точкой, имя формируется справа налево;
  • суммарное имя домена (узла) не содержит более 255 символов ( a – z , A — Z , 0 –9, дефис, точка);
  • имя на каждом уровне иерархии не может состоять только из цифр, но может начинаться с цифры;
  • имена не различают регистр букв (прописные или строчные);
  • метка на каждом уровне иерархии не может больше 63 символов;
  • метка нулевой длины зарезервирована для корневого домена.

Уникальность имен FQDN в первую очередь обеспечивается иерархической структурой (рис. 8_1). На корневом уровне иерархии присутствует нулевая метка. На следующем, верхнем уровне, могут присутствовать один из трех типов доменов: домен организации, географический домен либо домен обратного просмотра.

К доменам организаций относятся трехсимвольные имена, используемые обычно только для организаций в пределах США:

  • COM -коммерческие предприятия;
  • EDU — образовательные учреждения;
  • GOV — правительственные службы США;
  • MIL — военное ведомство США;
  • NET — поставщики услуг в Интернет;
  • INT – международная организация;
  • ORG — неклассифицированные организации.

К географическим доменам относятся двухсимвольные имена, определяющие коды стран или регионов, например:

  • AU — Австралия;
  • BR — Бразилия;
  • CA — Канада;
  • DE — Германия;
  • FR — Франция;
  • RU — Россия;
  • UK – Великобритания и т. д.

Доменами обратного просмотра являются in — addr . arpa и IP 6. INT .

Рис . 8_ 1 . Иерархическая структура имен

Все пространство имен DNS делится на логические непересекающиеся разделы-множества (ветки на дереве пространства имен), которые называются зонами . Структура дерева пространства имен такова, что один из узлов в зоне всегда ближе к корню, чем остальные. Имя этого узла используется в качестве имени зоны, а сама зона распространяется вниз от этого узла до самого нижнего уровня, либо до начала следующей зоны. Использование зон упрощает процесс определения имен, когда имени FQDN ставится в соответствие конкретный IP -адрес . Для осуществления этого процесса серверам сети присваивают разные роли.

Один из серверов в каждой зоне берет на себя функции по хранению и распознаванию части базы данных DNS для этой зоны. Такой сервер называется главным доменным сервером имен ( domain master name server ). Все изменения и обновление информации по зоне вносятся именно на этом сервере. Сама база данных содержит следующую информацию:

  • имена всех зон;
  • адреса серверов имен всех зон;
  • адреса серверов имен корневых доменов;
  • адреса серверов доменов, связывающих текущий домен с иерархией DNS ;
  • IP -адреса всех узлов в текущем домене.

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

Кэширующие серверы имен используются для увеличения эффективности процесса определения имен. Такой сервер не содержит постоянного списка узлов в зоне, а кэширует результат выполнения запросов, полученный при обращении к другим серверам имен. Параметр, отвечающий за время сохранения имени в кэше, называется TTL ( Time To Live ), когда время истекает, запись удаляется.

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

При определении имени могут использоваться три типа запросов: рекурсивный, итеративный и обратный. Рекурсивный запрос необходим при определении полного IP -адреса и наиболее часто используется клиентами. Итеративный запрос используется для частичного определения имени и используется серверами имен. Обратный запрос позволяет IP -адресу поставит в соответствие имя запрашиваемого ресурса.

Определение имени с помощью сервера DNS

Рассмотрим процесс обработки типичного запроса на определения имени. Клиент запрашивает IP -адрес узла www . mephi . ru в Интернете.

  1. Сервер имен домена (локальный для клиента) пытается найти требуемый IP -адрес в своих базах данных и в кэше DNS и вернуть его клиенту. Если адрес не найден, то данный Сервер имен домена выступает как преобразователь имен и производит запрос к корневому серверу имен (таких серверов сейчас около 15).
  2. Корневой сервер имен просматривает запрос www . m ephi . ru и сообщает преобразователю, где находится сервер . ru , т.е. его IP -адрес .
  3. Затем преобразователь запрашивает сервер . ru на определения адреса www . mephi . ru .
  4. Сервер . ru ищет в своей базе адрес . mephi . ru , и результат поиска сообщает преобразователю
  5. Преобразователь еще раз посылает запрос на определение имени www . mephi . ru , в этот раз уже серверу . mephi . ru .
  6. Полученный ответ в виде полного IP -адреса преобразователь помещает в кэш и передает его клиенту, который его запрашивал.

Один из методов определения адреса самим клиентом является использование файла HOSTS . Этот файл представляет собой локальную базу данных, связывающую IP -адреса с именами узлов. В большинстве UNIX -систем она находится в файле / etc / hosts , а в системе Windows NT местоположение файла HOSTS должно быть в \% Systemroot \ system 32\ drivers \ etc . В файле HOSTS содержится отображение IP -адреса на соответствующее имя узла, причем одному адресу может соответствовать более одного имени, которые отделяются друг от друга пробелом. Чувствительность к регистру букв зависит от конкретной платформы. Помните, что для Windows NT регистр букв не имеет значение. Главное, чтобы файл HOSTS не содержал ошибок, не имел расширения в имени и находился в требуемом месте! Вид типичного файла HOSTS приведен на рисунке 2, где знак # отмечает комментарии.

# Table of IP addresses and host names

127.0.0.1 localhost testhosts

# maps 2 host names to one IP address

#maps one host name to IP address

#maps an FQDN to IP address

#maps one host name to IP address

Рис. 8_ 2. Файл HOSTS

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

Рис. 8_ 3. Настройка службы DNS

В сетях Windows XP имеется возможность использовать оба способа, как через файл HOSTS , так и через службу DNS -сервера . Когда запрашивается имя узла, то выполняются следующие шаги:


  1. служба TCP / IP проверяет, содержится ли данное имя в файле HOSTS ;
  2. если там его нет, то формируется и посылается запрос на разрешение имени соответствующему DNS -серверу .

На рисунке 8_3 приведен пример настроек службы DNS . По умолчанию, имя узла в поле Host Name должно совпадать с текущем именем данного компьютера (его NetBIOS именем ). В окне Domain задается домена организации. Сочетание имени узла и имени домена образует FQDN , под которым данный компьютер будет известен DNS -серверу . В окно DNS Service Search Order вводится IP -адрес DNS -сервера , при необходимости этот список может быть увеличен до 3 адресов. Порядок, в котором указаны адреса, определяет порядок опроса при разрешении имени. Опция Domain Suffix Search Order позволяет использовать дополнительные суффиксы для образования полных доменных имен при определении адреса компьютера, заданного только именем узла.

WINS и разрешение имен NetBIOS

В сетях Windows XP , помимо стандартных средств DNS и HOSTS , для распознавания имен используется и служба определения имен Интернета WINS ( Windows Internet Name Service ). Ее присутствие связано с тем, что все ресурсы в сетях Windows NT (компьютеры, пользователи, папки, общие принтеры и т.д.) имеют имена NetBIOS . Эти имена динамически регистрируются при входе пользователя в сеть ли при запуске службы или приложения. При запросе сетевого ресурса его имя NetBIOS разрешается в IP -адрес с помощью широковещательных пакетов.

Для уменьшения широковещательного трафика NetBIOS Микрософт предлагает использовать сервера WINS или статический файл LMHOSTS . Использование сервера WINS позволяет:

  • Посылать запросы на разрешение имени NetBIOS не в широковещательном режиме, а непосредственно самому серверу, что уменьшает вероятность появления «широковещательных штормов».
  • Эффективно использовать динамически изменяемую базу данных WINS при частой смене IP -адресов клиентов, например при DHCP .

На рисунке 8_4 приведен пример настройки компьютера-клиента на использование сервера WINS .

Помимо сетевого адаптера и IP -адреса основного сервера WINS , можно указать адрес резервного сервера WINS , указать возможность использования DNS -имен и FQDN при работе с приложениями Windows . Примером такой возможности является использование линейной команды NETUSE или NETVIEW . Формат команд NETUSE следующий, для которых работает UNC ( Universal Naming Conversion ):

NETUSE G :\\ NetBIOS >\

где \\ NetBIOS >\ представляет собой UNC .

Если установлена опция Enable DNS for Windows Resolution , то Windows команд можно использовать и другой формат:

NETUSE G :\\ FQDN или IP -адрес >\ .

Помимо возможности использования FQDN , на данной вкладке устанавливается дисциплина использования файла LMHOSTS , который содержит отображение имен NetBIOS в IP — адреса , и его автоматический импорт с любого компьютера сети.

Рис . 8_4 . Настройка службы WIN S

Управление сетями TCP / IP и протоколы прикладного уровня

В любой реализации TCP / IP имеется множество приложений, функционирующих на всех платформах. Эти приложения хорошо документированы и могут работать совместно. В сетях Windows NT часто используется специальный сервер приложений фирмы Микрософт – IIS ( Internet Information Server ), позволяющий управлять этими приложениями и организовывать к ним доступ со стороны клиентов (рис. 8_5).

Рис. 8_ 5 . Приложения IIS

Протокол передачи файлов FTP является самым популярным протоколом уровня приложений. Он использует установление виртуальных каналов для надежной передачи между узлами. При своей работе FTP опирается на TCP с установлением соединения.

К основным функциям FTP относятся:

Работа с файлами,

Перемещение и копирование файлов,

Для переноса файлов сервер, поддерживающий FTP можно настроить на аутентификацию по ученой записи пользователя и паролю, либо оставить возможность анонимного входа по имени « anonymous » с адресом электронной почты вместо пароля.

Возможность настройки службы FTP поддерживается приложением IIS , которая позволяет играть роль сервера FTP . На рисунке 8_6 приведен пример настройки службы FTP в рамках IIS .

Рис. 8_6 . Настройки сервера FTP

Протокол передачи гипертекста HTTP обеспечивает доступ к информации World Wide Web на основе запросов и ответов. Для получения информации клиент HTTP посылает запрос на сервер, который содержит информацию о целях запроса, основные функции поиска и извлечения данных.

Так же, как IIS может служить сервером FTP , также он может быть сервером WWW . На рисунке 8_7 представлена настройка некоторых свойств сервера WWW .

Простой протокол передачи почты SMTP определяет, как передаются сообщения между узлами в сети TCP / IP . Этот протокол не обеспечивает локальный интерфейс пользователя или локальную доставку, он определяет только способ пересылки от узла к узлу. Для создания сообщений, работы с почтовыми ящиками и отправки сообщений, необходима локальная почтовая программа. Обычно, эта дополнительная программа использует еще два протокола: POP 3 ( Post Office Protocol v .3) — почтовый протокол версии 3 и IMAP ( Internet Messaging Access ) — протокол доступа к сообщениям в Интернет.

Рис. 8_7 . Настройки сервера WWW

Простой протокол управления сетью позволяет SNMP основан на дейтаграммном взаимодействии UDP , и является основным инструментом управления в гетерогенных сетях TCP / IP . Протокол позволяет использовать одну из рабочих станций в качестве менеджера SNMP . Из менеджера SNMP можно посылать запросы любому другому активному сетевому устройству, содержащему соответствующее программное обеспечение, т.е. агенту SNMP . У каждого агента SNMP имеется свой набор объектов базы данных управляющей информации MIB ( Management Information Base ), которую менеджер может запрашивать с того или иного узла.

В SNMP определено пять типов команд, которыми можно обмениваться:

  • GetNextRequest – позволяет менеджеру получить информацию из таблицы. Менеджер посылает этот запрос до тех пор, пока не получит требуемую информацию либо не считает всю таблицу;
  • GetRequest – посылается менеджером для получения информации от агента;
  • GetRespons e – посылается агентом в ответ на запрос менеджера;
  • SetRequest – используется менеджером для изменения значений того или иного параметра MIB , ответ на него не обязателен;
  • Trap – используется агентом для уведомления менеджера о некоторых специальных событиях.


В каждый запрос, посылаемый агенту от менеджера, включается имя сообщества. Под именем сообщества понимается текстовая регистро-зависимая строка. Имя сообщества подразделяется на несколько категорий:

  • Сообщества управления – наличие имени сообщества дает менеджеру SNMP право чтения и записи на ограниченный набор объектов MIB . По умолчанию использование имени сообщества управления запрещено, т.к. это позволяет защитить MIB от изменения со стороны менеджера, не имеющего на это права;
  • Сообщества наблюдения – дает право менеджеру SNMP право чтения информации из MIB , по умолчанию присваивается имя “ public ”;
  • Сообщества уведомления – имя сообщества прерывания включается во все уведомления, исходящих из агента, по умолчанию присваивается имя “ public ”.

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

К основным преимуществам использования SNMP в управлении сетью относятся:

  • Широкое распространение;
  • Хорошо проверен и технологичен;
  • Простота интеграции с другими сетевыми технологиями;
  • Легкость масштабирования и построения больших сетей;
  • Преемственность, когда более поздние программные продукты могут динамически управлять более старыми версиями.

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

Для того чтобы спланировать эффективную реализацию SNMP в сетях Windows NT администратор системы должен определить:

  • Имена сообществ, разделяемые сетевыми узлами;
  • IP -адрес или имя узла, который будет работать как менеджер SNMP ;
  • Человека, который будет управлять этим менеджером SNMP .

После того, как указанные свойства определены, необходимо инсталлировать и настроить службу SNMP , входящую в дистрибутив Windows 2003 NT .

После инсталляции в утилите Performance Monitor прибавляются дополнительные счетчики, позволяющие наблюдать за производительностью ICMP , IP , TCP , DHCP , FTP , WINS и IIS . Новые файлы MIB с интересующими администратора сети показателями создаются утилитой Perf 2 MIB .

В 1992 году для решения проблем адресного пространства и ряда смежных задач сообщество Интернет разработало три проекта протоколов : “TCP and UDP with Bigger Addresses (TUBA)”; “Common Architecture for the Internet (CatnIP)” и “Simple Internet Protocol Plus (SIPP) [ смотри “ Протоколы и ресурсы Интернет ” Семенов Ю . А ., Радио и связь , М 1995]. После анализа всех этих предложений был принят новый протокол IPv6 с IP-адресами в 128 бит вместо 32 для IPv4 . Внедрение этого нового протокола представляет отдельную серьезную проблему, так как этот процесс не предполагает замены всего программного обеспечения во всем мире одновременно.

Адресное пространство IPv6 будет распределяться IANA (Internet Assigned Numbers Authority — комиссия по стандартным числам в Интернет [RFC-1881]). IANA будет делегировать права выдачи IP-адресов региональным сервис-провайдерам, субрегиональным структурам и организациям. Отдельные лица и организации могут получить адреса непосредственно от регионального распределителя или сервис провайдера.

Передача адресного пространства от IANA не является необратимым. Если, по мнению IANA распорядитель адресного пространства допустил серьезные ошибки, IANA может аннулировать выполненное ранее выделение.

IPv6 представляет собой новую версию протокола Интернет (RFC-1883 ), являющуюся преемницей версии 4 (IPv4; RFC-791).

Изменения IPv6 можно характеризовать следующим образом.

  1. Использование 128-разрядного адресного пространства, благодаря чему масштабируемость Internet резко повышается. Такое расширение адресного пространства позволит исключить необходимость преобразования сетевых адресов (Network Address Translation, NAT), если протокол будет реализован в сети соответствующим образом. Другое преимущество IPv6 состоит в том, что он предусматривает возможность использования различных типов адресов, например IPX.
  2. Автоматическая конфигурация адресов представляет собой одну из важнейших практических технологий в IPv6. Она не только избавляет от необходимости назначать новые адреса вручную, но и упрощает изменение ранее назначенных адресов. Однако такая система будет работать только при использовании эффективной методики перенумерации.
  3. IPv6 имеет три типа адресов, в этом случае предусматривают уникальную адресацию (unicast addressing), когда пакеты передаются одному адресату, и групповую адресацию (multicast addressing), когда пакеты передаются каждому члену группы, увеличивая накладные расходы на маршрутизацию. Такие сообщения посылаются одному из членов предопределенной группы из нескольких адресов, а не каждому из них.
  4. IPv6 включает также поддержку мобильного IP для обеспечения маршрутизации между беспроводными и наземными сетями. Мобильное устройство сохраняет свой исходный адрес, но при этом оно получает второй адрес с информацией о местонахождении.
  5. IPv6 предусматривает и функции для упрощения и усовершенствования маршрутизации. Некоторые из полей заголовка IPv4 были исключены или стали необязательными, в результате чего накладные расходы на обработку пакетов на маршрутизаторе должны сократиться. Изменение заголовка позволяет также повысить гибкость с точки зрения возможности введения новых опций.

Несколько веб сайтов IIS на одном порту и IP

По умолчанию во время установки сервера IIS (Internet Information Services) создается пустой веб-сайт “Default Web Site”, который отвечает на стандартном веб порту – TCP 80. В терминах IIS это означает, что выполнена привязка этого сайта (Binding) к порту 80. Чтобы открыть этот сайт, достаточно в браузере набрать имя сервера IIS (“http://web-srv1”) или его IP адрес (“http://10.10.0.88”). Один веб сервер IIS может обслуживать десятки и сотни сайтов, и технически можно запустить несколько веб-сайтов, которые слушают и отвечают на одном и том же порту (80 или 443). Однако из интерфейса IIS Manager, совсем не очевидно, что можно запустить второй сайт на этом же хосте без привязки его к другому порту (например, 8080). В этой статье мы разберёмся, как на одном сервере IIS запустить сразу несколько сайтов, чтобы они были привязаны к одному и тому же порту и IP адресу.

Итак, как мы уже говорили ранее, на одном сервере IIS может быть запущено множество сайтов, однако чтобы IIS мог корректно распределять HTTP запросы, каждый сайт должен идентифицироваться неким уникальным значением. Для веб сайта IIS оно формируется из трех атрибутов, комбинация которых для каждого сайта должна быть уникальной. Это:

  • номер TCP порта
  • IP адрес
  • имя узла (host header)

Информация о запущенных сайтах хранится в атрибуте ServerBindings метабазы IIS в формате IP:Port:Hostname. Таким образом, если нужно запустить несколько сайтов на одном порту и IP адресе, нужно использовать уникальный Host header. Что это такое? Host header – это часть HTTP запроса к серверу, который отправляет клиент, указывая к какому конкретно сайту он хочет обратиться. Соответственно, данный host header должен быть указан на стороне веб сервера, а в DNS содержаться корректная запись, осуществляющая соответствие между именем хоста и ip адресом веб-сервера.

Итак, предположим, что у нас на IIS уже запущен один веб сайт на 80 порту. Нам нужно добавить второй сайт на этом же порту.

В консоли управления IIS создадим второй сайт (Add Website). С именем TestSite , файлы которого будут храниться в каталоге c:\inetpub\TestSite (имя хоста пока не указываем).

После того, как вы нажмете “OK”, появится предупреждение, в котором говорится, что вы не можете использовать привязку *:80 для двух сайтов, т.е. одновременно может работать только один из них.


Согласимся с этим предупреждением. Итак, у нас появился второй сайт, также привязанный к 80 порту, но запустить его без остановки первого сайта нельзя.

Чтобы создать уникальную привязку, укажем для второго сайта другое имя (Host Name). Щелкните ПКМ по сайту TestSite и выберите пункт меню Edit Bindings. Выберите нужную привязку и нажмите Edit.

В поле Host Name укажите уникальное имя хоста, к которому должны обращаться пользователи, например TestSite.

Настроить привязку можно и из командной строки. В данном примере для IIS 7 и выше команда установки привязки будет выглядеть так:

C:\Windows\System32\inetsrv\appcmd.exe set site /site.name:»TestSite» /+bindings.[protocol=’http’,bindingInformation=’*:80:TestSite’]

Теперь можно запустить и второй веб сайт.

Все, что осталось сделать – добавить в DNS алиас для сервера (запись типа A или CNAME), указывающую на IP адрес веб-сервера или его имя.

Создать CNAME запись для имени TestSite можно с помощью консоли DNS (dnsmgmt.msc), в качестве FQDN target host указать доменное имя вашего IIS сервера.

Создать такую запись также можно с помощью PowerShell :

Add-DnsServerResourceRecordCName -HostNameAlias web-srv1.contoso.loc -Name testsite -ZoneName contoso.loc

Теперь в браузере попробуйте открыть сайт http://TestSite . Он должен успешно открыться.

Еще несколько полезных моментов, которые стоит упомянуть.

В том случае, если у вас используется локальный сервер IIS, сопоставление имен сайтов с IP адресом сервера выполняется через файл C:\Windows\system32\drivers\etc\hosts .

Настройки привязок хранятся в конфигурационном файле IIS ( C:\Windows\System32\inetsrv\config\applicationHost.config ) в секции

В нашем примере эта секция содержит такие данные :

По аналогии вы можете разместить и запустить на одном порту веб-сервера IIS несколько сотен сайтов.

Базовые сведения об IIS

Структура каталогов IIS

Основные компоненты IIS расположены в каталоге %systemroot%\System32\inetsrv . Структура каталогов inetsrv показана в следующей таблице.

Каталог Описание
ASP Compiled Templates Содержит используемый шаблон ASP.
History Содержит историю изменений метабазы, позволяющую выполнять откат изменений в метабазе.
iisadmpwd Содержит ASP-страницы, относящиеся к аутентификации IIS Admin.
MetaBack Каталог по умолчанию для резервных файлов метабазы.

Примечание. Более подробная информация о метабазе приведена в разделе «Метабаза» далее в лекции.

Веб-сайт администрирования

В IIS 6 веб-сайт администрирования позволяет управлять всем сервером Windows из локального или удаленного веб-браузера. Веб-сайт администрирования располагается в каталоге %systemroot%\System32\ServerAppliance . Он функционирует через SSL, используя порт 8098 по умолчанию. Для доступа к веб-сайту администрирования введите в строке адреса браузера https://имя_компьютера:8098 (где имя_компьютера представляет собой имя компьютера, который необходимо администрировать).

Файлы справки IIS

Все файлы справки IIS 6 перемещены в централизованное место расположения вместе с остальными файлами справки Windows. Это папка %systemroot%\help\iishelp . Самым простым способом вызова справки IIS является выбор команды Help/Help Topics (Справка/Вызов справки) в консоли MMC.

Каталог Inetpub

Каталог Inetpub является основным каталогом файлов IIS. В нем расположены каталоги с содержимым каждой установленной службы. Путь по умолчанию для каталога Inetpub – C:\Inetpub .

Каталог Inetpub содержит следующие подкаталоги.

Каталог Описание
AdminScripts Содержит сценарии Visual Basic, используемые для администрирования сервера IIS.
ftproot Каталог верхнего уровня службы FTP.
mailroot Каталог верхнего уровня службы SMTP.
nntpfile Каталог верхнего уровня службы NNTP.
wwwroot Каталог верхнего уровня веб-сайта по умолчанию.

Учетные записи, используемые в IIS

Поскольку функционирование всех компонентов WS03 рассматривается с точки зрения безопасности, и для доступа необходима учетная запись , IIS устанавливает две учетные записи и одну группу в базу данных учетных записей для использования их в работе. Эти элементы позволяют IIS выполнять программы и рабочие процессы, а пользователям – осуществлять доступ к сайту. Ниже приведена более подробная информация .

IUSR_COMPUTERNAME

Учетная запись обеспечивает анонимный доступ к веб-сайту при подключении пользователя к веб-странице без представления входных данных. Такой пользователь по умолчанию является членом группы Guest (Гость).

IWAM_COMPUTERNAME

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


IIS_WPG

Члены этой группы могут запускать рабочие процессы. Любая учетная запись, выполняющая рабочие процессы, должна быть членом данной группы. Это учетная запись с низким уровнем безопасности, обладающая правами сетевой службы. Процессы, использующие уровень прав Network Service (Сетевая служба), осуществляют доступ к серверу так, как если бы они находились вне сервера, и поэтому не имеют прямого доступа к операционной системе.

Эти процессы можно просмотреть в консоли MMC Computer Management (Управление компьютером) панели Administrative Tools (Администрирование). Для открытия списка Users and Groups (Пользователи и группы) выполните следующие действия.

  1. В меню Start (Пуск) выберите Administrative Tools\ Computer Management (Администрирование\Управление компьютером).
  2. Список пользователей и групп содержится в окне Local Users and Groups (Локальные пользователи и группы) консоли Computer Management (Управление компьютером).
  3. Если компьютер является контроллером домена, список пользователей и групп располагается в окне Active Directory Users And Computers (Компьютеры и пользователи Active Directory) панели Administrative Tools (Администрирование).

Для управления IIS служит оснастка MMC . MMC представляет собой универсальное средство, позволяющее сохранять единую структуру и внешний вид приложений. Для управления IIS 6 используется оснастка IIS . Консоль IIS MMC расположена в окне Start\Administrative Tools (Пуск\Администрирование).

Консоль Microsoft Management Console

С помощью оснастки IIS Manager (или MMC) (см. рис. 1.2) осуществляется управление FTP-сайтами, наборами приложений, веб-сайтами, виртуальными серверами SMTP и NNTP на данном компьютере или на той машине, с которой установлено соединение. По умолчанию соединение установлено с локальным компьютером. Для подключения другого компьютера щелкните правой кнопкой мыши на имени локального компьютера и выберите команду Connect (Подключить).

Управление сайтом с помощью MMC

В верхней части окна IIS Manager (Диспетчер IIS) находится панель инструментов, с помощью которой на сайте выполняются основные функции. Над панелью инструментов располагается строка меню, содержащая команды управления. Нужно помнить, что MMC представляет собой отдельную программу, и что не все опции в ней связаны с IIS. Некоторые опции предназначены для настройки компонентов MMC. Вид панели инструментов и меню изменяется в зависимости от выбора объекта в левой области окна IIS Manager.

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

Свойства локального компьютера. Свойства локального компьютера позволяют изменять параметры, глобально влияющие на все компоненты IIS. Для открытия окна свойства локального компьютера щелкните правой кнопкой мыши на имени_компьютера (локального компьютера) в окне IIS MMC, затем выберите Properties (Свойства). Отобразится окно Properties (см. рис. 1.3).

Изменение любых параметров в этом окне требует последующего перезапуска IIS. На IIS в целом здесь влияют два параметра: Enable Direct Metabase Edit (Включить прямое изменение метабазы) и Encode Web Logs In UTF-8 (Использовать для веб-журналов кодировку UTF-8).

Параметр Enable Direct Metabase Edit (Включить прямое изменение метабазы) позволяет редактировать метабазу при работе IIS. В предыдущих версиях IIS метабаза представляла собой исполняемый файл, доступ к которому был возможен только при помощи специальной утилиты из пакета инструментальных средств. Теперь этот файл можно редактировать в программе Notepad (Блокнот), так как он представлен в формате XML (Расширяемый язык разметки). Можно помещать конфигурацию в буфер и вставлять ее из буфера, сохранять конфигурацию, причем изменения будут вступать в силу незамедлительно. Данный способ работы требует включения журнала метабазы, но так как это является установкой по умолчанию, то никаких вопросов возникать не должно.

Опция Encode Web Logs In UTF-8 (Использовать для веб-журналов кодировку UTF-8) указывает, что в журналах веб и/или FTP должна использоваться кодировка UTF-8, а не локальный набор символов. UTF-8 представляет собой стандарную кодировку текста с восьмибитным кодированием символов Unicode. Для представления каждого символа требуется от одного до шести октетов. UTF-8 использует универсальный набор символов и поддерживает ASCII-текст для совместимости с прежними версиями.

[Конспект админа] Домены, адреса и Windows: смешивать, но не взбалтывать

В очередном «конспекте админа» остановимся на еще одной фундаментальной вещи – механизме разрешения имен в IP-сетях. Кстати, знаете почему в доменной сети nslookup на все запросы может отвечать одним адресом? И это при том, что сайты исправно открываются. Если задумались – добро пожаловать под кат. .

Для преобразования имени в IP-адрес в операционных системах Windows традиционно используются две технологии – NetBIOS и более известная DNS.

Дедушка NetBIOS

NetBIOS (Network Basic Input/Output System) – технология, пришедшая к нам в 1983 году. Она обеспечивает такие возможности как:

регистрация и проверка сетевых имен;

установление и разрыв соединений;

связь с гарантированной доставкой информации;

связь с негарантированной доставкой информации;

  • поддержка управления и мониторинга драйвера и сетевой карты.
  • В рамках этого материала нас интересует только первый пункт. При использовании NetBIOS имя ограниченно 16 байтами – 15 символов и спец-символ, обозначающий тип узла. Процедура преобразования имени в адрес реализована широковещательными запросами.


    Широковещательным называют такой запрос, который предназначен для получения всеми компьютерами сети. Для этого запрос посылается на специальный IP или MAC-адрес для работы на третьем или втором уровне модели OSI.

    Для работы на втором уровне используется MAC-адрес FF:FF:FF:FF:FF:FF, для третьего уровня в IP-сетях адрес, являющимся последним адресом в подсети. Например, в подсети 192.168.0.0/24 этим адресом будет 192.168.0.255

    Интересная особенность в том, что можно привязывать имя не к хосту, а к сервису. Например, к имени пользователя для отправки сообщений через net send.

    Естественно, постоянно рассылать широковещательные запросы не эффективно, поэтому существует кэш NetBIOS – временная таблица соответствий имен и IP-адреса. Таблица находится в оперативной памяти, по умолчанию количество записей ограничено шестнадцатью, а срок жизни каждой – десять минут. Посмотреть его содержимое можно с помощью команды nbtstat -c, а очистить – nbtstat -R.

    Пример работы кэша для разрешения имени узла «хр».

    Что происходило при этом с точки зрения сниффера.

    В крупных сетях из-за ограничения на количество записей и срока их жизни кэш уже не спасает. Да и большое количество широковещательных запросов запросто может замедлить быстродействие сети. Для того чтобы этого избежать, используется сервер WINS (Windows Internet Name Service). Адрес сервера администратор может прописать сам либо его назначит DHCP сервер. Компьютеры при включении регистрируют NetBIOS имена на сервере, к нему же обращаются и для разрешения имен.

    В сетях с *nix серверами можно использовать пакет программ Samba в качестве замены WINS. Для этого достаточно добавить в конфигурационный файл строку «wins support = yes». Подробнее – в документации.

    В отсутствие службы WINS можно использовать файл lmhosts, в который система будет «заглядывать» при невозможности разрешить имя другими способами. В современных системах по умолчанию он отсутствует. Есть только файл-пример-документация по адресу %systemroot%\System32\drivers\etc\lmhost.sam. Если lmhosts понадобится, его можно создать рядом с lmhosts.sam.

    Сейчас технология NetBIOS не на слуху, но по умолчанию она включена. Стоит иметь это ввиду при диагностике проблем.

    Стандарт наших дней – DNS

    DNS (Domain Name System) – распределенная иерархическая система для получения информации о доменах. Пожалуй, самая известная из перечисленных. Механизм работы предельно простой, рассмотрим его на примере определения IP адреса хоста www.google.com:

    если в кэше резолвера адреса нет, система запрашивает указанный в сетевых настройках интерфейса сервер DNS;

    сервер DNS смотрит запись у себя, и если у него нет информации даже о домене google.com – отправляет запрос на вышестоящие сервера DNS, например, провайдерские. Если вышестоящих серверов нет, запрос отправляется сразу на один из 13 (не считая реплик) корневых серверов, на которых есть информация о тех, кто держит верхнюю зону. В нашем случае – com.

    после этого наш сервер спрашивает об имени www.google.com сервер, который держит зону com;

  • затем сервер, который держит зону google.com уже выдает ответ.
  • Наглядная схема прохождения запроса DNS.

    Разумеется, DNS не ограничивается просто соответствием «имя – адрес»: здесь поддерживаются разные виды записей, описанные стандартами RFC. Оставлю их список соответствующим статьям.

    Сам сервис DNS работает на UDP порту 53, в редких случаях используя TCP.

    DNS переключается на TCP с тем же 53 портом для переноса DNS-зоны и для запросов размером более 512 байт. Последнее встречается довольно редко, но на собеседованиях потенциальные работодатели любят задавать вопрос про порт DNS с хитрым прищуром.

    Также как и у NetBIOS, у DNS существует кэш, чтобы не обращаться к серверу при каждом запросе, и файл, где можно вручную сопоставить адрес и имя – известный многим %Systemroot%\System32\drivers\etc\hosts.

    В отличие от кэша NetBIOS в кэш DNS сразу считывается содержимое файла hosts. Помимо этого, интересное отличие заключается в том, что в кэше DNS хранятся не только соответствия доменов и адресов, но и неудачные попытки разрешения имен. Посмотреть содержимое кэша можно в командной строке с помощью команды ipconfig /displaydns, а очистить – ipconfig /flushdns. За работу кэша отвечает служба dnscache.

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

    При попытке разрешения имени обычно используются сервера DNS, настроенные на сетевом адаптере. Но в ряде случаев, например, при подключении к корпоративному VPN, нужно отправлять запросы разрешения определенных имен на другие DNS. Для этого в системах Windows, начиная с 7\2008 R2, появилась таблица политик разрешения имен (Name Resolution Policy Table, NRPT). Настраивается она через реестр, в разделе HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DnsClient\DnsPolicyConfig или групповыми политиками.

    Настройка политики разрешения имен через GPO.

    При наличии в одной сети нескольких технологий, где еще и каждая – со своим кэшем, важен порядок их использования.

    Порядок разрешения имен

    Операционная система Windows пытается разрешить имена в следующем порядке:

    проверяет, не совпадает ли имя с локальным именем хоста;

    смотрит в кэш DNS распознавателя;

    если в кэше соответствие не найдено, идет запрос к серверу DNS;


    если имя хоста «плоское», например, «servername», система обращается к кэшу NetBIOS. Имена более 16 символов или составные, например «servername.domainname.ru» – NetBIOS не используется;

    если не получилось разрешить имя на этом этапе – происходит запрос на сервер WINS;

    если постигла неудача, то система пытается получить имя широковещательным запросом, но не более трех попыток;

  • последняя попытка – система ищет записи в локальном файле lmhosts.
  • Для удобства проиллюстрирую алгоритм блок-схемой:

    Алгоритм разрешения имен в Windows.

    То есть, при запуске команды ping server.domain.com NetBIOS и его широковещательные запросы использоваться не будут, отработает только DNS, а вот с коротким именем процедура пойдет по длинному пути. В этом легко убедиться, запустив простейший скрипт:

    Выполнение второго пинга происходит на несколько секунд дольше, а сниффер покажет широковещательные запросы.

    Сниффер показывает запросы DNS для длинного имени и широковещательные запросы NetBIOS для короткого.

    Отдельного упоминания заслуживают доменные сети – в них запрос с коротким именем отработает чуть по-другому.

    Active Directory и суффиксы

    Active Directory тесно интегрирована с DNS и не функционирует без него. Каждому компьютеру домена создается запись в DNS, и компьютер получает полное имя (FQDN — fully qualified domain name) вида name.subdomain.domain.com.

    Для того чтоб при работе не нужно было вводить FQDN, система автоматически добавляет часть имени домена к хосту при различных операциях – будь то регистрация в DNS или получение IP адреса по имени. Сначала добавляется имя домена целиком, потом следующая часть до точки.

    При попытке запуска команды ping servername система проделает следующее:

    если в кэше DNS имя не существует, система спросит у DNS сервера о хосте servername.subdomain.domain.com;

  • если ответ будет отрицательный – система запросит servername.domain.com, на случай, если мы обращаемся к хосту родительского домена.
  • При этом к составным именам типа www.google.com суффиксы по умолчанию не добавляются. Это поведение настраивается групповыми политиками.

    Настройка добавления суффиксов DNS через групповые политики.

    Настраивать DNS суффиксы можно также групповыми политиками или на вкладке DNS дополнительных свойств TCP\IP сетевого адаптера. Просмотреть текущие настройки удобно командой ipconfig /all.

    Суффиксы DNS и их порядок в выводе ipconfig /all.

    Однако утилита nslookup работает немного по-другому: она добавляет суффиксы в том числе и к длинным именам. Посмотреть, что именно происходит внутри nslookup можно, включив диагностический режим директивой debug или расширенный диагностический режим директивой dc2. Для примера приведу вывод команды для разрешения имени ya.ru:

    Из-за суффиксов утилита nslookup выдала совсем не тот результат, который выдаст например пинг:

    Это поведение иногда приводит в замешательство начинающих системных администраторов.

    Лично сталкивался с такой проблемой: в домене nslookup выдавал всегда один и тот же адрес в ответ на любой запрос. Как оказалось, при создании домена кто-то выбрал имя domain.com.ru, не принадлежащее организации в «большом интернете». Nslookup добавляла ко всем запросам имя домена, затем родительский суффикс – com.ru. Домен com.ru в интернете имеет wildcard запись, то есть любой запрос вида XXX.com.ru будет успешно разрешен. Поэтому nslookup и выдавал на все вопросы один ответ. Чтобы избежать подобных проблем, не рекомендуется использовать для именования не принадлежащие вам домены.

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

    Отсюда частые вопросы – почему ping не работает, а nslookup работает.

    В плане поиска и устранения ошибок разрешения имен могу порекомендовать не бояться использовать инструмент для анализа трафика – сниффер. С ним весь трафик как на ладони, и если добавляются лишние суффиксы, то это отразится в запросах DNS. Если запросов DNS и NetBIOS нет, некорректный ответ берется из кэша.

    Если же нет возможности запустить сниффер, рекомендую сравнить вывод ping и nslookup, очистить кэши, проверить работу с другим сервером DNS.


    Кстати, если вспомните любопытные DNS-курьезы из собственной практики – поделитесь в комментариях.

    Как правильно связать домен iis и конкретный порт на Iis

    Есть арендованный впс(winserver2012), на нем стоит иис, сейчас там хостится допустим 5 сайтов

    • хттп:\ип. порт №80
    • хттп:\ип. порт №82
    • хттп:\ип. порт №85

    в настройках доменного имени у регистратора, в данном случае можно указать только ип, без порта, только ип. Далее если я приду просто по ип,я прийду на основной открытый порт, т.е. 80 мой сайт на 85 к которому я хочу привязать домен, но с домена переходит все равно на основной т.е. на 80

    как сделать так что бы клиента закидывать на тот порт куда ему нужно?

    Вместо IP-адреса используйте имя хоста в IIS 7

    У меня есть простой проект в asp.net mvc3 Я публикую на своем локальном ПК и используя свой IP-адрес, чтобы открыть его. Я пытаюсь использовать имя хоста, которое я установил в IIS, но он не откроет проект. Как использовать имя хоста в IIS7?. Кто-нибудь знает?.

    Чтобы добавить имя хоста в IIS7, выполните следующую процедуру от Microsoft:

    1. Откройте диспетчер IIS. Информацию об открытии диспетчера IIS см. В разделе «Открыть диспетчер IIS (IIS 7)».
    2. На панели «Соединения» разверните узел «Узлы» в дереве и выберите сайт, для которого вы хотите настроить заголовок узла.
    3. На панели «Действия» нажмите «Привязки».
    4. В диалоговом окне «Связывание сайтов» выберите привязку, для которой вы хотите добавить заголовок узла, а затем нажмите «Изменить» или «Добавить», чтобы добавить новую привязку с заголовком узла.
    5. В поле Имя хоста введите заголовок узла для сайта, например www.contoso.com.
    6. Нажмите «ОК».
    7. Чтобы добавить дополнительный заголовок узла, создайте новую привязку с тем же IP-адресом и портом и новым заголовком хоста. Повторите для каждого заголовка хоста, который вы хотите использовать для этого IP-адреса и порта.

    Эта конфигурация означает, что запросы, полученные IIS, для этого имени хоста будут отправлены на определенный вами сайт.

    Однако вам нужна конфигурация для запросов на фактический выход на этот IIS-сервер, и именно здесь используется DNS.

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

    • Если это для сайта интрасети, обратитесь к своей сетевой команде.
    • Если это для интернет-сайта/экстрасети, вам нужно купить доменное имя, и ваш провайдер позволит вам настроить DNS-конфигурацию.
    • Если это используется только для локальных (Windows), вы можете обойти DNS с помощью файла hosts. Проверьте эту страницу, например. Файл hosts позволяет указать локальномукомпьютеру указать имя хоста на IP-адрес по вашему выбору.

    Установка и конфигурирование IIS

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

    В этой и следующих статьях мы рассмотрим различные варианты развертывания. Однако во всех случаях основные предпосылки остаются неизменными. На рабочей станции имеется готовый веб-сайт, который нужно развернуть на сервере, чтобы он был доступен клиентам. Для ASP.NET таким сервером является , а его текущей версией — IIS 8. Когда он был впервые реализован, IIS представлял собой базовый веб-сервер. С годами IIS развился в сложный сервер приложений, предоставляющий широкое множество функциональных средств, наиболее важным из которых является поддержка хостинга приложений ASP.NET.

    В этой статье основное внимание уделяется IIS 8. Хотя машина, на которой запущен IIS 8, здесь называется сервером, IIS можно запускать под управлением версий Windows как для рабочей станции, так и для сервера. На рабочих станциях доступны не все, но большинство функциональных возможностей, что позволяет размещать сложные веб-сайты. По возможности мы рекомендуем использовать Windows Server, однако недорогой альтернативой могут послужить Windows 7 или Windows 8.

    В Microsoft привязывают выпуски IIS с выпусками Windows. В состав Windows Server 2008 и Windows Vista входит версия IIS 7.0, в состав Windows Server 2008 R2 и Windows 7 — версия IIS 7.5, а в состав Windows Server 2012 и Windows 8 — IIS 8. Версии — 7.0 и 7.5 — в Microsoft обобщенно называют IIS 7, что может вносить путаницу. Версию IIS, поддерживаемую операционной системой, изменить нельзя — Windows Server 2008 будет использовать только IIS 7.0. Например, модернизировать ее до версии IIS 7.5, используемой в Windows Server 2008 R2, не получится.

    Установка IIS

    Компонент IIS включен как часть установки Windows (как для сервера, так и для рабочих станций) и требует активизации и конфигурирования. Далее представлены три способа активации IIS для различных операционных систем.

    Установка IIS на настольных версиях Windows (Windows Vista, Windows 7 и Windows 8)

    Каждая версия операционной системы Windows предлагает свою версию IIS — IIS 8 (в Windows 8), IIS 7.5 (в Windows 7) или IIS 7 (в Windows Vista). Во всех этих версиях Windows, IIS включен, но изначально не установлен. Чтобы установить его, необходимо выполнить следующие действия:

    Откройте панель управления.

    Нажмите кнопку «Включение или отключение компонентов Windows». Теперь вам нужно подождать, пока Windows исследует вашу систему.

    Найдите элемент Internet Information Services (Службы IIS) в верхней части списка и нажмите на галочку чтобы включить его:

    Обратите внимание, что Windows позволяет включить множество компонентов IIS: поддержка FTP-сервера, дополнительные инструменты управления, службы обратной совместимости с IIS 6 и т.д.

    Убедитесь, что вы выбрали поддержку ASP.NET. Для этого раскройте узел Службы Интернета Компоненты разработки приложений ASP.NET (Internet Information Services World Wide Web Services Application Development Features ASP.NET):

    Если вы хотите использовать поддержку IIS в Visual Studio, которая позволяет вам создавать виртуальные каталоги IIS непосредственно в диалоговом окне New Web Site, вам нужно выбрать пункт «Совместимость управления IIS 6» в разделе «Средства управления веб-сайтом» (Web Management Tools IIS 6 Management Compatibility).

    Как только вы выбрали нужные параметры IIS, нажмите кнопку OK для завершения установки.

    Установка IIS в Windows Server 2008


    Установка и настройка IIS одинакова для Windows Server 2008 и Windows Server 2008 R2. Необходимые шаги описаны ниже:

    Запустите диспетчер сервера. Чтобы сделать это, нажмите кнопку Start и выберите All Programs Administrative Tools Server Manager.

    Выберите узел Roles в дереве слева.

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

    Выполните необходимые действия в мастере. Вас вероятно попросят установить дополнительные необходимые роли — если это так, нужно просто принять операции и продолжить.

    После установки вам будет предложено настроить веб-сервер. Как в настольных версиях Windows, вы можете выбрать специфические особенности IIS 7, которые должны быть включены.

    Если вы работаете в ASP.NET с версией .NET Framework 4.5, то эту версию .NET Framework необходимо будет установить (центр разработчиков .NET Framework)

    Установка IIS в Windows Server 2012

    Процесс установки IIS в Windows Server 2012, по существу, такой же, как и в Windows Server 2008. Основное различие заключается в том, что пользовательский интерфейс несколько отличается. Подробное описание вы можете найти перейдя по ссылке Installing IIS 8 on Windows Server 2012.

    Управление IIS

    При установке IIS, он автоматически создает каталог с именем C:\inetpub\wwwroot, который представляет ваш веб-сайт. Все файлы в этом каталоге будет отображаться, как будто они находятся в корневом каталоге вашего веб-сервера.

    Чтобы добавить дополнительные страницы на ваш веб-сервер, можно скопировать файлы HTML, ASP или ASP.NET напрямую в каталог C:\Inetpub\wwwroot. Например если добавить файл TestFile.html в этот каталог, вы можете запросить его в браузере через URL-адрес http://localhost/TestFile.html. Вы даже можете создавать вложенные папки для группирования связанных ресурсов. Например, вы можете получить доступ к C:\inetpub\wwwroot\MySite\MyFile.html через браузер, используя URL-адрес http://localhost/MySite/MyFile.html.

    Каталог wwwroot удобен для запуска простых примеров и статичных страниц. Для правильного использования ASP.NET вы должны сделать свой собственный виртуальный каталог для каждого веб-приложения, которое вы создаете. Например, вы можете создать папку с любым именем на любом диске вашего компьютера и поместить ее в виртуальный каталог IIS как будто она расположена в каталоге C:\inetpub\wwwroot.

    Прежде чем начать работу, вам нужно запустить диспетчер служб IIS. Его можно найти в меню Start (Пуск). Конкретное расположение может зависеть от используемой версии Windows (IIS Диспетчер служб IIS). Ярлык программы будет располагаться в разделе Programs (Программы) или Administrative Tools (Администрирование). Начальная страница IIS Manager показана на рисунке ниже:

    Теперь нужно ознакомиться с рядом терминов, используемых в IIS. В левой части окна IIS Manager отображается запись с именем используемого сервера. Наш сервер имеет имя PROFESSORWEB, сгенерированное по умолчанию Windows 8, которое будет использоваться в большинстве примеров. В центральной области отображается представление сервера. Это представление отображает набор значков, которые позволяют конфигурировать параметры сервера. В правой части экрана расположен список доступных действий. Например, в этом представлении можно запускать, останавливать и перезапускать сервер.

    Если развернуть элемент сервера в древовидном представлении в левой части экрана, отобразится элемент Sites (Сайты), содержащий единственную запись Default Web Site (Веб-сайт по умолчанию). Сайт — это коллекция файлов и каталогов, образующих веб-сайт. На одном сервере IIS может поддерживать несколько сайтов, как правило, на различных портах TCP/IP (по умолчанию используется порт 80). Сочетание имени сервера и порта сайта образует первую часть URL-адреса. Например, при использовании сервера mywebserver с сайтом, подключенным к порту 80, URL-адрес выглядит следующим образом:

    Каждый сайт может содержать множество файлов и каталогов. Каждый из них образует часть URL-адреса. Так, URL-адрес статической страницы mypage.html, расположенной в каталоге myfiles, будет следующим:

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

    Чтобы проверить работоспособность IIS выберите Default Web Site и в правой области диспетчера служб IIS выберите пункт «Запустить». После этого нажмите кнопку «Обзор *.80 (http)» чтобы открыть страницу сайта в браузере:

    Как видите, в моем случае я поменял порт используемый по умолчанию (с 80 на 8080). Я сделал это, т.к. на 80-м у меня запущен локальный Apache-сервер. Если у вас возникает такая же проблема, то изменить порт можно щелкнув правой кнопкой мыши по сайту (Default Web Site) и выбрав в контекстном меню «Изменить привязки» (Bindings). После этого в диалоговом окне можно изменить порт, используемый по умолчанию.

    Итак, каждый сервер может поддерживать множество сайтов, каждый из которых работает на другом порту или с другим IP-адресом. Каждый сайт может иметь множество файлов и каталогов, и сочетание этих элементов предоставляет информацию о URL-адресе. Мы вернемся к URL-адресам и использованию IIS Manager при рассмотрении каждого из подходов к развертыванию.

    IIS 7.0: краткая инструкция для системного администратора. Часть 1 – пpoверка результатов установки.

    Продолжаем говорить об процедуре установки веб сервера под управлением IIS 7.0 на Windows Server 2008, которая была рассмотрена в предыдущем посте.

    Теперь перейдем к проверке результатов установки IIS 7.0. Самый простой вариант проверить, работает ли веб сервер, особенно – находясь за локальной консолью, это обратиться из любого веб-браузера по адресу http://localhost/. Далее, проверить с локальной и удаленной машины по IP-адресу.

    При установке IIS 7.0 создается веб сайт по умолчанию, сконфигурированный на ответ при любом URL-запросе, поступившем на порт 80 любого сетевого интерфейса сервера, на котором установлен IIS 7.0. Т.е. запрос браузера типа http://localhost/ должен быть обработан как запрос к веб сайту по умолчанию. Содержимое сайта по умолчанию представляет собой 2 файла – iisstart.htm и welcome.png (который отображается в iisstart.htm), которые и будут открыты клиентом. Поэтому результат обращения к localhost будет иметь следующий вид:

    Теперь, если все хорошо (если «плохо» – поиск неисправностей и ошибок мы рассмотрим позже, в отдельном разделе), убедимся, что все модули, которые должны быть установлены по умолчанию – подключены и работают, а базовая конфигурация – отвечает нашим требованиям.

    1. Основным инструментом управления IIS 7.0 является консоль Internet Information Services (IIS) Manager, которая устанавливается по умолчанию, вместе с ролью Web Server в Windows Server 2008 (IIS Management Console, раздел Management Tools при установки модулей). После соответствующей установки консоль управления IIS 7.0 можно найти, как дочернюю запись внутри раздела Web Server (IIS) в разделе ролей Server Manager, либо как пункт в разделе Administrative Tools меню Start, либо выполнив команду inetmgr (в командной строке или через пункт Run того же меню Start).

    2. При старте консоль Internet Information Services (IIS) Manager открывается с «домашней страницей», на которой в виде панелей находится информация о том, к каким веб серверам и веб сайтам подключался пользователь консоли до этого (если консоль только установлена вместе с ролью Web Server (IIS), то в консоле присутствует запись только о локальном веб сервере), также присутствуют ссылки для выбора подключения к другим серверам, веб сайтам, веб приложениям и папкам, а также ссылки на внешние ресурсы, посвященные IIS.

    3. Кроме того, на домашней странице присутствует панель новостей, которые подгружаются как новостная RSS-лента с сайта www.iis.net, если администратор нажимает на ссылку Enable IIS News. Новости, кстати, очень полезные, рекомендуется включать и использовать эту информацию в повседневной работе.

    4. При подключении к какому либо веб серверу IIS 7.0 консоль Internet Information Services (IIS) Manager представляет его конфигурацию, как логическую структуру – уровень самого веб сервера, чьи настройки являются глобальными и распространяются по умолчанию на все веб сайты, пулы приложений и, сообственно, веб сайты со своими настройками. Эта конфигурационная иерархия, в виде разворачивающегося дерева, начинающегося с узла с именем (или IP) веб сервера, отображается в левой панели консоли Internet Information Services (IIS) Manager.

    5. Если выбрать какой-то узел в дереве конфигурации, то в центральной панель консоли Internet Information Services (IIS) Manager будут отображены в виде отдельных иконок все параметры (а также – модули или списки), соответствующие конфигурации выбранного узла, а в правой панели – набор контекстных задач и операций, которые администратор (или пользователь) может выполнить над данным узлом.

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

    7. В правой панели при выборе узла веб сайта отображаются все операции, возможные для выполнения непосредственно с веб сервером (службами IIS в целом) в данном конексте – перезапуск, останов, запуск, переход к пулам приложений и сайтам.

    8. Убеждаемся, что пулы приложений (Application Pools) сконфигурированы. Пулы приложений будут рассмотрены позже. Пулы являются дочерним узлом в дереве конфигурации для узла веб сайта. При установке по умолчанию создается только один пул – DefaultAppPool, в котором регистрируется одно приложение – сконфигурированный по умолчанию веб сайт, работу которого мы уже проверили. См. снимок экрана.

    9. Ниже узла пулов приложений в дереве конфигурации находится узел веб сайтов (Sites), при выборе которого отображается список работающих на данном веб сервере веб сайтов. По умолчанию создается один веб сайт под названием Default Web Site с внутренним номером (ID) равным 1, «привязанный» на 80 порт всех IP-адресах всех сетевых интерфейсов к любому URL в запросе, и использующий в качестве домашнего каталога своего контента каталог с путем %SystemDrive%\inetpub\wwwroot (что при установленном Windows Server 2008 на диск C: соответствует C: \inetpub\wwwroot).

    10. При выборе в левой панели консоли узла веб сайта (Default Web Site), также, как и в случае с выбором узла веб сервера, в центральной панели отображаются иконки для доступа к параметрам конфигурации различных модулей, на этот раз – конкретного веб сайта. Убеждаемся, что также, как и в случае со всем веб сервером, все необходимые модули представлены в центральной панели.

    11. В правой панели консоли, аналогично панели для всего веб сервера, отображаются контекстные команды, правда, на этот раз их список серьезно расширен – старт/стоп/перезапуск процесса веб сайта, просмотр его базовых и расширенных настроек (а не параметров модулей), настройки привязки (адрес, порт, доменное имя – по сочетанию которых будет отвечать на запросы данный веб сайт) и т.п.

    В принципе, для базовой проверки работоспособности и целостности установки данных шагов вполне достаточно. Но если вы хотите поближе познакомиться с «полным» набором настроек и конфигурацией «по умолчанию» – то можете проделать следующие шаги.

    12. Выберите узел веб сервера в дереве конфигурации в левой панели консоли Internet Information Services (IIS) Manager. В центральной панели кликните на иконку Modules. В центральной панели откроется следующий полный список установленных по умолчанию модулей, представляющий из себя перечень .dll файлов.

    13. Чтобы убедиться, что веб сервер будет работать только со статическими файлами (по умолчанию) или только с нужными вам расширениями – выберите снова узел веб сервера и в центральной панели кликните на иконку Handler Mappings. Откроется список «привязки» расширений вызываемых на веб сайте пользователем файлов и привязанных к данным расширениям модулям, выполняющим обработку данного вызова. Обратите внимание, что по умолчанию все файлы привязаны к модулю обработки статических файлов (т.е. запрос какого либо скриптового или исполнимого файла из домашнего каталога веб сайта не будет приводить к его исполнению на сервере, а лишь к передаче данного файла пользователю), а также к модулям документа по умолчанию и просмотра каталога. С этими модулями мы познакомимся позже.

    14. И, наконец, для того, чтобы убедиться в безопасности веб сайта – проверьте параметры его аутентификации. Для этого выбираем иконку Authentication в той же центральной панели. По умолчанию никаких модулей аутентификации веб сервер (и веб сайты) не поддерживает. Т.е. все подключения для него анонимны. В чем безопасность? Это значит, что пользователям будет доступен только то содержимое домашних каталогов сайтов – файлы и подкаталоги – которые имеют NTFS разрешения для чтения «всем» (Everyone). В случае, если таких разрешений файл не имеет, пользователю будет отказано в доступе с соответствующей ошибкой 401. Если же пользователь попробует каким-то образом аутентифицироваться в процессе HTTP запроса на сервере – то поскольку никаких модулей аутентификации, кроме анонимного, на веб сервере не установлено – он снова получит соответствующую ошибку 401.

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

    Итак, сервер установлен и его работоспособность проверена. Теперь достаточно поместить какой либо статический контент (файлы HTML, изображения, документы и файлы для выгрузки пользователями) в домашний каталог его сайта по умолчанию (напоминаю, что это в большинстве случаев C:\inetpub\wwwroot) – и веб сайт под управлением IIS 7.0 начнет работать. Ну, и конечно, для внешних сайтов – не забыть прописать их A-record в вашей доменной зоне на публичном DNS сервере.

    В следующей части – установка IIS 7.0 в режиме командной строки, особенности работы IIS 7.0 на Server Core.

    Илон Маск рекомендует:  Вырезанные уголки
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL