Enabling end to end tls on azure application gateway

Экспорт доверенного корневого сертификата (для SKU версии 2)

Доверенный корневой сертификат необходим для разрешения внутренних экземпляров в SKU версии 2 шлюза приложений. Корневой сертификат — это закодированный в Base-64 корневой сертификат формата X.509(.CER) из сертификатов внутреннего сервера. В этом примере мы будем использовать сертификат TLS/SSL для внутреннего сертификата, экспортируем сначала открытый ключ этого сертификата, а затем корневой сертификат доверенного центра сертификации из открытого ключа в формате Base64, чтобы получить доверенный корневой сертификат. Промежуточные сертификаты должны быть объединены с сертификатом сервера и установлены на внутреннем сервере.

Чтобы экспортировать CER-файл для сертификата, сделайте следующее:

Выполните шаги 1–8 из предыдущего раздела , чтобы экспортировать открытый ключ из внутреннего сертификата.
Экспортировав открытый ключ, откройте файл.
Перейдите в представление «Путь сертификации», чтобы просмотреть центр сертификации.
Выберите корневой сертификат, а затем — Просмотр сертификата.

Вы должны увидеть сведения о корневом сертификате.
Перейдите в представление Сведения и нажмите кнопку Копировать в файл…
На этом этапе вы извлекли сведения о корневом сертификате из внутреннего сертификата. Откроется мастер экспорта сертификатов. Теперь выполните шаги 2–9 из раздела Экспорт сертификата проверки подлинности из внутреннего сертификата (для номера SKU версии 1) выше, чтобы экспортировать доверенный корневой сертификат в формате Base-64 с кодировкой X.509 (.CER).

Server variables

Application Gateway uses server variables to store useful information about the server, the connection with the client, and the current request on the connection. Examples of information stored include the client’s IP address and the web browser type. Server variables change dynamically, for example, when a new page loads or when a form is posted. You can use these variables to evaluate rewrite conditions and rewrite headers. In order to use the value of server variables to rewrite headers, you will need to specify these variables in the syntax {var_serverVariableName}

Application gateway supports the following server variables:

Variable name	Description
add_x_forwarded_for_proxy	The X-Forwarded-For client request header field with the variable (see explanation later in this table) appended to it in the format IP1, IP2, IP3, and so on. If the X-Forwarded-For field isn’t in the client request header, the variable is equal to the variable. This variable is particularly useful when you want to rewrite the X-Forwarded-For header set by Application Gateway so that the header contains only the IP address without the port information.
ciphers_supported	A list of the ciphers supported by the client.
ciphers_used	The string of ciphers used for an established TLS connection.
client_ip	The IP address of the client from which the application gateway received the request. If there’s a reverse proxy before the application gateway and the originating client, will return the IP address of the reverse proxy.
client_port	The client port.
client_tcp_rtt	Information about the client TCP connection. Available on systems that support the TCP_INFO socket option.
client_user	When HTTP authentication is used, the user name supplied for authentication.
host	In this order of precedence: the host name from the request line, the host name from the Host request header field, or the server name matching a request. Example: In the request , host value will be is
cookie_name	The name cookie.
http_method	The method used to make the URL request. For example, GET or POST.
http_status	The session status. For example, 200, 400, or 403.
http_version	The request protocol. Usually HTTP/1.0, HTTP/1.1, or HTTP/2.0.
query_string	The list of variable/value pairs that follows the «?» in the requested URL. Example: In the request , query_string value will be
received_bytes	The length of the request (including the request line, header, and request body).
request_query	The arguments in the request line.
request_scheme	The request scheme: http or https.
request_uri	The full original request URI (with arguments). Example: in the request , request_uri value will be
sent_bytes	The number of bytes sent to a client.
server_port	The port of the server that accepted a request.
ssl_connection_protocol	The protocol of an established TLS connection.
ssl_enabled	«On» if the connection operates in TLS mode. Otherwise, an empty string.
uri_path	Identifies the specific resource in the host that the web client wants to access. This is the part of the request URI without the arguments. Example: In the request , uri_path value will be

Mutual authentication server variables (Preview)

Application Gateway supports the following server variables for mutual authentication scenarios. Use these server variables the same way as above with the other server variables.

Variable name	Description
client_certificate	The client certificate in PEM format for an established SSL connection.
client_certificate_end_date	The end date of the client certificate.
client_certificate_fingerprint	The SHA1 fingerprint of the client certificate for an established SSL connection.
client_certificate_issuer	The «issuer DN» string of the client certificate for an established SSL connection.
client_certificate_serial	The serial number of the client certificate for an established SSL connection.
client_certificate_start_date	The start date of the client certificate.
client_certificate_subject	The «subject DN» string of the client certificate for an established SSL connection.
client_certificate_verification	The result of the client certificate verification: SUCCESS, FAILED:<reason>, or NONE if a certificate was not present.

End-to-end TLS with the v2 SKU

Authentication Certificates have been deprecated and replaced by Trusted Root Certificates in the Application Gateway v2 SKU. They function similarly to Authentication Certificates with a few key differences:

Certificates signed by well known CA authorities whose CN matches the host name in the HTTP backend settings do not require any additional step for end to end TLS to work.
For example, if the backend certificates are issued by a well known CA and has a CN of contoso.com, and the backend http setting’s host field is also set to contoso.com, then no additional steps are required. You can set the backend http setting protocol to HTTPS and both the health probe and data path would be TLS enabled. If you’re using Azure App Service or other Azure web services as your backend, then these are implicitly trusted as well and no further steps are required for end to end TLS.

Note

In order for a TLS/SSL certificate to be trusted, that certificate of the backend server must have been issued by a CA that is well-known. If the certificate was not issued by a trusted CA, the application gateway will then check to see if the certificate of the issuing CA was issued by a trusted CA, and so on until either a trusted CA is found (at which point a trusted, secure connection will be established) or no trusted CA can be found (at which point the application gateway will mark the backend unhealthy). Therefore, it is recommended the backend server certificate contain both the root and intermediate CAs.

If the backend server certificate is self-signed, or signed by unknown CA/intermediaries, then to enable end to end TLS in Application Gateway v2 a trusted root certificate must be uploaded. Application Gateway will only communicate with backends whose server certificate’s root certificate matches one of the list of trusted root certificates in the backend http setting associated with the pool.
In addition to the root certificate match, Application Gateway v2 also validates if the Host setting specified in the backend http setting matches that of the common name (CN) presented by the backend server’s TLS/SSL certificate. When trying to establish a TLS connection to the backend, Application Gateway v2 sets the Server Name Indication (SNI) extension to the Host specified in the backend http setting.
If pick hostname from backend target is chosen instead of the Host field in the backend http setting, then the SNI header is always set to the backend pool FQDN and the CN on the backend server TLS/SSL certificate must match its FQDN. Backend pool members with IPs aren’t supported in this scenario.
The root certificate is a base64 encoded root certificate from the backend server certificates.

Часто задаваемые вопросы

Переведет ли скрипт Azure PowerShell трафик со шлюза версии 1 на новый шлюз версии 2?

Нет. Скрипт Azure PowerShell только переносит конфигурацию. За фактическую миграция трафика отвечаете вы, и она осуществляется под вашим полным контролем.

Поддерживает ли этот скрипт сертификаты, отправленные в Azure KeyVault?

Нет. В настоящее время скрипт не поддерживает сертификаты в KeyVault. Однако такая возможность может быть реализована в будущих версиях.

При использовании этого скрипта возникли проблемы. Где можно получить помощь?

Вы можете обратиться в службу поддержки Azure в разделе «Конфигурация и настройка/переход на SKU версии 2». Дополнительные сведения о поддержке Azure см. здесь.

Проблемы со стандартной пробой работоспособности

Причина

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

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

В таблице приведены значения, связанные со стандартной пробой работоспособности:

Свойства проверки	Значение	Описание
URL-адрес проверки		URL-адрес
Интервал	30	Интервал проверки в секундах
Время ожидания	30	Время ожидания проверки в секундах
Пороговое значение сбоя	3	Количество повторных попыток проверки. Сервер внутреннего пула считается неисправным, когда количество повторных неудачных попыток проверки достигает порогового значения сбоя.

Решение

Убедитесь, что стандартный сайт настроен и ожидает передачи данных по адресу 127.0.0.1.
Если в параметре BackendHttpSetting задан порт, отличный от 80, на стандартном сайте нужно настроить ожидание передачи данных через этот порт.
Вызов к должен вернуть код результата HTTP 200. Необходимо вернуть в течении 30-секундного периода ожидания.
Убедитесь, что настроенный порт открыт и в нем нет правил брандмауэра и группы безопасности сети Azure, которые блокируют входящий или исходящий трафик через настроенный порт.
Если классические виртуальные машины Azure или облачная служба используются с полным доменным именем или общедоступным IP-адресом, откройте соответствующую конечную точку.
Если виртуальная машина настроена с помощью Azure Resource Manager и находится за пределами виртуальной сети, в которой развернут шлюз приложений, настройте в группе безопасности сети доступ через нужный порт.

Обновление привязки сертификата

Примечание

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

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

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

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

Очистка ресурсов

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

Чтобы удалить группу ресурсов:

На портале Azure в меню слева выберите Группы ресурсов.
На странице Группы ресурсов выполните поиск группы myResourceGroupAG в списке и выберите ее.
На странице группы ресурсов выберите Удалить группу ресурсов.
Введите myResourceGroupAG в поле Введите имя группы ресурсов, а затем выберите Удалить.

Чтобы восстановить файл hosts, сделайте следующее:

Удалите строки и из файла hosts и запустите и из командной строки.

Добавление серверных целевых объектов

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

Для этого сделайте следующее:

Создайте две виртуальные машины (myVM и myVM2), которые будут использоваться в качестве внутренних серверов.
Установить службы IIS на виртуальных машинах, чтобы убедиться, что шлюз приложений успешно создан.
Добавить внутренние серверы к внутренним пулам.

Создание виртуальной машины

На портале Azure выберите Создать ресурс. Появится окно Создать.
Выберите Windows Server 2016 Datacenter в списке Популярные. Появится страница Создание виртуальной машины.

Шлюз приложений может осуществлять маршрутизацию трафика для любого типа виртуальной машины, используемой в этом внутреннем пуле. В этом примере используется Windows Server 2016 Datacenter.
На вкладке Основы введите для следующих параметров виртуальной машины такие значения:
- Группа ресурсов. Выберите myResourceGroupAG для имени группы ресурсов.
- Имя виртуальной машины. Введите myVM для имени виртуальной машины.
- Имя пользователя. Введите имя пользователя для учетной записи администратора.
- Пароль. Введите пароль для учетной записи администратора.
Примите остальные значения по умолчанию и щелкните Далее: Диски.
Примите значения по умолчанию на вкладке Диски, а затем выберите Далее: Сети.
На вкладке Сети убедитесь, что для параметра Виртуальная сеть выбрано значение myVNet, а для параметра Подсеть — значение myBackendSubnet. Примите остальные значения по умолчанию и щелкните Далее: управление.

Шлюз приложений может взаимодействовать с экземплярами за пределами виртуальной сети, к которой он относится, при наличии подключения по IP-адресу.
На вкладке Управление для параметра Диагностика загрузки задайте значение Отключить. Примите другие значения по умолчанию и выберите Review + create (Просмотр и создание).
На вкладке Review + create (Просмотр и создание) проверьте параметры, устраните ошибки проверки, а затем выберите Создать.
Дождитесь завершения развертывания, прежде чем продолжить.

Установка служб IIS для тестирования

В этом примере службы IIS устанавливаются на виртуальные машины, чтобы проверить, создан ли шлюз приложений в Azure.

Откройте Azure PowerShell. Для этого выберите Cloud Shell в верхней панели навигации портала Azure, а затем выберите PowerShell из раскрывающегося списка.
Измените параметр расположения для своей среды, а затем выполните следующую команду, чтобы установить службы IIS на виртуальной машине:
Создайте вторую виртуальную машину и установите IIS, следуя только что выполненным инструкциям. Используйте myVM2 в качестве имени виртуальной машины и параметр VMName для командлета Set-AzVMExtension.

Добавление серверов во внутренние пулы

Выберите Все ресурсы, а затем — myAppGateway.
Выберите Серверные пулы в меню слева.
Выберите myBackendPool.
В разделе Тип цели выберите Виртуальная машина из раскрывающегося списка.
В разделе Цель выберите сетевой интерфейс из раскрывающегося списка myVM.
Повторите эту процедуру, чтобы добавить сетевой интерфейс для myVM2.
Щелкните Сохранить.
Прежде чем переходить к следующему шагу, дождитесь завершения развертывания.

Состояние работоспособности серверной части: Unknown

Если состояние работоспособности серверной части — Unknown, то портал будет выглядеть как на снимке экрана ниже.

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

Группа безопасности сети в подсети Шлюза приложений блокирует входящий доступ из Интернета к портам 65503–65534 (номер SKU версии 1) или 65200–65535 (SKU версии 2).
Для UDR в подсети Шлюза приложений задан маршрут по умолчанию (0.0.0.0/0), а для следующего прыжка не указано значение «Internet» (Интернет).
Маршрут по умолчанию объявляется подключением ExpressRoute или VPN к виртуальной сети по протоколу BGP.
Пользовательский DNS-сервер настроен в виртуальной сети, которая не может разрешать общедоступные доменные имена.
Шлюз приложения находится в состоянии Unhealthy.

Решение.

Проверьте, не блокирует ли группа безопасности сети доступ из Интернета к портам 65503–65534 (номер SKU версии 1) или 65200–65535 (SKU версии 2).

а. На вкладке Обзор Шлюза приложений выберите ссылку Виртуальная сеть и подсеть.

b. На вкладке Подсети виртуальной сети выберите подсеть, в которой развернут Шлюз приложений.

c. Проверьте, настроены ли какие-либо группы безопасности сети.

d. Если группа безопасности сети настроена, найдите ее ресурс на вкладке Поиск или в разделе Все ресурсы.

д) В разделе Inbound Rules (Правила для входящего трафика) добавьте правило для входящего трафика, чтобы разрешить диапазон портов назначения 65503–65534 (для SKU версии 1) или 65200–65535 (для SKU версии 2), задав для параметра Source (Источник) значение Any (Любой) или Internet (Интернет).

е) Выберите Сохранить и убедитесь, что серверная часть отображается в состоянии Healthy. Кроме того, это можно сделать с помощью PowerShell или интерфейса командной строки.
Проверьте, задал ли для UDR маршрут по умолчанию (0.0.0.0/0) со следующим прыжком, отличным от Internet (Интернет).

а. Выполните шаги 1a и 1b, чтобы определить подсеть.

b. Проверьте, настроены ли UDR. Если это так, выполните поиск соответствующего ресурса на панели поиска или в разделе Все ресурсы.

c. Проверьте наличие маршрутов по умолчанию (0.0.0.0/0) со следующим прыжком, отличным от Internet (Интернет). Если параметр имеет значение Virtual Appliance (Виртуальное устройство) или Virtual Network Gateway (Шлюз виртуальной сети), необходимо убедиться, что виртуальное устройство или локальное устройство может правильно переслать пакет обратно в назначение в Интернете, не изменяя этот пакет.

d. В противном случае измените следующий прыжок на Internet (Интернет), выберите Сохранить и проверьте работоспособность серверной части.
Маршрут по умолчанию объявляется подключением ExpressRoute или VPN к виртуальной сети по протоколу BGP.

а. При наличии подключения ExpressRoute или VPN к виртуальной сети по протоколу BGP и объявлении маршрута по умолчанию необходимо убедиться, что пакет пересылается обратно в Интернет и не изменяется. Проверить это можно с помощью параметра Устранение неполадок с подключением на портале Шлюза приложений.

b. Выберите назначение вручную, указав любой IP-адрес, поддерживающий маршрутизацию в Интернете, например 1.1.1.1. Задайте любой порт назначения и проверьте подключение.

c. Если следующим прыжком является шлюз виртуальной сети, то может существовать маршрут по умолчанию, объявленный через подключение ExpressRoute или VPN.
Если в виртуальной сети задан настраиваемый DNS-сервер, убедитесь, что этот сервер (или серверы) может разрешать общедоступные домены. Разрешение общедоступных доменных имен может потребоваться в случаях, когда Шлюз приложений должен взаимодействовать с внешними доменами, например серверами OCSP, или проверять состояние отзыва сертификата
Чтобы убедиться, что Шлюз приложений работоспособен и выполняется, перейдите к параметру Работоспособность ресурсов на портале проверьте, отображается ли состояние Работоспособное. Если вы видите состояние Неработоспособно или Снижение производительности, обратитесь в службу поддержки.

Специальные рекомендации

Завершение сеансов TLS и использования сквозного режима TLS в службе с несколькими клиентами

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

Обратите внимание, что на приведенном выше рисунке не требуется добавлять сертификаты проверки подлинности, если в качестве серверной части выбрана Служба приложений

Проверка работоспособности

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

Сценарий перенаправления на URL-адрес Службы приложений

В некоторых сценариях имя узла в ответе Службы приложений может инициировать в браузере конечного пользователя перенаправление на имя узла *.azurewebsites.net, а не в домен, связанный со Шлюзом приложений. Эта проблема может возникать в следующих случаях:

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

Сведения об устранении проблем в таких ситуациях см. в статье об устранении неполадок перенаправления на URL-адрес службы приложений.

Требования к закрытым сертификатам

И , и соответствуют требованиям Службы приложений. Если вы решили передать или импортировать закрытый сертификат в Службу приложений, то этот сертификат должен соответствовать следующим требованиям. Он:

должен быть экспортирован как , зашифрованный с помощью TRIPLE DES;
должен содержать закрытый ключ длиной не менее 2048 битов;
должен содержать все промежуточные сертификаты и корневой сертификат в цепочке сертификатов.

Чтобы защитить личный домен в привязке TLS, сертификат должен соответствовать дополнительным требованиям:

должен содержать данные для аутентификации сервера (OID = 1.3.6.1.5.5.7.3.1);
должен быть подписан доверенным центром сертификации;

Примечание

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

Команды

	Добавьте профили SSL шлюза приложений.
	Перечислите существующие профили SSL шлюза приложений.
	Удалите существующие профили SSL шлюза приложений.

az network application-gateway ssl-profile add

Изменить

Добавьте профили SSL шлюза приложений.

Добавьте профиль SSL для существующего шлюза приложений.

Обязательные параметры

—gateway-name

Имя шлюза приложений.

—name

Имя профиля SSL, уникального в пределах шлюза приложений.

—resource-group -g

Имя группы ресурсов. Вы можете настроить расположение по умолчанию с помощью .

—cipher-suites

Наборы шифров SSL, которые должны быть включены в шлюзе приложений в указанном порядке.

—client-auth-config —client-auth-configuration

Настройка проверки подлинности клиента для ресурса шлюза приложений.

допустимые значения: False, True

—disabled-protocols —disabled-ssl-protocols

Разделенный пробелами список протоколов для отключения.

—min-protocol-version

Минимальная версия протокола SSL для поддержки в шлюзе приложений.

—policy-name

Имя политики SSL.

—policy-type

Тип политики SSL.

допустимые значения: Custom, Predefined

—subscription

Имя или идентификатор подписки Вы можете настроить подписку по умолчанию с помощью .

—trusted-client-cert —trusted-client-certificates

Массив ссылок на сертификаты доверенного клиента шлюза приложений.

Глобальные параметры

—debug

Повышение уровня детализации журнала для включения всех журналов отладки.

—help -h

Отображение этого справочного сообщения и выход.

—only-show-errors

Показывать только ошибки, блокируя предупреждения.

—output -o

Формат вывода.

—query

Строка запроса JMESPath. Дополнительные сведения и примеры см. в разделе http://jmespath.org/.

—verbose

Повышение уровня детализации журнала. Чтобы включить полные журналы отладки, используйте параметр —debug.

az network application-gateway ssl-profile list

Изменить

Перечислите существующие профили SSL шлюза приложений.

Список всех профилей SSL для существующего шлюза приложений.

Обязательные параметры

—gateway-name

Имя шлюза приложений.

—resource-group -g

Имя группы ресурсов. Вы можете настроить расположение по умолчанию с помощью .

—query-examples

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

Глобальные параметры

—debug

Повышение уровня детализации журнала для включения всех журналов отладки.

—help -h

Отображение этого справочного сообщения и выход.

—only-show-errors

Показывать только ошибки, блокируя предупреждения.

—output -o

Формат вывода.

—query

Строка запроса JMESPath. Дополнительные сведения и примеры см. в разделе http://jmespath.org/.

—verbose

Повышение уровня детализации журнала. Чтобы включить полные журналы отладки, используйте параметр —debug.

Изменить

Удалите существующие профили SSL шлюза приложений.

Обязательные параметры

—gateway-name

Имя шлюза приложений.

—name

Имя профиля SSL, уникального в пределах шлюза приложений.

—resource-group -g

Имя группы ресурсов. Вы можете настроить расположение по умолчанию с помощью .

Application Gateway only

This design covers the situation where only web applications exist in the virtual network, and inspecting outbound traffic with NSGs is sufficient to protect outbound flows to the internet.

Note

This is not a recommended design since using Azure Firewall to control outbound flows (instead of only NSGs) will prevent certain attack scenarios such as data exfiltration, where you make sure that your workloads are only sending data to an approved list of URLs.

The main difference from the previous design with only the Azure Firewall is that the Application Gateway doesn’t act as a routing device with NAT. It behaves as a full reverse application proxy. That is, Application Gateway stops the web session from the client, and establishes a separate session with one of its backend servers. Inbound HTTP(S) connections from the Internet need to be sent to the public IP address of the Application Gateway, connections from Azure or on-premises to the private IP address. Return traffic from the Azure VMs will follow standard VNet routing back to the Application Gateway (see the packet walk further down for more details). Outbound internet flows from Azure VMs will go straight to the internet.

The following table summarizes traffic flows:

Flow	Goes through Application Gateway / WAF	Goes through Azure Firewall
HTTP(S) traffic from internet/onprem to Azure	Yes	N/A
HTTP(S) traffic from Azure to internet/onprem	No	N/A
Non-HTTP(S) traffic from internet/onprem to Azure	No	N/A
Non-HTTP(S) traffic from Azure to internet/onprem	No	N/A

The following packet walk example shows how a client accesses the VM-hosted application from the public internet.

The client starts the connection to the public IP address of the Azure Application Gateway:
- Source IP address: ClientPIP
- Destination IP address: AppGwPIP
The Application Gateway instance that receives the request stops the connection from the client, and establishes a new connection with one of the back ends. The back end sees the Application Gateway instance as the source IP address. The Application Gateway inserts an X-Forwarded-For HTTP header with the original client IP address.
- Source IP address: 192.168.200.7 (the private IP address of the Application Gateway instance)
- Destination IP address: 192.168.1.4
- X-Forwarded-For header: ClientPIP
The VM answers the application request, reversing source and destination IP addresses. The VM already knows how to reach the Application Gateway, so doesn’t need a UDR.
- Source IP address: 192.168.1.4
- Destination IP address: 192.168.200.7
Finally, the Application Gateway instance answers the client:
- Source IP address: AppGwPIP
- Destination IP address: ClientPIP

Azure Application Gateway adds metadata to the packet HTTP headers, such as the X-Forwarded-For header containing the original client’s IP address. Some application servers need the source client IP address to serve geolocation-specific content, or for logging. For more information, see How an application gateway works.

The IP address is one of the instances the Azure Application Gateway service deploys under the covers, here with the front-end IP address . These individual instances are normally invisible to the Azure administrator. But noticing the difference is useful in some cases, such as when troubleshooting network issues.
The flow is similar if the client comes from an on-premises network over a VPN or ExpressRoute gateway. The difference is the client accesses the private IP address of the Application Gateway instead of the public address.

Проблемы с пользовательскими пробами работоспособности

Причина

Пользовательские пробы работоспособности более гибкие по сравнению со стандартными. Для пользовательских проб можно настроить интервал, URL-адрес и путь к ним (для тестирования), а также число неудачных откликов, после которых экземпляр внутреннего пула будет считаться неработоспособным.

Добавлены следующие дополнительные свойства.

Свойства проверки	Описание
Имя	Имя проверки. Это имя используется для указания проверки в параметрах HTTP внутреннего сервера
Протокол	Протокол, используемый для проверки. Проба использует протокол, определенный в параметрах HTTP серверной части.
Узел	Имя узла для проверки. Применяется только в случае, если в шлюзе приложений настроено многосайтовое подключение. (То есть указывается не имя узла виртуальной машины.)
путь	Относительный путь проверки. Путь должен начинаться с «/». Проба отправляется в <protocol>://<host>:<port><path>
Интервал	Интервал проверки в секундах. Интервал времени между двумя последовательными проверками.
Время ожидания	Время ожидания проверки в секундах. Если ответ о работоспособности не получен в течение этого времени ожидания, то проба считается неудачной.
Пороговое значение сбоя	Количество повторных попыток проверки. Сервер внутреннего пула считается неисправным, когда количество повторных неудачных попыток проверки достигает порогового значения сбоя.

Решение

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

проба указана правильно, согласно руководству;
Если шлюз приложений настроен для одного сайта, нужно указать стандартное имя узла , если в пользовательской пробе не задано другое имя.
Убедитесь, что вызов http://<host>:<port><path> возвращает HTTP-код результата 200.
Убедитесь, что значения «Интервал», «Время ожидания» и «Порог работоспособности» находятся в допустимом диапазоне.
При использовании зонда HTTPS убедитесь, что внутренний сервер не требует SNI путем настройки резервного сертификата.

Create a server certificate

Next, you’ll create a server certificate using OpenSSL.

Create the CSR (Certificate Signing Request)

The CSR is a public key that is given to a CA when requesting a certificate. The CA issues the certificate for this specific request.

Note

The CN (Common Name) for the server certificate must be different from the issuer’s domain. For example, in this case, the CN for the issuer is and the server certificate’s CN is .

Use the following command to generate the CSR:
When prompted, type the password for the root key, and the organizational information for the custom CA: Country/Region, State, Org, OU, and the fully qualified domain name. This is the domain of the website and it should be different from the issuer.

Verify the newly created certificate

Use the following command to print the output of the CRT file and verify its content:
Verify the files in your directory, and ensure you have the following files:
- contoso.crt
- contoso.key
- fabrikam.crt
- fabrikam.key

Prerequisites

Use the Bash environment in Azure Cloud Shell.
If you prefer, install the Azure CLI to run CLI reference commands.
- If you’re using a local installation, sign in to the Azure CLI by using the command. To finish the authentication process, follow the steps displayed in your terminal. For additional sign-in options, see Sign in with the Azure CLI.
- When you’re prompted, install Azure CLI extensions on first use. For more information about extensions, see Use extensions with the Azure CLI.
- Run to find the version and dependent libraries that are installed. To upgrade to the latest version, run .

This tutorial requires version 2.0.4 or later of the Azure CLI. If using Azure Cloud Shell, the latest version is already installed.

TLS från end-to-end med v1-SKU:n

Om du vill aktivera TLS från end-to-end till backend-servrarna och för Application Gateway att dirigera begäranden till dem, måste hälsoavsökningarna lyckas och returnera felfritt svar.

För HTTPS-hälsoavsökningar använder SKU:n Application Gateway v1 en exakt matchning av autentiseringscertifikatet (offentlig nyckel för servercertifikatet och inte rotcertifikatet) som ska överföras till HTTP-inställningarna.

Endast anslutningar till kända och tillåtna backends tillåts sedan. De återstående backends betraktas som felaktiga av hälsoavsökningarna. Självsignerade certifikat är enbart för testningsändamål och rekommenderas inte för produktions-arbetsbelastningar. Sådana certifikat måste tillåtas i listan med programgatewayen enligt beskrivningen i föregående steg innan de kan användas.

Anteckning

Autentisering och konfiguration av betrott rotcertifikat krävs inte för betrodda Azure-tjänster, till exempel Azure App Service. De anses vara betrodda som standard.