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

Azure Firewall известные проблемы и ограничения

Сводка

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

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

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

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

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

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

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

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

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

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

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

Предполагаемая дата доступности: 31 декабря 2026 года.		 Разверните новый брандмауэр Azure в другом регионе.

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

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

Azure Firewall известные проблемы версии "Стандарт"

Azure Стандартный Firewall имеет следующие известные проблемы:

Проблема Описание Смягчение последствий
Поддержка DNAT для частных IP-адресов, ограниченная версиями Standard и Premium Поддержка DNAT для частных IP-адресов Azure Firewall доступна только в версиях брандмауэра "Стандарт" и "Премиум", а не в базовой версии. Нет
Процессы деактивации и активации Azure Firewall не поддерживаются, если настроены правила DNAT для частных IP-адресов. Процесс выделения Azure Firewall завершается сбоем при настройке частных правил DNAT 1. Освободить Azure Firewall
2. Удалите все правила DNAT для частного IP-адреса
. Выделите Azure Firewall и дождитесь получения частного IP-адреса
4. Перенастройте правила DNAT для частного IP с соответствующим частным IP-адресом.
Правила сетевой фильтрации для протоколов, которые отличаются от TCP или UDP (например, ICMP), не работают для трафика, связанного с Интернетом Правила сетевой фильтрации для протоколов, которые отличаются от TCP или UDP, не работают со SNAT для общедоступных IP-адресов. Протоколы, отличные от TCP/UDP, поддерживаются между подсетями-спицами и виртуальными сетями (VNets). Azure Firewall использует Standard Load Balancer, который в настоящее время не поддерживает SNAT для IP-протоколов. Мы изучаем варианты поддержки протоколов, отличных от TCP/UDP, для связанного с Интернетом трафика в будущем выпуске.
При деактивации Azure Firewall и повторной активации ему может быть назначен новый частный IP-адрес. После процесса деаллокации и аллокации Azure Firewall IP-адрес частный назначается динамически из подсети Azure Firewall. При назначении нового частного 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 (Оповещение и отказ).
С защищенными виртуальными центрами зоны доступности можно настроить только во время развертывания. Невозможно настроить Availability Zones после развертывания брандмауэра с защищенными виртуальными центрами. По замыслу.
SNAT на входящих соединениях Правила DNAT для входящего трафика всегда изменяют исходный IP-адрес для возвращаемого трафика. Чтобы отслеживать исходный IP-адрес клиента для веб-трафика, настройте клиенты или прокси-серверы, чтобы включить исходный IP-адрес в заголовки XFF . Azure Firewall сохраняет эти IP-адреса в заголовке XFF и добавляет IP-адрес брандмауэра в заголовок XFF при обработке правил веб-трафика.
Поддержка фильтрации SQL FQDN только в режиме прокси-сервера (порт 1433) Для Azure SQL Database, Azure Synapse Analytics и Azure SQL Managed Instance:

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

Для Azure SQL IaaS:

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

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

Дополнительные сведения см. в разделе масштабирование SNAT-портов с Azure Virtual Network NAT.
DNAT не поддерживается при включенном принудительном туннелировании Брандмауэры, развернутые с включенным принудительным туннелированием, не поддерживают входящий трафик из Интернета из-за асимметричной маршрутизации. Отсутствие поддержки DNAT при принудительном туннелировании запланировано из-за асимметричной маршрутизации. Путь возврата для входящих подключений проходит через локальный брандмауэр, который не видит установленного подключения.
Исходящий пассивный FTP может не работать для брандмауэров с несколькими общедоступными IP-адресами в зависимости от конфигурации FTP-сервера. Пассивный FTP устанавливает разные подключения для каналов управления и данных. Когда брандмауэр с несколькими общедоступными IP-адресами отправляет данные для исходящего трафика, он случайным образом выбирает один из общедоступных IP-адресов в качестве исходного. FTP может завершиться ошибкой, если каналы управления и обмена данными используют разные исходные IP-адреса, в зависимости от конфигурации FTP-сервера. Запланирована явная конфигурация SNAT. Тем временем можно настроить FTP-сервер так, чтобы он принимал каналы данных и управления с разных исходных IP-адресов (см. пример для IIS). Кроме того, при возникновении проблем с подключением FTP рекомендуется использовать один IP-адрес.
Входящий пассивный FTP может не работать в зависимости от конфигурации FTP-сервера Пассивный FTP устанавливает разные подключения для каналов управления и данных. Входящие подключения через Azure Firewall преобразуются с использованием SNAT к одному из частных IP-адресов брандмауэра для обеспечения симметричной маршрутизации. FTP может завершиться ошибкой, если каналы управления и обмена данными используют разные исходные IP-адреса, в зависимости от конфигурации FTP-сервера. Сохранение исходного IP-адреса источника изучается. Тем временем можно настроить FTP-сервер так, чтобы он принимал каналы данных и управления с разных исходных IP-адресов.
Активный FTP не работает, когда FTP-клиент должен обратиться к FTP-серверу через Интернет. Активный FTP использует команду PORT из FTP-клиента, который указывает FTP-серверу, какой IP и порт использовать для канала передачи данных. Команда PORT использует частный IP-адрес клиента, который не может быть изменен. Трафик на стороне клиента, проходящий через Azure Firewall, подвергается трансляции NAT для интернет-коммуникаций, в результате чего FTP-сервер считает команду PORT недопустимой. Сбой Active FTP — это основное ограничение Active FTP при использовании с NAT на стороне клиента.
В метрике NetworkRuleHit отсутствует измерение протокола Метрика ApplicationRuleHit разрешает протокол на основе фильтрации, но этот компонент отсутствует в соответствующей метрике NetworkRuleHit. Соответствующее исправление рассматривается.
Правила NAT с портами в диапазоне от 64000 до 65535 не поддерживаются Azure Firewall разрешает любой порт в диапазоне 1–65535 в правилах сети и приложений, однако правила NAT поддерживают только порты в диапазоне 1–63999. Ограничение портов правил NAT является текущим ограничением.
Обновления конфигурации могут занять пять минут в среднем Обновление конфигурации Azure Firewall может занять три–пять минут в среднем, а параллельные обновления не поддерживаются. Соответствующее исправление рассматривается.
Azure Firewall использует заголовки TLS SNI для фильтрации трафика HTTPS и MSSQL Если браузер или серверное программное обеспечение не поддерживает расширение индикатора имени сервера (SNI), вы не можете подключиться через Azure Firewall. Если браузер или серверное программное обеспечение не поддерживает SNI, возможно, вы сможете управлять подключением с помощью сетевого правила вместо правила приложения. См. Индикатор имени сервера для программного обеспечения, поддерживающего SNI.
Не удается добавить теги политики брандмауэра с помощью портала или шаблонов Azure Resource Manager (ARM) Azure Firewall Политика имеет ограничение поддержки исправлений, которое предотвращает добавление тега с помощью портала 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/Application или Network — 2000 (Resource Manager ограничение). Текущее ограничение — предел в 2000 правил для коллекции.
Не удается развернуть брандмауэр с Availability Zones с недавно созданным общедоступным IP-адресом При развертывании брандмауэра с Availability Zones нельзя использовать только что созданный общедоступный IP-адрес. Сначала создайте новый избыточный между зонами общедоступный IP-адрес, а затем назначьте этот ранее созданный IP-адрес во время развертывания брандмауэра.
Связывание общедоступного IP-адреса с Azure Firewall не поддерживается в сценарии между клиентами. Если вы создаете общедоступный IP-адрес в клиенте A, вы не можете связать его с брандмауэром, развернутным в клиенте B. Нет.
Виртуальные машины за пределами Azure Firewall не могут подключаться к адресатам правил DNAT, используя общедоступный IP-адрес брандмауэра. Когда виртуальные машины направляют трафик через Azure Firewall и пытаются подключиться к ресурсам, настроенным с помощью правил DNAT с помощью общедоступного IP-адреса брандмауэра, подключение завершается ошибкой. Сбой подключения происходит из-за того, что Azure Firewall не поддерживает перенаправление трафика от внутренних виртуальных машин на собственный публичный IP-адрес брандмауэра для целей правил DNAT. Решение для этого ограничения в настоящее время находится в разработке.
Проблемы с подключением при маршрутизации ОС-уровневого трафика IPsec из виртуальных машин Azure в локальную сеть через Azure Firewall Standard В некоторых гибридных развертываниях Azure виртуальные машины используют туннели IPsec на основе ОС для подключения к локальным сетям. Если этот трафик направляется через Azure Firewall категории "Стандартный", особенно при использовании VPN Gateway или глобального пиринга виртуальных сетей, пакеты IPsec могут не проходить через брандмауэр, что приводит к проблемам с подключением. Избегайте маршрутизации IPsec-трафика, присущего ОС, из виртуальных машин Azure через Azure Firewall Standard. Решение для этого ограничения в настоящее время находится в разработке.
Операции управления создают запросы DNS, видимые в журналах Брандмауэр Azure выполняет внутренние поиски DNS в рамках обычных операций управления и платформы (например, обновлений конфигурации, телеметрии и подключения к службам). Эти запросы DNS могут отображаться в журналах Azure DNS клиента или средствах мониторинга безопасности, даже если они не инициируются трафиком клиента. Это поведение ожидается и не указывает на ошибку конфигурации или проблемы безопасности. При необходимости фильтруйте или исключите известные домены служб Майкрософт в политиках мониторинга DNS.

известные проблемы Azure Firewall Premium

Замечание

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

Azure Firewall Premium имеет следующие известные проблемы:

Проблема Описание Смягчение последствий
Поддержка 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 истекает. В некоторых уникальных случаях срок действия промежуточного сертификата ЦС может истекти через два месяца до первоначальной даты окончания срока действия. Обновите промежуточный сертификат ЦС за два месяца до первоначальной даты окончания срока действия. Соответствующее исправление рассматривается.
Проблемы с подключением при маршрутизации трафика IPsec, собственного для ОС, из виртуальных машин Azure в локальную сеть через Azure Firewall Premium. В некоторых гибридных развертываниях Azure виртуальные машины используют туннели IPsec на основе ОС для подключения к локальным сетям. Если этот трафик направляется через Azure Firewall категории "Стандартный", особенно при использовании VPN Gateway или глобального пиринга виртуальных сетей, пакеты IPsec могут не проходить через брандмауэр, что приводит к проблемам с подключением. Избегайте маршрутизации встроенного в ОС IPsec-трафика из виртуальных машин Azure через Azure Firewall Premium. Решение для этого ограничения в настоящее время находится в разработке.

Дальнейшие действия

  • Last updated on