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

В этой статье описывается настройка параметров прокси-сервера в Windows.

Оригинальная версия продукта: Windows 10 — все выпуски, Windows Server 2012 R2
Исходный номер КБ: 2777643

Домашние пользователи. Эта статья предназначена для использования агентами поддержки и ИТ-специалистами. Дополнительные сведения о настройке прокси-сервера на домашнем компьютере см. в следующей статье:

Аннотация

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

Настройка параметров прокси-сервера с помощью протокола автоматического обнаружения веб-прокси (WPAD)

Рекомендуется использовать WPAD для настройки Windows для использования прокси-сервера в Интернете. Конфигурация делается с помощью DNS или DHCP. Он не требует параметров на клиентских компьютерах. Пользователи могут привозить компьютеры и устройства из дома или других мест и автоматически открывать конфигурацию прокси-сервера в Интернете.

Настройка параметров прокси-сервера в Internet Explorer или с помощью групповой политики

Если вы предпочитаете статически настраивать клиентские компьютеры с помощью параметров прокси-сервера в Интернете, используйте один из следующих методов:

• Настройка параметров в Internet Explorer вручную.
• Настройка компьютеров, присоединив к домену, с помощью групповой политики.

Приложениям, которые не получают параметры прокси в Internet Explorer, может потребоваться установить параметры в каждом приложении для настройки параметров прокси.

Файлы автоматической конфигурации прокси/автоматической конфигурации (PAC)

Параметры файловой конфигурации (PAC) прокси-сервера также можно настраивать вручную в Internet Explorer или с помощью групповой политики. При использовании приложений Microsoft Store тип приложения определяет, используются ли параметры прокси, полученные из файлов PAC. Кроме того, у приложения могут быть параметры для настройки параметров прокси.

Программное обеспечение клиента прокси/брандмауэра

Программное обеспечение клиента прокси/брандмауэра имеет определенный характер для бренда прокси-сервера, который вы используете. Шлюз microsoft Forefront Threat Management Gateway (TMG) 2010 является примером прокси-сервера, который может использовать клиентские программы для управления настройками прокси. Клиентское программное обеспечение прокси/брандмауэра, установленное в качестве драйвера LSP, не будет работать в Windows с любыми приложениями Modern/Microsoft Store, но будет работать со стандартными приложениями. Клиентское программное обеспечение прокси/брандмауэра, установленное в качестве драйвера WFP, будет работать с Windows во всех приложениях. Обратитесь к производителю прокси-серверов, если у вас есть другие вопросы об использовании клиентского программного обеспечения производителя вместе с Windows.

Клиентский инструмент брандмауэра TMG/ISA основан на LSP и не будет работать с приложениями Modern/Microsoft Store.

Параметр командной строки

Вы также можете настроить параметры прокси-сервера с помощью netsh winhttp set proxy команды. Этот параметр рекомендуется только для тестирования, так как его непросто развернуть. Команда должна выполняться по командной подсказке с помощью учетных данных администрирования. Мы не рекомендуем этот вариант для мобильных компьютеров. Причина в том, что большинство пользователей не могут изменить этот параметр при подключении к другой сети.

Дополнительная информация

Дополнительные сведения о настройке параметров прокси-сервера с помощью групповой политики см. в следующей статье:
Средства и параметры расширения обслуживания Internet Explorer

Web Application Proxy в Windows Server 2012 R2

Продолжаем знакомиться с новыми возможностями ОС Windows Server 2012 R2. Ранее мы рассказывали о корпоративном аналоге DropBox в Windows Server 2012 R2 под названием Work Folders. Сегодня речь пойдет о еще одном новшестве новой серверной платформы – функции Web Application Proxy. Web Application Proxy – это новая функция роли Remote Access в Windows 2012 R2, позволяющая публиковать HTTP/ HTTPS приложения, расположенные в периметре корпоративной сети на клиентских устройствах (в первую очередь подразумеваются мобильные устройства) за ее периметром. Благодаря возможности интеграции c AD FS (служба может выступать в качестве ADFS-прокси), возможно обеспечить аутентификацию внешних пользователей, пытающихся получить доступ к опубликованным приложениям.

Web Application Proxy предоставляет такие же возможности публикации приложений, как и Forefront Unified Access Gateway (UAG), однако данная служба также позволяет взаимодействовать с другими серверами и сервисами, обеспечивая тем самым более гибкую и рациональную конфигурацию.

Web Application Proxy по сути выполняет функцию обратного прокси сервера (HTTP reverse proxy), организуя ретрансляцию запросов клиентов из внешней сети на внутренний сервер, и является межсетевым экраном на прикладном уровне.

Сервер со службой Web Application Proxy получает внешний HTTP/HTTPS трафик и терминирует его, после чего от своего имени инициирует новое подключение ко внутреннему приложению (веб-серверу). Т.е. внешние пользователи прямого доступа к внутреннему приложению реально не получают. Любой другой трафик, получаемый Web Application Proxy, отклоняется (в том числе отклоняются HTTP/HTTPS запросы, которые могут быть использованы при DoS, SSL и 0-day атаках).

Требования к организации Web Application Proxy и ключевые особенности:

• Систему можно развернуть на серверах с ОС Windows Server 2012 R2, включенных в домен Active Directory, с ролями AD FS и Web Application Proxy. Эти роли должны быть установлены на разных серверах.
• Необходимо обновить схему Active Directory до Windows Server 2012 R2 (обновлять контроллеры домена до Windows Server 2012 R2 не нужно)
• В качестве клиентских устройств поддерживаются устройства с ОС Windows, IOS (iPad и iPhone). Работы над клиентами для Android и Windows Phone пока еще не окончены
• Аутентификация клиентов осуществляется службой Active Directory Federation Services (ADFS), которая также выполняет функции ADFS – проксирования.
• Типовая схема размещения сервера с ролью Web Application Proxy представлена на рисунке. Данный сервер располагается в выделенной DMZ зоне и отделен от внешней (Интернет) и внутренней сети (Интранет) межсетевыми экранами. В этой конфигурации для работы Web Application Proxy требует наличия двух интерфейсов – внутреннего (Intranet) и внешнего (DMZ)

Установка роли ADFS в Windows Server 2012 R2

Для обеспечения дополнительной безопасности преаутентифкация внешних клиентов выполняется на сервере ADFS, в противном случае используется pass-through аутентификация на конечном сервере приложения (что менее секьюрно). Поэтому первый шаг при настройке Web Application Proxy – установка на отдельном сервере роли Active Directory Federation Services.

При установке ADFS нужно выбрать SSL сертификат, который будет использоваться для шифрования, а также DNS имена, которые будут использоваться клиентами при подключении (соответствующие записи в DNS зоне придется создать самостоятельно).

Затем нужно указать сервисную учетную запись для службы ADFS. Необходимо учесть, что имя ADFS должно быть указано в атрибут Service Principal Name аккаунта. Сделать это можно командой:

И, наконец, указать базу данных, в которой будет хранится информация: это может быть встроенная база на этом же сервере (WID — Windows Internal Database) или отдельная база на выделенном SQL-сервере.

Установка службы Web Application Proxy

Следующий этап, настройка самой службы Web Application Proxy. Напомним, что служба Web Application Proxy в Windows Server 2012 R2 является частью роли “Remote Access”. Установите службу Web Application Proxy и запустите мастер ее настройки.

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

Далее нужно указать сертификат (убедитесь, что в альтернативных именах сертификата содержится имя сервера ADFS).

Публикация приложения через Web Application Proxy

После того, как установлены роли ADFS и Web Application Proxy (которая работает еще и как ADFS Proxy), можно перейти непосредственно к публикации наружу конкретного приложения. Сделать это можно с помощью консоли Remote Access Management Console.

Запустите мастер публикации и укажите, хотите ли вы использовать для преаутентификации службу ADFS (это именно наш вариант).

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

Backend server URL: lync.winitpro.local:4443

Завершите работу мастера, и на этом публикация приложений окончена. Теперь, если попытаться с помощью браузера зайти на опубликованный внешний URL-адрес, то браузер сначала будет перенаправлен на службу аутентификации (ADFS Proxy), а после успешной аутентификации пользователь будет отправлен непосредственно на внутренний сайт (веб приложение).

Благодаря новой службе Web Application Proxy в Windows Server 2012 R2 возможно реализовать функционал обратного прокси сервера с целью публикации внутренних служб предприятия наружу без необходимости использования задействовать сторонние файерволы и продукты, в том числе такие, как Forefront и пр.

Install and Configure the Web Application Proxy Server

Applies To: Windows Server 2012 R2

This content is relevant for the on-premises version of Web Application Proxy. To enable secure access to on-premises applications over the cloud, see the Azure AD Application Proxy content.

This topic describes how to install the Remote Access role with the Web Application Proxy role service and how to configure the Web Application Proxy server to connect to an ActiveВ Directory Federation Services (ADВ FS) server. Before beginning the deployment steps, ensure that you have completed the planning steps described in Plan the Web Application Proxy Server.

This topic includes sample Windows PowerShell cmdlets that you can use to automate some of the procedures described. For more information, see Using Cmdlets.

Configure CAs and certificates

Web Application Proxy servers require the following certificates in the certificate store on each Web Application Proxy server:

A certificate whose subject covers the federation service name. If you want to use Workplace Join, the certificate must also contain the following subject alternative names (SANs): . and enterpriseregistration. .

A wildcard certificate, a subject alternative name (SAN) certificate, several SAN certificates, or several certificates whose subjects cover each web application.

A copy of the certificate issued to external servers when using client certificate preauthentication.

Configure certificate templates

Depending on your deployment and authentication requirements, you might require additional certificate templates on your internal certification authority (CA).

To configure a certificate template

On the internal CA, create a certificate template as described in Creating Certificate Templates.

Deploy the certificate template as described in Deploying Certificate Templates.

Configure web application certificates

In an Web Application Proxy deployment you require certificates for the published web applications, and for the AD FS proxy if your deployment provides AD FS proxy functionality. For these required certificates, there are two options for the issuing CA:

Public—Supplied by a 3rd party.

A website certificate used for server authentication. If the certificate subject is not a wildcard, it must be the externally resolvable fully qualified domain name (FQDN) URL that you configure on the Web Application Proxy server for the application.

Private—The following are required, if they do not already exist:

A website certificate used for server authentication. The certificate subject should be an externally resolvable FQDN that is reachable from the Internet. The certificate can be based on the certificate template created in Configure certificate templates.

A certificate revocation list (CRL) distribution point that is reachable from a publicly resolvable FQDN.

Make sure that the website certificate used for server authentication meets the following requirements:

The common name of the certificate should match the name that you configure for the external URL of the published web application, or the federation service name.

For the Enhanced Key Usage field, use the Server Authentication object identifier (OID).

For the CRL Distribution Points field, specify a CRL distribution point that is accessible by client devices that are connected to the Internet.

The certificate must have a private key.

The certificate must be imported directly into the personal store.

Certificates can have wildcards in the name. A wildcard certificate with the subject name *.contoso.com can be used for web applications in the domain contoso.com, for example, sharepoint.contoso.com and owa.contoso.com. This wildcard certificate cannot be used for the website sharepoint.internal.contoso.com.

Certificates can be subject alternative name (SAN) certificates. For example, a SAN certificate with the names owa.contoso.com and crm.contoso.com can be used for only those two websites. It cannot be used for sharepoint.contoso.com.

For Workplace Join, a SAN certificate is required with the following SANs: . For example, adfs1.contoso.com. enterpriseregistration. For example, enterpriseregistration.contoso.com.

Install the Remote Access role

To deploy Web Application Proxy, you must install the Remote Access role with the Web Application Proxy role service on a server that will act as the Web Application Proxy server.

Repeat this procedure for all of the servers that you want to deploy as Web Application Proxy servers.

To install the Web Application Proxy role service

On the Web Application Proxy server, in the Server Manager console, in the Dashboard, click Add roles and features.

In the Add Roles and Features Wizard, click Next three times to get to the server role selection screen.

On the Select server roles dialog, select Remote Access, and then click Next.

Click Next twice.

On the Select role services dialog, select Web Application Proxy, click Add Features, and then click Next.

On the Confirm installation selections dialog, click Install.

On the Installation progress dialog, verify that the installation was successful, and then click Close.

Windows PowerShell equivalent commands

The following Windows PowerShell cmdlet or cmdlets perform the same function as the preceding procedure. Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because of formatting constraints.

See the instructional video for help Installing the Web Application Proxy

Configure Web Application Proxy

You must configure Web Application Proxy to connect to an AD FS server.

Repeat this procedure for all of the servers that you want to deploy as Web Application Proxy servers.

To configure Web Application Proxy

On the Web Application Proxy server, open the Remote Access Management console: On the Start screen, click the Apps arrow. On the Apps screen, typeВ RAMgmtUI.exe, and then press ENTER. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Yes.

In the navigation pane, click Web Application Proxy.

In the Remote Access Management console, in the middle pane, click Run the Web Application Proxy Configuration Wizard.

On the Web Application Proxy Configuration Wizard, on the Welcome dialog, click Next.

On the Federation Server dialog, do the following, and then click Next:

In the Federation service name box, enter the fully qualified domain name (FQDN) of the AD FS server; for example, fs.contoso.com.

In the User name and Password boxes, enter the credentials of a local administrator account on the AD FS servers.

On the AD FS Proxy Certificate dialog, in the list of certificates currently installed on the Web Application Proxy server, select a certificate to be used by Web Application Proxy for AD FS proxy functionality, and then click Next.

The certificate you choose here should be the one that whose subject is the Federation Service name, for example, fs.contoso.com. If you plan on using Workplace Join, this must be a SAN certificate with the SANs described in Configure CAs and certificates.

On the Confirmation dialog, review the settings. If required, you can copy the PowerShell cmdlet to automate additional installations. Click Configure.

On the Results dialog, verify that the configuration was successful, and then click Close.

Windows PowerShell equivalent commands

The following Windows PowerShell cmdlet or cmdlets perform the same function as the preceding procedure. Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because of formatting constraints.

The following command will prompt you to enter credentials of a local administrator account on the AD FS servers.