Поделиться через

Известные проблемы и ограничения брандмауэра Azure

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

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

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

Текущие ограничения емкости

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

Регион или зоны Артикул (SKU) Ограничения Рекомендация
Физическая зона 1 и зона 4 в восточной части США 2 EUAP Базовый, Стандартный и Премиум — Невозможно развернуть новый брандмауэр Azure в зоне 1 и зоне 4. Рекомендуется развернуть новую Брандмауэр Azure в оставшихся зонах доступности или использовать другой регион. Сведения о настройке существующего брандмауэра см. в статье "Как настроить зоны доступности после развертывания?"
- Физическая зона 2 в Северной Европе
в - Юго-Восточной Азии		 "Стандартный" и "Премиум" — Вы не можете развернуть новую Брандмауэр Azure в зоне 3 в Юго-Восточной Азии или зоне 2 в Северной Европе.

— Если остановить существующий Брандмауэр Azure, развернутый в этой зоне, его нельзя перезапустить.

Дополнительные сведения см. в разделе "Физические и логические зоны доступности".		 Рекомендуется развернуть новую Брандмауэр Azure в оставшихся зонах доступности или использовать другой регион. Сведения о настройке существующего брандмауэра см. в статье "Как настроить зоны доступности после развертывания?"
Физическая зона 3 в южной части США Базовый, Стандартный и Премиум — Невозможно развернуть новый брандмауэр Azure в зоне 3.

Предполагаемая дата доступности: 31 марта 2026		 Рекомендуется развернуть новую Брандмауэр Azure в оставшихся зонах доступности или использовать другой регион. Сведения о настройке существующего брандмауэра см. в статье "Как настроить зоны доступности после развертывания?"
Физическая зона 2 в Центральной Испании Базовый, Стандартный и Премиум — Невозможно развернуть новый брандмауэр Azure в зоне 2.

Предполагаемая дата: 31 декабря 2026 г.		 Рекомендуется развернуть новую Брандмауэр Azure в оставшихся зонах доступности или использовать другой регион. Сведения о настройке существующего брандмауэра см. в статье "Как настроить зоны доступности после развертывания?"
Правительство США Вирджиния Премия — В регионе «US Gov Virginia» нет доступных ресурсов для SKU Azure Firewall уровня Premium, а зональные и незональные развертывания блокируются. Разверните SKU брандмауэра Azure Стандартный или разверните SKU Премиум в другом регионе.
Физическая зона 3 в Вирджиния правительство США "Базовый" и "Стандартный" - Зональные развертывания блокируются в физической зоне 3 в правительстве США, Вирджиния.

— Необходимо вручную выбрать доступные зоны для успешного развертывания, что приводит к неоптимальному процессу развертывания.		 Выберите зоны 1 и 2 для зональных развертываний или используйте другой регион.
Физическая зона 2 в западной части США 2 Базовый, Стандартный и Премиум — Невозможно развернуть новый брандмауэр Azure в зоне 2. Рекомендуется развернуть новую Брандмауэр Azure в оставшихся зонах доступности или использовать другой регион. Сведения о настройке существующего брандмауэра см. в статье "Как настроить зоны доступности после развертывания?"

Предупреждение

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

Известные проблемы с брандмауэром Azure уровня "Стандартный"

Ниже описаны известные проблемы в Брандмауэре Azure уровня "Стандартный".

Проблема Описание Меры по снижению риска
Поддержка DNAT для частных IP-адресов, ограниченная версиями Standard и Premium Поддержка DNAT в частном IP-адресе брандмауэра Azure доступна только в версиях брандмауэра уровня "Стандартный" и "Премиум", а не в базовой версии. нет
При настройке правил DNAT для частных IP-адресов не поддерживается размещение и выделение ресурсов брандмауэра Azure. Процесс распределения ресурсов брандмауэра Azure завершается неудачно при конфигурации частных правил DNAT. 1. Деаллокация брандмауэра Azure
2. Удалите все правила DNAT для частного IP-адреса
. Выделите брандмауэр Azure и подождите
, пока не заполнится приватный IP-адрес. Перенастройте правила DNAT для частного IP с соответствующим частным IP-адресом.
Правила сетевой фильтрации для протоколов, которые отличаются от TCP или UDP (например, ICMP), не работают для трафика, связанного с Интернетом Правила сетевой фильтрации для протоколов, которые отличаются от TCP или UDP, не работают со SNAT для общедоступных IP-адресов. Протоколы, отличные от TCP/UDP, поддерживаются между подсетями-спицами и виртуальными сетями (VNets). Брандмауэр Azure использует стандартный Load Balancer, который в настоящее время не поддерживает SNAT для IP-протоколов. Мы изучаем варианты поддержки протоколов, отличных от TCP/UDP, для связанного с Интернетом трафика в будущем выпуске.
При освобождении брандмауэра Azure и повторном выделении его может быть назначен новый частный IP-адрес. После процесса освобождения и выделения адресов для брандмауэра Azure частный IP-адрес назначается динамически из подсети брандмауэра Azure. При назначении нового частного IP-адреса, отличающегося от предыдущего, это приводит к проблемам маршрутизации. Необходимо перенастроить существующие определяемые пользователем маршруты (UDR) с новым частным IP-адресом. Исправление изучается, чтобы сохранить частный IP-адрес после процесса выделения.
Дочерние политики брандмауэра не наследуют параметры DNS от родительских политик. При изменении параметров DNS в родительской политике брандмауэра дочерние политики, связанные с ней, могут не разрешать доменные имена в своих правилах. Настройте настройки DNS непосредственно в каждой дочерней политике, вместо того чтобы полагаться на родительскую политику. Мы работаем над исправлением, чтобы разрешить наследование параметров DNS.
В PowerShell и CLI отсутствует поддержка протокола ICMP Azure PowerShell и CLI не поддерживают ICMP как допустимый протокол в правилах сети. Протокол ICMP по-прежнему можно использовать с помощью портала и REST API. Мы добавим поддержку ICMP в PowerShell и CLI в ближайшее время.
Для тегов FQDN требуется указать протокол и порт. Для правил приложений с тегами FQDN требуется указать определение порта и протокола. В качестве значения протокола порта можно использовать HTTPS. Мы работаем над тем, чтобы сделать поле «порт: протокол» необязательным при использовании тегов FQDN.
Не поддерживается перемещение брандмауэра в другую группу ресурсов или подписку Не поддерживается перемещение брандмауэра в другую группу ресурсов или подписку. Поддержка этой функции реализована в нашей стратегии. Чтобы переместить брандмауэр в другую группу ресурсов или подписку, нужно удалить текущий экземпляр и повторно создать его в новой группе ресурсов или подписке.
Оповещения об угрозах могут быть маскированы Правила сети с направлением на порт 80/443 для исходящей фильтрации маскируют предупреждения аналитики угроз, когда они настроены на режим только уведомления. С помощью правил приложения создайте фильтрацию исходящего трафика для порта 80/443. Или измените режим аналитики угроз на Alert and Deny (Оповещение и отказ).
С защищенными виртуальными центрами зоны доступности можно настроить только во время развертывания. Невозможно настроить Зоны доступности после развертывания брандмауэра с защищенными виртуальными концентраторами. По замыслу.
SNAT на входящих соединениях Правила DNAT для входящего трафика всегда изменяют исходный IP-адрес для возвращаемого трафика. Чтобы отслеживать исходный IP-адрес клиента для веб-трафика, настройте клиенты или прокси-серверы, чтобы включить исходный IP-адрес в заголовки XFF . Брандмауэр Azure сохраняет эти IP-адреса в заголовке XFF и добавляет IP-адрес брандмауэра в заголовок XFF при обработке правил веб-трафика.
Поддержка фильтрации SQL FQDN только в режиме прокси-сервера (порт 1433) Для Базы данных SQL Azure, Azure Synapse Analytics и Управляемого экземпляра SQL Azure:

Фильтрация SQL FQDN поддерживается только в прокси-режиме (порт 1433).

Для Azure SQL IaaS:

Если вы используете нестандартные порты, можно указать эти порты в правилах приложения.		 Для SQL в режиме перенаправления (по умолчанию используется для подключения из Azure) можно фильтровать доступ с помощью тега службы SQL в правилах сети Брандмауэра Azure.
Исходящий трафик через TCP-порт 25 блокируется Платформа Azure блокирует исходящие сообщения электронной почты, отправленные непосредственно внешним доменам (например outlook.com , и gmail.com) через TCP-порт 25. Блокировка исходящего трафика SMTP через порт 25 — это поведение платформы по умолчанию в Azure. Брандмауэр Azure не вводит более конкретное ограничение. Используйте прошедшие проверку подлинности службы ретрансляции, которые обычно подключаются через TCP-порт 587, но также поддерживают и другие порты. Подробные сведения см. в статье Устранение проблем с исходящими SMTP-подключениями в Azure.

Другим вариантом является развертывание брандмауэра Azure в стандартной корпоративной подписке (EA). Брандмауэр Azure в подписке EA может взаимодействовать с общедоступными IP-адресами с помощью исходящего TCP-порта 25. Он может работать в других типах подписок, но не гарантируется. Для частных IP-адресов, таких как виртуальные сети, VPN и Azure ExpressRoute, Брандмауэр Azure поддерживает исходящее подключение через TCP-порт 25.
Нехватка портов SNAT Брандмауэр Azure в настоящее время поддерживает 2496 портов на публичный IP-адрес для каждого экземпляра набора виртуальных машин типа back-end. По умолчанию существует два экземпляра масштабируемого набора виртуальных машин. Таким образом, на поток приходится 4992 порта (конечный IP-адрес, порт назначения и протокол (TCP или UDP). Брандмауэр масштабируется до максимума 20 инстанций. Исчерпание портов SNAT является ограничением платформы. Вы можете обойти эти ограничения, указав минимум пять общедоступных IP-адресов для развертываний Брандмауэра Azure, в которых может возникнуть проблема нехватки SNAT. Добавление дополнительных общедоступных IP-адресов увеличивает количество портов SNAT, доступных в пять раз. Используйте выделение из префикса IP-адреса, чтобы упростить последующие разрешения. В качестве более постоянного решения можно развернуть шлюз NAT, чтобы преодолеть ограничения на количество портов SNAT. Развертывание шлюза NAT поддерживается для развертываний виртуальной сети.

Дополнительные сведения см. в статье Масштабирование портов SNAT с помощью NAT виртуальных сетей Azure.
DNAT не поддерживается при включенном принудительном туннелировании Брандмауэры, развернутые с включенным принудительным туннелированием, не поддерживают входящий трафик из Интернета из-за асимметричной маршрутизации. Отсутствие поддержки DNAT при принудительном туннелировании запланировано из-за асимметричной маршрутизации. Путь возврата для входящих подключений проходит через локальный брандмауэр, который не видит установленного подключения.
Исходящий пассивный FTP может не работать для брандмауэров с несколькими общедоступными IP-адресами в зависимости от конфигурации FTP-сервера. Пассивный FTP устанавливает разные подключения для каналов управления и данных. Когда брандмауэр с несколькими общедоступными IP-адресами отправляет данные для исходящего трафика, он случайным образом выбирает один из общедоступных IP-адресов в качестве исходного. FTP может завершиться ошибкой, если каналы управления и обмена данными используют разные исходные IP-адреса, в зависимости от конфигурации FTP-сервера. Запланирована явная конфигурация SNAT. Тем временем можно настроить FTP-сервер так, чтобы он принимал каналы данных и управления с разных исходных IP-адресов (см. пример для IIS). Кроме того, при возникновении проблем с подключением FTP рекомендуется использовать один IP-адрес.
Входящий пассивный FTP может не работать в зависимости от конфигурации FTP-сервера Пассивный FTP устанавливает разные подключения для каналов управления и данных. Входящие подключения в Брандмауэре Azure используют механизм SNAT для одного из частных IP-адресов брандмауэра, чтобы обеспечить симметричную маршрутизацию. FTP может завершиться ошибкой, если каналы управления и обмена данными используют разные исходные IP-адреса, в зависимости от конфигурации FTP-сервера. Сохранение исходного IP-адреса источника изучается. Тем временем можно настроить FTP-сервер так, чтобы он принимал каналы данных и управления с разных исходных IP-адресов.
Активный FTP не работает, когда FTP-клиент должен обратиться к FTP-серверу через Интернет. Активный FTP использует команду PORT из FTP-клиента, который указывает FTP-серверу, какой IP и порт использовать для канала передачи данных. Команда PORT использует частный IP-адрес клиента, который не может быть изменен. Трафик на стороне клиента, проходящий через Брандмауэр Azure, подвергается преобразованию с использованием NAT для интернет-коммуникаций, в результате чего команда PORT считается недопустимой FTP-сервером. Сбой Active FTP — это основное ограничение Active FTP при использовании с NAT на стороне клиента.
В метрике NetworkRuleHit отсутствует измерение протокола Метрика ApplicationRuleHit разрешает протокол на основе фильтрации, но этот компонент отсутствует в соответствующей метрике NetworkRuleHit. Соответствующее исправление рассматривается.
Правила NAT с портами в диапазоне от 64000 до 65535 не поддерживаются Брандмауэр Azure разрешает порты в диапазоне 1–65535 в правилах сети и приложений, но правила NAT поддерживают порты только в диапазоне 1–63999. Ограничение портов правил NAT является текущим ограничением.
Обновления конфигурации могут занять пять минут в среднем Для обновления конфигурации брандмауэра Azure в среднем может потребоваться 3–5 минут. Параллельные обновления не поддерживаются. Соответствующее исправление рассматривается.
Брандмауэр Azure использует заголовки TLS на основе SNI для фильтрации трафика HTTPS и MSSQL Если программное обеспечение браузера или сервера не поддерживает расширение указания имени сервера (SNI), вы не сможете подключиться через Брандмауэр Azure. Если браузер или серверное программное обеспечение не поддерживает SNI, возможно, вы сможете управлять подключением с помощью сетевого правила вместо правила приложения. См. Индикатор имени сервера для программного обеспечения, поддерживающего SNI.
Не удается добавить теги политики брандмауэра с помощью портала или шаблонов Azure Resource Manager (ARM) Для политики Брандмауэра Azure действует ограничение на поддержку исправлений, которое не позволяет добавить тег с помощью портала Azure или шаблонов ARM. Следующая ошибка возникает: не удалось сохранить теги для ресурса. Соответствующее исправление рассматривается. Либо можно использовать командлет Azure PowerShell Set-AzFirewallPolicy для обновления тегов.
IPv6 в настоящее время не поддерживается При добавлении IPv6-адреса к правилу происходит сбой брандмауэра. Используйте только IPv4-адреса. Поддержка IPv6 находится на стадии изучения.
Удаление групп RuleCollectionGroup с использованием шаблонов ARM не поддерживается. Удаление RuleCollectionGroup с помощью шаблонов ARM не поддерживается и приводит к сбою. Удаление RuleCollectionGroups с помощью шаблонов ARM не поддерживается.
Правило DNAT для разрешения любого (*) будет выполнять SNAT для трафика. Если правило DNAT разрешает любой (*) в качестве исходного IP-адреса, то неявное сетевое правило будет соответствовать трафику VNet-VNet и всегда будет выполнять SNAT для этого трафика. Автоматическое поведение SNAT для правил DNAT с любым источником является текущим ограничением.
Добавление правила DNAT в защищенный виртуальный концентратор с провайдером безопасности не поддерживается. При добавлении правила DNAT в защищенный виртуальный концентратор с поставщиком безопасности он приводит к асинхронной маршрутизации для возвращаемого трафика DNAT, который передается поставщику безопасности. Не поддерживается.
Ошибка при создании более чем 2000 коллекций правил. Максимальное число коллекций сетевых правил или правил NAT/приложений составляет 2000 (ограничение Resource Manager). Текущее ограничение — предел в 2000 правил для коллекции.
Не удается развернуть брандмауэр с Зонами доступности, используя только что созданный общедоступный IP-адрес При развертывании брандмауэра с Зонами доступности нельзя использовать только что созданный общедоступный IP-адрес. Сначала создайте новый избыточный между зонами общедоступный IP-адрес, а затем назначьте этот ранее созданный IP-адрес во время развертывания брандмауэра.
Связывание общедоступного IP-адреса с брандмауэром Azure не поддерживается в сценарии с несколькими клиентами. Если вы создаете общедоступный IP-адрес в клиенте A, вы не можете связать его с брандмауэром, развернутным в клиенте B. Нет.
Виртуальные машины, стоящие за брандмауэром Azure, не могут подключаться к назначениям правил DNAT с помощью общедоступного IP-адреса брандмауэра. Когда виртуальные машины направляют трафик через Azure Firewall и пытаются подключиться к ресурсам, настроенным правилами DNAT, используя публичный IP-адрес брандмауэра, соединение не осуществляется. Сбой подключения возникает, так как брандмауэр Azure не поддерживает закрепление трафика от внутренних виртуальных машин к собственному общедоступному IP-адресу брандмауэра для назначений правил DNAT. Решение для этого ограничения в настоящее время находится в разработке.

Известные проблемы с Брандмауэром Azure Premium

Примечание.

Любая проблема, которая относится к уровню "Стандартный", также применяется к уровню "Премиум".

Ниже описаны известные проблемы в Брандмауэре Azure уровня "Премиум".

Проблема Описание Меры по снижению риска
Поддержка ESNI для разрешения FQDN в HTTPS Зашифрованный SNI не поддерживается в процессе HTTPS рукопожатия. Сейчас только Firefox поддерживает ESNI через пользовательскую конфигурацию. Рекомендуемое решение — отключить функцию ESNI.
Проверка подлинности клиентских сертификатов не поддерживается Клиентские сертификаты используются для создания взаимного отношения доверия между клиентом и сервером. Сертификаты клиентов используются во время согласования TLS. Брандмауэр Azure повторно согласовывает соединение с сервером и не имеет доступа к закрытому ключу сертификатов клиентов. нет
QUIC/HTTP3 QUIC — это новая основная версия протокола HTTP. Это UDP-протокол, использующий порты 80 (PLAN) и 443 (SSL). Проверка FQDN/URL/TLS не поддерживается. Настройте передачу UDP 80/443 в качестве правил сети.
Сертификаты, подписанные недоверенным клиентом Брандмауэр не доверяет подписанным клиентом сертификатам, когда он получает их от веб-сервера на основе интрасети. Соответствующее исправление рассматривается.
IDPS отображает неправильный исходный IP-адрес для оповещений HTTP без проверки TLS При создании оповещений для HTTP-трафика без шифрования к общедоступным IP-адресам, он отображает внутренний IP-адрес вместо исходного IP-адреса источника. Соответствующее исправление рассматривается.
Распространение сертификатов После применения сертификата ЦС на брандмауэре может потребоваться от 5 до 10 минут, прежде чем сертификат вступит в силу. Соответствующее исправление рассматривается.
Поддержка TLS 1.3 Протокол TLS 1.3 поддерживается частично. Туннель TLS от клиента к брандмауэру основан на TLS 1.2, а от брандмауэра к внешнему веб-серверу — на TLS 1.3. Обновления сейчас рассматриваются.
Срок действия промежуточного сертификата удостоверяющего центра TLSi истекает. В некоторых уникальных случаях срок действия промежуточного сертификата ЦС может истекти через два месяца до первоначальной даты окончания срока действия. Обновите промежуточный сертификат ЦС за два месяца до первоначальной даты окончания срока действия. Соответствующее исправление рассматривается.

Следующие шаги

  • Last updated on