Как сетевой сервер управляет запросами от нескольких клиентов для различных служб: Сервер политики сети | Microsoft Learn

Содержание

Сервер политики сети | Microsoft Learn

Статья

04/13/2023

Область применения: Windows Server 2022, Windows Server 2016, Windows Server 2019

Этот раздел можно использовать для обзора сервера политики сети в Windows Server 2016 и Windows Server 2019. NPS устанавливается при установке компонента служб политики сети и доступа (NPAS) в Windows Server 2016 и Server 2019.

Примечание

В дополнение к этому разделу доступна следующая документация по NPS.

Передовые практики по работе с сервером политики сети
Начало работы с сервером политики сети
Планирование сервера политики сети
Развертывание сервера политики сети
Управление сервером политики сети
Командлеты сервера политики сети (NPS) в Windows PowerShell для Windows Server 2016 и Windows 10
Командлеты сервера политики сети (NPS) в Windows PowerShell для Windows Server 2012 R2 и Windows 8. 1
Командлеты NPS в Windows PowerShell для Windows Server 2012 и Windows 8

Сервер сетевых политик (NPS) позволяет создавать и применять политики доступа к сети на уровне организации для проверки подлинности и авторизации сетевых подключений.

Вы также можете настроить NPS в качестве прокси-сервера radius для удаленной проверки подлинности, чтобы перенаправлять запросы на подключение к удаленному серверу NPS или другому серверу RADIUS, чтобы можно было сбалансировать запросы на подключение и перенаправлять их в правильный домен для проверки подлинности и авторизации.

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

СЕРВЕР RADIUS. NPS выполняет централизованную проверку подлинности, авторизацию и учет беспроводных подключений, коммутаторов проверки подлинности, удаленного доступа и VPN. Если сервер политики сети используется в качестве RADIUS-сервера, серверы доступа к сети, например точки беспроводного доступа и VPN-серверы, настраиваются как RADIUS-клиенты на сервере политики сети. Кроме того, можно настроить политики сети, используемые сервером политики сети для авторизации запросов на подключение. Также можно настроить RADIUS-учет, чтобы сервер политики сети сохранял информацию в файлах журнала, хранящихся на локальном жестком диске или в базе данных Microsoft SQL Server. Дополнительные сведения см. в разделе СЕРВЕР RADIUS.
Прокси-сервер RADIUS. При использовании NPS в качестве прокси-сервера RADIUS настраивается политика запросов на подключение, которая сообщает NPS, какие запросы на подключение следует перенаправить на другие серверы RADIUS и на какие серверы RADIUS вы хотите перенаправить запросы на подключение. На сервере политики сети можно также настроить переадресацию данных учета для их хранения на одном или нескольких компьютерах в группе удаленных RADIUS-серверов. Сведения о настройке NPS в качестве прокси-сервера RADIUS см. в следующих разделах. Дополнительные сведения см. в разделе ПРОКСИ-сервер RADIUS.
- Настройка политик запросов на подключение
Учет RADIUS. Вы можете настроить NPS для записи событий в локальный файл журнала или в локальный или удаленный экземпляр Microsoft SQL Server. Дополнительные сведения см. в разделе Ведение журнала NPS.

Важно!

Защита доступа к сети (NAP), центр регистрации работоспособности (HRA) и протокол авторизации учетных данных узла (HCAP) являются устаревшими в Windows Server 2012 R2 и недоступны в Windows Server 2016. Если у вас есть развертывание NAP с использованием операционных систем, предшествующих Windows Server 2016, вы не сможете перенести развертывание NAP в Windows Server 2016.

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

Выпуски Windows Server и NPS

NPS предоставляет различные функции в зависимости от устанавливаемого выпуска Windows Server.

Windows Server 2016 или Windows Server 2019 Standard/Datacenter Edition

С помощью NPS в Windows Server 2016 Standard или Datacenter можно настроить неограниченное количество клиентов RADIUS и удаленных групп серверов RADIUS. Кроме того, можно настроить клиенты RADIUS, указав диапазон IP-адресов.

Примечание

Компонент политики сети И служб доступа WIndows недоступен в системах, установленных с параметром установки Основных серверных компонентов.

В следующих разделах содержатся более подробные сведения о NPS в качестве сервера RADIUS и прокси-сервера.

СЕРВЕР RADIUS и прокси-сервер

NPS можно использовать в качестве сервера RADIUS, прокси-сервера RADIUS или и того, и другого.

сервер RADIUS;

NPS — это реализация майкрософт стандарта RADIUS, определенного целевой группой по разработке в Интернете (IETF) в RFCs 2865 и 2866. Как сервер RADIUS, NPS выполняет централизованную проверку подлинности, авторизацию и учет многих типов сетевого доступа, включая беспроводной, коммутатор проверки подлинности, удаленный доступ к удаленному подключению и виртуальной частной сети (VPN), а также подключения между маршрутизаторами.

Примечание

Сведения о развертывании NPS в качестве СЕРВЕРА RADIUS см. в разделе Развертывание сервера политики сети.

NPS позволяет использовать разнородный набор беспроводных устройств, коммутаторов, оборудования для удаленного доступа или VPN. NPS можно использовать со службой удаленного доступа, которая доступна в Windows Server 2016.

NPS использует домен доменные службы Active Directory (AD DS) или базу данных учетных записей пользователей диспетчера учетных записей безопасности (SAM) для проверки подлинности учетных данных пользователя при попытках подключения. Если сервер, на котором выполняется NPS, является членом домена AD DS, служба NPS использует службу каталогов в качестве базы данных учетной записи пользователя и является частью решения единого входа. Тот же набор учетных данных используется для управления доступом к сети (проверка подлинности и авторизация доступа к сети) и для входа в домен AD DS.

Примечание

NPS использует свойства телефонного подключения учетной записи пользователя и сетевых политик для авторизации подключения.

Поставщики услуг Интернета (ISP) и организации, поддерживающие сетевой доступ, сталкиваются с повышенной проблемой управления всеми типами сетевого доступа из одной точки администрирования, независимо от типа используемого оборудования для доступа к сети. Стандарт RADIUS поддерживает эту функцию как в однородных, так и в разнородных средах. RADIUS — это протокол клиента и сервера, который позволяет оборудованию сетевого доступа (используемому в качестве клиентов RADIUS) отправлять запросы проверки подлинности и учета на сервер RADIUS.

СЕРВЕР RADIUS имеет доступ к сведениям учетной записи пользователя и может проверка учетные данные проверки подлинности сетевого доступа. Если учетные данные пользователя прошли проверку подлинности и попытка подключения авторизована, сервер RADIUS авторизует доступ пользователей на основе указанных условий, а затем регистрирует подключение к сетевому доступу в журнале учета. Использование RADIUS позволяет собирать и хранить данные проверки подлинности, авторизации и учета пользователей сетевого доступа в централизованном расположении, а не на каждом сервере доступа.

Использование NPS в качестве сервера RADIUS

NPS можно использовать в качестве сервера RADIUS, если:

Вы используете домен AD DS или локальную базу данных учетных записей пользователей SAM в качестве базы данных учетных записей пользователей для клиентов доступа.
Вы используете удаленный доступ на нескольких серверах удаленного доступа, VPN-серверах или маршрутизаторах с телефонным подключением по запросу и хотите централизовать как конфигурацию сетевых политик, так и ведение журнала подключений и учет.
Вы передаете поставщику услуг коммутируемый доступ, VPN или беспроводной доступ. Серверы доступа используют RADIUS для проверки подлинности и авторизации подключений, созданных членами вашей организации.
Вы хотите централизовать проверку подлинности, авторизацию и учет разнородного набора серверов доступа.

На следующем рисунке показан сервер NPS в качестве сервера RADIUS для различных клиентов доступа.

RADIUS-прокси

В качестве прокси-сервера RADIUS NPS пересылает сообщения проверки подлинности и учета на NPS и другие radius-серверы. NPS можно использовать в качестве прокси-сервера RADIUS для обеспечения маршрутизации сообщений RADIUS между клиентами RADIUS (также называемыми серверами доступа к сети) и серверами RADIUS, которые выполняют проверку подлинности, авторизацию и учет попытки подключения.

При использовании в качестве прокси-сервера RADIUS NPS представляет собой центральную точку переключения или маршрутизации, через которую передаются сообщения о доступе и учете radius. NPS записывает в журнал учета сведения о пересылаемых сообщениях.

Использование NPS в качестве прокси-сервера RADIUS

NPS можно использовать в качестве прокси-сервера RADIUS, если:

Вы являетесь поставщиком услуг, который предлагает аутсорсинговые службы коммутируемого подключения, VPN или беспроводной сети для нескольких клиентов. NaSs отправляет запросы на подключение к прокси-серверу RADIUS NPS. В зависимости от области имени пользователя в запросе на подключение прокси-сервер RADIUS NPS перенаправит запрос подключения на сервер RADIUS, поддерживаемый клиентом, и может пройти проверку подлинности и авторизовать попытку подключения.
Вы хотите обеспечить проверку подлинности и авторизацию для учетных записей пользователей, которые не являются членами домена, членом которого является NPS, или другого домена, имеющего двустороннее доверие с доменом, членом которого является NPS. Сюда входят учетные записи в недоверенных доменах, односторонних доверенных доменах и других лесах. Вместо того чтобы настраивать серверы доступа для отправки запросов на подключение к серверу RADIUS NPS, можно настроить их для отправки запросов на подключение к прокси-серверу RADIUS NPS. Прокси-сервер RADIUS NPS использует часть имени области в имени пользователя и перенаправляет запрос в NPS в правильном домене или лесу. Попытки подключения для учетных записей пользователей в одном домене или лесу могут проходить проверку подлинности для NAS в другом домене или лесу.
Вы хотите выполнить проверку подлинности и авторизацию с помощью базы данных, которая не является базой данных учетной записи Windows. В этом случае запросы на подключение, соответствующие указанному имени области, перенаправляются на сервер RADIUS, который имеет доступ к другой базе данных учетных записей пользователей и данных авторизации. Примерами других пользовательских баз данных являются базы данных Novell Directory Services (NDS) и язык SQL (SQL).
Вы хотите обработать большое количество запросов на подключение. В этом случае вместо того, чтобы клиенты RADIUS пытались сбалансировать свои запросы на подключение и учет между несколькими radius-серверами, можно настроить их для отправки запросов на подключение и учет на прокси-сервер RADIUS NPS. Прокси-сервер RADIUS NPS динамически распределяет нагрузку запросов подключения и учета на нескольких серверах RADIUS и увеличивает обработку большого количества клиентов RADIUS и проверки подлинности в секунду.
Вы хотите обеспечить проверку подлинности RADIUS и авторизацию для внешних поставщиков услуг и свести к минимуму конфигурацию брандмауэра интрасети. Брандмауэр интрасети находится между сетью периметра (сетью между интрасетью и Интернетом) и интрасетью. Размещая NPS в сети периметра, брандмауэр между сетью периметра и интрасетью должен разрешать трафик между NPS и несколькими контроллерами домена. Заменив NPS прокси-сервером NPS, брандмауэр должен разрешить передачу только трафика RADIUS между прокси-сервером NPS и одним или несколькими NPS в интрасети.

Важно!

NPS поддерживает проверку подлинности в лесах без прокси-сервера RADIUS, если режим работы леса — Windows Server 2003 или выше и между лесами существует двустороннее отношение доверия. Но если вы используете EAP-TLS или PEAP-TLS с сертификатами в качестве метода проверки подлинности, необходимо использовать прокси-сервер RADIUS для проверки подлинности в лесах.

На следующем рисунке показан сервер NPS в качестве прокси-сервера RADIUS между клиентами RADIUS и серверами RADIUS.

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

Конфигурации NPS можно создать для следующих сценариев:

Беспроводной доступ
Удаленный доступ к удаленному подключению организации или виртуальной частной сети (VPN)
Внешний коммутируемый или беспроводной доступ
Доступ к Интернету
Прошедший проверку подлинности доступ к ресурсам экстрасети для бизнес-партнеров

Примеры конфигурации сервера RADIUS и прокси-сервера RADIUS

В следующих примерах конфигурации показано, как настроить NPS в качестве сервера RADIUS и прокси-сервера RADIUS.

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

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

NPS в качестве сервера RADIUS и прокси-сервера RADIUS. В дополнение к политике запросов на подключение по умолчанию, которая указывает, что запросы на подключение обрабатываются локально, создается новая политика запросов на подключение, которая перенаправляет запросы на подключение на NPS или другой сервер RADIUS в недоверенном домене. Эта вторая политика называется политикой прокси-сервера. В этом примере политика прокси-сервера отображается первым в упорядоченном списке политик. Если запрос на подключение соответствует политике прокси-сервера, запрос на подключение пересылается на сервер RADIUS в удаленной группе серверов RADIUS. Если запрос на подключение не соответствует политике прокси-сервера, но соответствует политике запроса на подключение по умолчанию, NPS обрабатывает запрос на подключение на локальном сервере. Если запрос на подключение не соответствует ни той из политик, он отклоняется.

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

NPS с удаленным сопоставлением пользователей RADIUS и Windows. В этом примере NPS выступает как сервер RADIUS и прокси-сервер RADIUS для каждого отдельного запроса на подключение, перенаправляя запрос проверки подлинности на удаленный СЕРВЕР RADIUS, используя локальную учетную запись пользователя Windows для авторизации. Эта конфигурация реализуется путем настройки атрибута Сопоставления удаленных пользователей RADIUS для Windows в качестве условия политики запроса подключения. (Кроме того, учетная запись пользователя должна быть создана локально на сервере RADIUS с тем же именем, что и учетная запись удаленного пользователя, для которой выполняется проверка подлинности с помощью удаленного radius-сервера.)

Параметр Configuration

Чтобы настроить NPS в качестве сервера RADIUS, можно использовать стандартную конфигурацию или расширенную конфигурацию в консоли NPS или в диспетчер сервера. Чтобы настроить NPS в качестве прокси-сервера RADIUS, необходимо использовать расширенную конфигурацию.

Стандартная конфигурация

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

Сервер RADIUS для коммутируемых или VPN-подключений
RADIUS-сервер для беспроводных или проводных подключений 802.1 X

Чтобы настроить NPS с помощью мастера, откройте консоль NPS, выберите один из предыдущих сценариев и щелкните ссылку, которая открывает мастер.

Расширенная конфигурация

При использовании расширенной конфигурации вы вручную настраиваете NPS в качестве сервера RADIUS или прокси-сервера RADIUS.

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

Предоставляются следующие расширенные элементы конфигурации.

Настройка сервера RADIUS

Чтобы настроить NPS в качестве сервера RADIUS, необходимо настроить клиенты RADIUS, сетевую политику и учет RADIUS.

Инструкции по созданию этих конфигураций см. в следующих разделах.

Настройка клиентов RADIUS
Настройка политик сети
Настройка учета сервера политики сети

Настройка прокси-сервера RADIUS

Чтобы настроить NPS в качестве прокси-сервера RADIUS, необходимо настроить клиенты RADIUS, удаленные группы серверов RADIUS и политики запросов на подключение.

Инструкции по созданию этих конфигураций см. в следующих разделах.

Настройка клиентов RADIUS
Настройка групп удаленных серверов RADIUS
Настройка политик запросов на подключение

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

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

Дополнительные сведения см. в разделе Настройка учета сервера политики сети.

Развертывание нескольких серверов удаленного доступа в многосайтового развертывания

Twitter

LinkedIn

Facebook

Адрес электронной почты

Статья

12/21/2022

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016

Windows Server 2016 и Windows Server 2012 объединить VPN DirectAccess и службу удаленного доступа (RAS) в одну роль удаленного доступа. Развертывание удаленного доступа возможно в нескольких корпоративных сценариях. Этот обзор содержит общие сведения о корпоративном сценарии развертывания серверов удаленного доступа в конфигурации с несколькими сайтами.

Описание сценария

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

Многосайтовое развертывание поддерживает клиентские компьютеры под управлением Windows 10, Windows 8 или Windows 7. Клиентские компьютеры под управлением Windows 10 или Windows 8 автоматически идентифицируют точку входа или пользователь может вручную выбрать точку входа. Автоматическое назначение выполняется в следующем порядке приоритета:

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

Поддержка клиентов, работающих Windows 7, должна быть включена вручную в каждой точке входа, а выбор точки входа этими клиентами не поддерживается.

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

Перед началом развертывания этого сценария ознакомьтесь со списком важных требований.

Перед развертыванием с несколькими сайтами необходимо развернуть один сервер DirectAccess с дополнительными Параметры.
Windows 7 клиентов всегда будут подключаться к определенному сайту. Они не смогут подключаться к ближайшему сайту в зависимости от расположения клиента (в отличие от Windows 10, 8 или 8.1 клиентов).
Изменение политик вне консоли управления DirectAccess или командлетов PowerShell не поддерживается.
Должна быть развернута инфраструктура открытого ключа.
Дополнительная информация: Мини-модуль руководства по лаборатории тестирования: Базовая PKI для Windows Server 2012.
Корпоративная сеть должна быть включена в IPv6. Если вы используете протокол ISATAP, необходимо удалить его и перейти на собственный IPv6.

Содержание сценария

Сценарий многосайтового развертывания включает в себя ряд шагов.

Разверните один сервер DirectAccess с дополнительными параметрами. Перед настройкой многосайтового развертывания необходимо развернуть один сервер удаленного доступа с дополнительными параметрами.
Планирование многосайтового развертывания. Для создания многосайтового развертывания с одного сервера требуются ряд дополнительных шагов планирования, включая соответствие требованиям к многосайтовой среде и планирование групп безопасности Active Directory, групповая политика объектов (GPO), DNS и параметров клиента.
Настройка многосайтового развертывания. Это состоит из ряда шагов конфигурации, включая подготовку инфраструктуры Active Directory, конфигурацию существующего сервера удаленного доступа и добавление нескольких серверов удаленного доступа в качестве точек входа в многосайтовое развертывание.
Устранение неполадок многосайтового развертывания. В этом разделе по устранению неполадок описывается ряд наиболее распространенных ошибок, которые могут возникнуть при развертывании удаленного доступа в многосайтовом развертывании.

Практическое применение

Многосайтовое развертывание обеспечивает следующее:

Улучшенная производительность мультисайтового развертывания позволяет клиентским компьютерам получать доступ к внутренним ресурсам с помощью удаленного доступа для подключения с помощью ближайшей и наиболее подходящей точки входа. Повышение эффективности клиентского доступа к внутренним ресурсам и повышение скорости клиентских запросов к Интернету, перенаправленных через DirectAccess. Трафик между точками входа можно сбалансировать с помощью внешней глобальной подсистемы балансировки нагрузки.
Упрощенное управление и мультисайт позволяет администраторам согласовывать развертывание удаленного доступа с развертыванием сайтов Active Directory, предоставляя упрощенную архитектуру. Общие параметры можно легко задать между серверами или кластерами точек входа. Параметры удаленного доступа можно управлять с любого сервера в развертывании или удаленно с помощью средств удаленного администрирования сервера (RSAT). Кроме того, можно отслеживать все многосайтовое развертывание из одной консоли управления удаленным доступом.

Роли и компоненты, используемые в данном сценарии

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

Роль/компонент	Способ поддержки сценария
Роль удаленного доступа	Эта роль устанавливается и удаляется с помощью консоли Диспетчера серверов. В эту роль входят и DirectAccess, служивший ранее компонентом Windows Server 2008 R2, и службы маршрутизации и удаленного доступа (RRAS), которые ранее представляли собой службу в составе роли сервера служб политики сети и доступа. Роль удаленного доступа включает два компонента. — DirectAccess и маршрутизация и удаленные службы Access (RRAS) VPN-DirectAccess и VPN управляются вместе в консоли управления удаленным доступом. — Функции маршрутизации RRAS-RRAS управляются в устаревшей консоли маршрутизации и удаленного доступа. Существуют следующие зависимости. — веб-сервер службы IIS (IIS) — эта функция необходима для настройки сервера сетевых расположений и веб-пробы по умолчанию. — Windows внутренних Database-Used для локального учета на сервере удаленного доступа.
Средства управления удаленным доступом	Этот компонент устанавливается описанным ниже образом. — Он устанавливается по умолчанию на сервере удаленного доступа при установке роли удаленного доступа и поддерживает пользовательский интерфейс консоли удаленного управления. — При необходимости его можно установить на сервере, на котором не запущена роль сервера удаленного доступа. В этом случае компонент используется для удаленного управления компьютером с возможностью удаленного доступа, на котором установлены DirectAccess и VPN. Средства управления удаленным доступом включают следующие элементы: — графический интерфейс удаленного доступа и средства командной строки — модуль удаленного доступа для Windows PowerShell Зависимости включают следующее: — консоль управления групповая политика — пакет администрирования ДИСПЕТЧЕР ПОДКЛЮЧЕНИЙ RAS (CMAK) — Windows PowerShell 3.0 — графические средства управления и инфраструктура

Роль/компонент

Способ поддержки сценария

Роль удаленного доступа

Эта роль устанавливается и удаляется с помощью консоли Диспетчера серверов.

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

— DirectAccess и маршрутизация и удаленные службы Access (RRAS) VPN-DirectAccess и VPN управляются вместе в консоли управления удаленным доступом.
— Функции маршрутизации RRAS-RRAS управляются в устаревшей консоли маршрутизации и удаленного доступа.

Существуют следующие зависимости.

— веб-сервер службы IIS (IIS) — эта функция необходима для настройки сервера сетевых расположений и веб-пробы по умолчанию.
— Windows внутренних Database-Used для локального учета на сервере удаленного доступа.

Средства управления удаленным доступом

Этот компонент устанавливается описанным ниже образом.

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

Средства управления удаленным доступом включают следующие элементы:

— графический интерфейс удаленного доступа и средства командной строки
— модуль удаленного доступа для Windows PowerShell

Зависимости включают следующее:

— консоль управления групповая политика
— пакет администрирования ДИСПЕТЧЕР ПОДКЛЮЧЕНИЙ RAS (CMAK)
— Windows PowerShell 3.0
— графические средства управления и инфраструктура

Требования к оборудованию

Для этого сценария действуют следующие требования к оборудованию.

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

Требования к программному обеспечению

Для этого сценария действуют следующие требования к программному обеспечению.

Требования к программному обеспечению для развертывания на одном сервере.
Помимо требований к программному обеспечению для одного сервера существует ряд требований к многосайтовой среде:
- Требования к проверке подлинности IPsec. В многосайтовом развертывании DirectAccess необходимо развернуть с помощью проверки подлинности на основе сертификата компьютера IPsec. Возможность проверки подлинности IPsec с помощью сервера удаленного доступа в качестве прокси-сервера Kerberos не поддерживается. Для развертывания сертификатов IPsec требуется внутренний ЦС.
- Требования к IP-HTTPS и серверу сетевых расположений— сертификаты, необходимые для IP-HTTPS, и сервер сетевых расположений должен быть выдан ЦС. Параметр использования сертификатов, автоматически выданных и самозаверяющих сервером удаленного доступа, не поддерживается. Сертификаты могут быть выданы внутренним ЦС или сторонним внешним ЦС.
- Требования к Active Directory— требуется по крайней мере один сайт Active Directory. Сервер удаленного доступа должен находиться на сайте. Для ускорения обновления рекомендуется, чтобы на каждом сайте был записываемый контроллер домена, хотя это не обязательно.
- Требования к группе безопасности: требования к группе безопасности приведены ниже.
  - Для всех Windows 8 клиентских компьютеров из всех доменов требуется одна группа безопасности. Рекомендуется создать уникальную группу безопасности этих клиентов для каждого домена.
  - Для каждой точки входа, настроенной для поддержки Windows 7 клиентов, требуется уникальная группа безопасности, содержащая Windows 7 компьютеров. Рекомендуется иметь уникальную группу безопасности для каждой точки входа в каждом домене.
  - Компьютеры должны входить только в одну группу безопасности, включающую клиентов DirectAccess. Если клиенты включены в несколько групп, разрешение имен для клиентских запросов будет работать некорректно.
- Объекты групповой политики групповой политики можно создавать вручную перед настройкой удаленного доступа или автоматически создавать во время развертывания удаленного доступа. Ниже приведены требования.
  - Для каждого домена требуется уникальный объект групповой политики клиента.
  - Объект групповой политики сервера требуется для каждой точки входа в домене, в котором расположена точка входа. Таким образом, если несколько точек входа находятся в одном домене, в домене будет несколько объектов групповой политики сервера (по одной для каждой точки входа).
  - Для каждой точки входа, включенной для поддержки Windows 7 клиентов, для каждого домена требуется уникальный объект групповой политики клиента Windows 7.

Известные проблемы

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

Несколько точек входа в одной подсети IPv4. Добавление нескольких точек входа в одну подсеть IPv4 приведет к конфликту IP-адресов, и DNS64-адрес для точки входа не будет настроен должным образом. Эта проблема возникает, когда протокол IPv6 не был развернут во внутренних интерфейсах серверов в корпоративной сети. Чтобы предотвратить эту проблему, выполните следующую команду Windows PowerShell на всех текущих и будущих серверах удаленного доступа:
```
Set-NetIPInterface -InterfaceAlias <InternalInterfaceName> -AddressFamily IPv6 -DadTransmits 0
```
Если общедоступный адрес, указанный для клиентов DirectAccess для подключения к серверу удаленного доступа, имеет суффикс, включенный в NRPT, DirectAccess может работать неправильно. Убедитесь, что NRPT имеет исключение для общедоступного имени. В многосайтовом развертывании следует добавить исключения для общедоступных имен всех точек входа. Обратите внимание, что если принудительное туннелирование включено, эти исключения добавляются автоматически. Они удаляются, если принудительное туннелирование отключено.
При использовании командлета Windows PowerShell Disable-DAMultiSite параметры WhatIf и Confirm не влияют, а multisite будет отключен и Windows 7 объектов групповой политики будут удалены.
Если Windows 7 клиентов, использующих DCA в многосайтовом развертывании, обновляются до Windows 8, помощник по сетевому подключению не будет работать. Эту проблему можно устранить заранее при обновлении клиента, изменив объекты групповой политики Windows 7 с помощью следующих командлетов Windows PowerShell:
```
Set-GPRegistryValue -Name <Windows7GpoName> -Domain <DomainName> -Key "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityAssistant" -ValueName "TemporaryValue" -Type Dword -Value 1
Remove-GPRegistryValue -Name <Windows7GpoName> -Domain <DomainName> -Key "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityAssistant"
```
Если клиент уже обновлен, переместите клиентский компьютер в группу безопасности Windows 8.
При изменении параметров контроллера домена с помощью командлета Set-DAEntryPointDC Windows PowerShell, если указанный параметр ComputerName является сервером удаленного доступа в точке входа, отличной от последней, добавленной в развертывание с несколькими сайтами, появится предупреждение о том, что указанный сервер не будет обновлен до следующего обновления политики. Фактические серверы, которые не были обновлены, можно увидеть с помощью состояния конфигурации на панели мониторингаконсоли управления удаленным доступом. Это не приведет к функциональным проблемам, однако можно запустить gpupdate /force на серверах, которые не были обновлены, чтобы немедленно обновить состояние конфигурации.
Если мультисайт развертывается в корпоративной сети только для IPv4, изменение префикса внутренней сети IPv6 также изменяет адрес DNS64, но не обновляет адрес в правилах брандмауэра, разрешающих dns-запросы к службе DNS64. Чтобы устранить эту проблему, выполните следующие команды Windows PowerShell после изменения префикса IPv6 внутренней сети:
```
$dns64Address = (Get-DAClientDnsConfiguration).NrptEntry | ?{ $_.DirectAccessDnsServers -match ':3333::1' } | Select-Object -First 1 -ExpandProperty DirectAccessDnsServers
$serverGpoName = (Get-RemoteAccess).ServerGpoName
$serverGpoDc = (Get-DAEntryPointDC).DomainControllerName
$gpoSession = Open-NetGPO -PolicyStore $serverGpoName -DomainController $serverGpoDc
Get-NetFirewallRule -GPOSession $gpoSession | ? {$_.Name -in @('0FDEEC95-1EA6-4042-8BA6-6EF5336DE91A', '24FD98AA-178E-4B01-9220-D0DADA9C8503')} |  Set-NetFirewallRule -LocalAddress $dns64Address
Save-NetGPO -GPOSession $gpoSession
```
Если directAccess был развернут при наличии существующей инфраструктуры ISATAP, при удалении точки входа, которая была узлом ISATAP, IPv6-адрес службы DNS64 будет удален с адресов DNS-серверов всех DNS-суффиксов в NRPT.
Чтобы устранить эту проблему, в мастере установки сервера инфраструктуры на странице DNS удалите суффиксы DNS, которые были изменены, и снова добавьте их с правильными адресами DNS-сервера, щелкнув диалоговое окно «Обнаружениеадресов DNS-сервера «.

Сеть

. Как веб-сервер может обрабатывать входящие запросы нескольких пользователей одновременно на одном порту (80)?

спросил
9 лет, 11 месяцев назад

Изменено
1 год, 11 месяцев назад

Просмотрено
75 тысяч раз

Как веб-сервер обрабатывает несколько входящих запросов одновременно на одном порту (80)?

Пример:
В то же время 300 тыс. пользователей хотят видеть изображение с сайта www.abcdef.com, которому назначен IP 10.10.100.100 и порт 80. Так как же www.abcdef.com может справиться с такой входящей нагрузкой пользователей?

Может ли один сервер (которому присвоен IP-адрес 10.10.100.100) обрабатывать такое огромное количество входящих пользователей? Если нет, то как можно назначить один IP-адрес более чем одному серверу для обработки этой нагрузки?

сеть
веб-приложения
сеть
TCP
сетевое программирование

Порт — это просто магическое число. Это не соответствует аппаратному обеспечению. Сервер открывает сокет, который «слушает» порт 80 и «принимает» новые подключения из этого сокета. Каждое новое соединение представлено новым сокетом, чей локальный порт также является портом 80, но чей удаленный IP: порт соответствует клиенту, который подключился. Так они не перепутаются. Поэтому вам не нужно несколько IP-адресов или даже несколько портов на стороне сервера.

Из tcpipguide

Эта идентификация соединений с использованием как клиентских, так и серверных сокетов обеспечивает гибкость в разрешении множественных соединений между устройствами, которые мы считаем само собой разумеющимися в Интернете. Например, загруженные серверные процессы приложений (такие как веб-серверы) должны иметь возможность обрабатывать соединения от более чем одного клиента, иначе Всемирная паутина будет практически непригодна для использования. Поскольку соединение идентифицируется с помощью сокета клиента, а также сокета сервера, это не проблема. В то время как веб-сервер поддерживает соединение, упомянутое выше, он может легко иметь другое соединение, например, порт 2,19.9 по IP-адресу 219.31.0.44. Это представлено идентификатором соединения:

 (41.199.222.3:80, 219.31.0.44:2199).

На самом деле у нас может быть несколько подключений от одного клиента к одному и тому же серверу. Каждому клиентскому процессу будет назначен различный временный номер порта, поэтому, даже если все они попытаются получить доступ к одному и тому же процессу сервера (например, процессу веб-сервера по адресу 41.199.222.3:80), все они будут иметь разные клиентские сокеты и представлять уникальные связи. Это то, что позволяет вам делать несколько одновременных запросов к одному и тому же веб-сайту с вашего компьютера.
Опять же, TCP отслеживает каждое из этих соединений независимо, поэтому каждое соединение не знает о других. TCP может обрабатывать сотни или даже тысячи одновременных подключений. Единственным ограничением является мощность компьютера, на котором работает протокол TCP, и пропускная способность физических подключений к нему: чем больше подключений выполняется одновременно, тем больше ресурсов приходится на каждое из них.

TCP Обеспечивает идентификацию клиента
Как я уже сказал, TCP заботится об идентификации клиента, а сервер видит только «сокет» для каждого клиента.
Допустим, сервер с адресом 10.10.100.100 прослушивает порт 80 для входящих TCP-соединений (HTTP создан поверх TCP). Браузер клиента (по адресу 10.9.8.7) подключается к серверу, используя клиентский порт 27143. Сервер видит: «клиент 10.9.8.7:27143 хочет подключиться, вы согласны?». Серверное приложение принимает и получает «дескриптор» (сокет) для управления всей связью с этим клиентом, и этот дескриптор всегда будет отправлять пакеты на 10.9..8.7:27143 с соответствующими заголовками TCP.

Пакеты никогда не бывают одновременными
Теперь физически существует только одно (или два) соединения, связывающее сервер с Интернетом, поэтому пакеты могут приходить только в последовательном порядке. Возникает вопрос: какова максимальная пропускная способность оптоволокна и сколько ответов сервер может вычислить и отправить в ответ. Помимо затраченного времени ЦП или узких мест в памяти при ответе на запросы, сервер также должен поддерживать некоторые ресурсы (по крайней мере, 1 активный сокет на каждого клиента) до тех пор, пока связь не будет завершена, и, следовательно, потреблять ОЗУ. Пропускная способность достигается за счет некоторых оптимизаций (не исключающих друг друга): неблокирующие сокеты (чтобы избежать конвейерной обработки/задержек сокетов), многопоточность (чтобы использовать больше ядер/потоков ЦП).

Дальнейшее повышение пропускной способности запросов: балансировка нагрузки
И, наконец, сервер на «лицевой стороне» веб-сайтов обычно не выполняет всю работу самостоятельно (особенно более сложные вещи, такие как запросы к базе данных, вычисления и т. д.) , и откладывать задачи или даже пересылать HTTP-запросы на распределенные серверы, в то время как они продолжают тривиально обрабатывать (например, пересылать) столько запросов в секунду, сколько могут. Распределение работы по нескольким серверам называется load-balancing .

1) Как веб-сервер обрабатывает несколько входящих запросов одновременно на одном порту (80)
==> а) один экземпляр веб-службы (пример: микрослужба весенней загрузки) запускается/прослушивается на сервере машина на порту 80.
b) Этому веб-сервису (приложение Spring boot) нужен контейнер сервлетов, как в основном tomcat.
В этом контейнере будет настроен пул потоков .
c) когда когда-либо запросы поступают от разных пользователей одновременно, этот контейнер будет
назначить каждый поток из пула для каждого из входящих запросов.
d) Поскольку код веб-службы на стороне сервера будет иметь beans (в случае java) в основном
singleton, каждый поток, относящийся к каждому запросу, будет вызывать singleton API
, и если есть необходимость в доступе к базе данных, то синхронизация этих
потоки необходимы, что делается с помощью аннотации @transactional. Эта аннотация
синхронизирует работу базы данных.

2) Может ли один сервер (которому присвоен IP-адрес 10.10.100.100) обрабатывать такое огромное количество входящих пользователей?
Если нет, то как можно назначить один IP-адрес более чем одному серверу для обработки этой нагрузки?
==> Об этом позаботится балансировщик нагрузки вместе с таблицей маршрутизации

ответ: виртуальные хосты, в заголовке HTTP это имя домена, поэтому веб-сервер знает, какие файлы запускаются или отправляются клиенту

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

Зарегистрируйтесь, используя электронную почту и пароль

Опубликовать как гость

Электронная почта

Обязательно, но не отображается

Опубликовать как гость

Электронная почта

Требуется, но не отображается

http — Как несколько клиентов одновременно подключаются к одному порту, скажем, 80, на сервере?

Итак, что происходит, когда сервер прослушивает входящие соединения через TCP-порт? Например, предположим, что у вас есть веб-сервер на порту 80. Предположим, что ваш компьютер имеет общедоступный IP-адрес 24.14.181.229, а человек, который пытается подключиться к вам, имеет IP-адрес 10.1.2.3. Этот человек может подключиться к вам, открыв сокет TCP на 24.14.181.229.на самом деле это не то, что происходит, но это концептуальная модель, которую имеют в виду многие люди.

Это интуитивно понятно, потому что с точки зрения клиента он имеет IP-адрес и подключается к серверу по адресу IP:PORT. Раз клиент подключается к 80 порту, то и его порт тоже должен быть 80? Это разумная вещь, чтобы думать, но на самом деле не то, что происходит. Если бы это было так, мы могли бы обслуживать только одного пользователя на иностранный IP-адрес. Как только удаленный компьютер подключается, он перехватывает соединение с порта 80 на порт 80, и никто другой не может подключиться.

Необходимо понимать три вещи:

1.) На сервере процесс прослушивает порт . Как только он получает соединение, он передает его другому потоку. Связь никогда не перегружает прослушивающий порт.

2.) Соединения однозначно идентифицируются ОС по следующим пяти кортежам: (локальный IP-адрес, локальный порт, удаленный IP-адрес, удаленный порт, протокол). Если какой-либо элемент в кортеже отличается, то это полностью независимое соединение.

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

Итак, вот что на самом деле создается, когда клиент подключается к серверу:

 Локальный компьютер | Удаленный компьютер | Роль
    -------------------------------------------------- ---------
    0.0.0.0:80 | <нет> | ПРОСЛУШИВАНИЕ
    127.0.0.1:80 | 10.1.2.3:<случайный_порт> | УЧРЕДИЛ

Во-первых, воспользуемся netstat, чтобы посмотреть, что происходит на этом компьютере. Мы будем использовать порт 500 вместо 80 (потому что на 80-м порту происходит куча всего, так как это общий порт, но функционально это не имеет значения).

 netstat-atnp | grep -i ":500"

Как и ожидалось, вывод пустой. Теперь запустим веб-сервер:

 sudo python3 -m http.server 500

Теперь снова результат запуска netstat:

 Proto Recv-Q Send-Q Local Address Foreign Address State
    TCP 0 0 0.0.0.0:500 0.0.0.0:* ПРОСЛУШАТЬ -

Итак, теперь есть один процесс, который активно прослушивает (состояние: LISTEN) порт 500. Локальный адрес — 0.0.0.0, что соответствует коду «прослушивания для всех». Легко совершить ошибку — прослушивать адрес 127.0.0.1, который будет принимать соединения только с текущего компьютера. Так что это не соединение, это просто означает, что процесс запросил bind() для IP-порта, и этот процесс отвечает за обработку всех соединений с этим портом. Это намекает на ограничение, согласно которому на каждом компьютере может быть только один процесс, прослушивающий порт (есть способы обойти это с помощью мультиплексирования, но это гораздо более сложная тема). Если веб-сервер прослушивает порт 80, он не может использовать этот порт совместно с другими веб-серверами.

Теперь давайте подключим пользователя к нашей машине:

 quicknet -m tcp -t localhost:500 -p Проверка полезной нагрузки.

Это простой скрипт (https://github.com/grokit/dcore/tree/master/apps/quicknet), который открывает TCP-сокет, отправляет полезную нагрузку (в данном случае «Проверка полезной нагрузки»), ждет несколько секунд и отключается. При повторном выполнении netstat во время этого отображается следующее:

 Proto Recv-Q Send-Q Local Address Foreign Address State
    TCP 0 0 0.0.0.0:500 0.0.0.0:* ПРОСЛУШАТЬ -
    TCP 0 0 192.168.1.10:500 192.168.1.13:54240 УСТАНОВЛЕН -

Если вы подключитесь к другому клиенту и снова выполните netstat, вы увидите следующее:

 Proto Recv-Q Send-Q Local Address Foreign Address State
    TCP 0 0 0.0.0.0:500 0.0.0.0:* ПРОСЛУШАТЬ -
    TCP 0 0 192.168.1.10:500 192.168.1.13:26813 УСТАНОВЛЕНО -

… то есть клиент использовал для подключения другой случайный порт. Таким образом, никогда не бывает путаницы между IP-адресами.