Брандмауэр Azure известные проблемы и ограничения
В этой статье перечислены известные проблемы для Брандмауэр Azure. Он обновляется по мере устранения проблем.
Сведения об ограничениях Брандмауэр Azure см. в разделе об ограничениях подписки и службы Azure, квотах и ограничениях.
Брандмауэр Azure категории "Стандартный"
Ниже описаны известные проблемы в Брандмауэре Azure уровня "Стандартный".
Примечание.
Любая проблема, которая относится к уровню "Стандартный", также применяется к уровню "Премиум".
Проблема | Описание | Меры по снижению риска |
---|---|---|
Поддержка DNAT для частных IP-адресов, ограниченная версиями Standard и Premium | Поддержка DNAT на Брандмауэр Azure частный IP-адрес предназначена для предприятий, поэтому ограничена версиями брандмауэра уровня "Стандартный" и "Премиум". | нет |
Правила сетевой фильтрации для протоколов, которые отличаются от TCP или UDP (например, ICMP), не работают для трафика, связанного с Интернетом | Правила сетевой фильтрации для протоколов, которые отличаются от TCP или UDP, не работают со SNAT для общедоступных IP-адресов. Протоколы, которые отличаются от TCP или UDP, поддерживаются между периферийными зонами подсетей и виртуальной сетью. | Брандмауэр Azure использует Load Balancer (цен. категория "Стандартный"), который сейчас не поддерживает SNAT для IP-протоколов. Изучаются варианты поддержки этого сценария в будущем выпуске. |
В 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-адрес брандмауэра (входящий трафик) используют механизм SNAT для одного из частных IP-адресов брандмауэра. На сегодняшний день это требование (также для активно-активных NVA) обеспечивает симметричность маршрутизации. | Чтобы сохранить исходный источник для HTTP/S, следует задуматься об использовании заголовков XFF. Например, перед брандмауэром следует использовать такую службу, как Azure Front Door или Шлюз приложений Azure. Также WAF можно добавить в качестве части службы Azure Front Door и привязать ее к брандмауэру. |
Поддержка фильтрации SQL FQDN только в режиме прокси-сервера (порт 1433) | Для Базы данных SQL Azure, Azure Synapse Analytics и Управляемого экземпляра SQL Azure: Фильтрация полных доменных имен SQL поддерживается только в прокси-режиме (порт 1433). Для Azure SQL IaaS: Если вы используете нестандартные порты, можно указать эти порты в правилах приложения. |
Для SQL в режиме перенаправления (по умолчанию используется для подключения из Azure) можно фильтровать доступ с помощью тега службы SQL в правилах сети Брандмауэра Azure. |
Исходящий трафик через TCP-порт 25 блокируется | Исходящие сообщения электронной почты, отправляемые непосредственно внешним доменам (например outlook.com , и gmail.com ) через TCP-порт 25, блокируются платформой Azure. Это поведение платформы по умолчанию в Azure. Брандмауэр Azure не вводит более конкретное ограничение. |
Используйте прошедшие проверку подлинности службы ретрансляции, которые обычно подключаются через TCP-порт 587, но также поддерживают и другие порты. Подробные сведения см. в статье Устранение проблем с исходящими SMTP-подключениями в Azure. Другим вариантом является развертывание Брандмауэр Azure в стандартной подписке Соглашение Enterprise (EA). Брандмауэр Azure в подписке EA может взаимодействовать с общедоступными IP-адресами с помощью исходящего TCP-порта 25. В настоящее время он также может работать в других типах подписок, но он не гарантируется. Для частных IP-адресов, таких как виртуальные сети, виртуальные сети и Azure ExpressRoute, Брандмауэр Azure поддерживает исходящее подключение через TCP-порт 25. |
Нехватка портов SNAT | Брандмауэр Azure в настоящее время поддерживает 2496 портов на общедоступный IP-адрес для каждого экземпляра масштабируемого набора виртуальных машин серверной части. По умолчанию существует два экземпляра масштабируемого набора виртуальных машин. Таким образом, на поток приходится 4992 порта (конечный IP-адрес, порт назначения и протокол (TCP или UDP). Брандмауэр масштабируется до 20 экземпляров. | Это ограничение платформы. Вы можете обойти эти ограничения, указав минимум пять общедоступных IP-адресов для развертываний Брандмауэра Azure, в которых может возникнуть проблема нехватки SNAT. Это позволит увеличить число доступных портов SNAT в пять раз. Чтобы упростить разрешения для подчиненных компонентов, используйте префикс IP-адреса для выделения ресурсов. В качестве более постоянного решения можно развернуть шлюз NAT, чтобы преодолеть ограничения на количество портов SNAT. Этот подход поддерживается для развертываний виртуальной сети. Дополнительные сведения см. в статье Масштабирование портов SNAT с помощью NAT виртуальных сетей Azure. |
DNAT не поддерживается при включенном принудительном туннелировании | Брандмауэры, развернутые с включенным принудительным туннелированием, не поддерживают входящий трафик из Интернета из-за асимметричной маршрутизации. | Это обусловлено схемой работы асимметричной маршрутизации. Обратный путь входящих подключений проходит через локальный брандмауэр, в котором нет данных об установленном соединении. |
Исходящий пассивный FTP может не работать для брандмауэров с несколькими общедоступными IP-адресами в зависимости от конфигурации FTP-сервера. | Пассивный FTP устанавливает разные подключения для каналов управления и данных. Когда брандмауэр с несколькими общедоступными IP-адресами отправляет данные для исходящего трафика, он случайным образом выбирает один из общедоступных IP-адресов в качестве исходного. FTP может завершиться ошибкой, если каналы управления и данные используют разные исходные IP-адреса в зависимости от конфигурации FTP-сервера. | Планирование явной конфигурации SNAT. Тем временем можно настроить FTP-сервер так, чтобы он принимал каналы данных и управления с разных исходных IP-адресов (см. пример для IIS). Как вариант, рассмотрите использование одного IP-адреса в такой ситуации. |
Входящий пассивный FTP может не работать в зависимости от конфигурации FTP-сервера | Пассивный FTP устанавливает разные подключения для каналов управления и данных. Входящие подключения в Брандмауэре Azure используют механизм SNAT для одного из частных IP-адресов брандмауэра, чтобы обеспечить симметричную маршрутизацию. FTP может завершиться ошибкой, если каналы управления и данные используют разные исходные IP-адреса в зависимости от конфигурации FTP-сервера. | Сохранение исходного IP-адреса источника изучается. Тем временем можно настроить FTP-сервер так, чтобы он принимал каналы данных и управления с разных исходных IP-адресов. |
Активный FTP не работает, когда FTP-клиент должен обратиться к FTP-серверу через Интернет. | Активный FTP использует команду PORT из FTP-клиента, который указывает FTP-серверу, какой IP и порт использовать для канала передачи данных. Эта команда PORT использует частный IP-адрес клиента, который не может быть изменен. Трафик на стороне клиента, проходящий через Брандмауэр Azure, включен для обмена данными через Интернет, что делает команду PORT недопустимой ftp-сервером. | Это общее ограничение Active FTP при использовании с клиентским NAT. |
В метрике NetworkRuleHit отсутствует измерение протокола | Метрика ApplicationRuleHit разрешает протокол на основе фильтрации, но этот компонент отсутствует в соответствующей метрике NetworkRuleHit. | Соответствующее исправление рассматривается. |
Правила NAT с портами в диапазоне от 64000 до 65535 не поддерживаются | Брандмауэр Azure разрешает порты в диапазоне 1–65535 в правилах сети и приложений, но правила NAT поддерживают порты только в диапазоне 1–63999. | Это текущее ограничение. |
Обновления конфигурации могут занять пять минут в среднем | Для обновления конфигурации брандмауэра 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 находится на стадии изучения. |
При обновлении нескольких групп IP-адресов возникает ошибка о конфликте. | При обновлении двух групп IP-адресов или более, подключенных к одному и тому же брандмауэру, для одного из ресурсов возникает сбой. | Это известная проблема/ограничение. При обновлении группы IP-адресов запускается обновление всех брандмауэров, к которым она подключена. Если обновление для второй группы IP-адресов запускается, когда брандмауэр по-прежнему находится в состоянии обновления, обновление группы завершается сбоем. Во избежание сбоя группы, подключенные к одному брандмауэру, нужно обновлять по одной за раз. Подождите достаточное время между обновлениями, чтобы брандмауэр успел выйти из состояния обновления. |
Удаление групп RuleCollectionGroup с использованием шаблонов ARM не поддерживается. | Удаление RuleCollectionGroup с помощью шаблонов ARM не поддерживается и приводит к сбою. | Это не поддерживается. |
Правило DNAT, разрешающее любой (*) трафик SNAT. | Если правило DNAT разрешает любой (*) в качестве исходного IP-адреса, то неявное правило сети соответствует трафику виртуальной сети и всегда будет SNAT трафик. | Это текущее ограничение. |
Добавление правила DNAT в защищенный виртуальный концентратор с поставщиком безопасности не поддерживается. | Это ведет к возникновению асинхронного маршрута для возвращаемого трафика DNAT, который передается поставщику безопасности. | Не поддерживается. |
Ошибка при создании более чем 2000 коллекций правил. | Максимальное число коллекций сетевых правил или правил NAT/приложений составляет 2000 (ограничение Resource Manager). | Это текущее ограничение. |
Заголовок XFF в HTTP/S | Заголовки XFF перезаписываются исходным IP-адресом источника, каким его видит брандмауэр. Это применимо для следующих вариантов использования: – HTTP-запросы; – HTTPS-запросы с терминированием TLS. |
Соответствующее исправление рассматривается. |
Не удается развернуть брандмауэр с Зонами доступности, используя только что созданный общедоступный IP-адрес | При развертывании брандмауэра с Зонами доступности нельзя использовать только что созданный общедоступный IP-адрес. | Сначала создайте новый избыточный между зонами общедоступный IP-адрес, а затем назначьте этот ранее созданный IP-адрес во время развертывания брандмауэра. |
Физическая зона 2 в Восточной Японии недоступна для развертываний брандмауэра. | Невозможно развернуть новый брандмауэр с физической зоной 2. Кроме того, если остановить существующий брандмауэр, развернутый в физической зоне 2, его нельзя перезапустить. Дополнительные сведения см. в разделе "Физические и логические зоны доступности". | Для новых брандмауэров разверните остальные зоны доступности или используйте другой регион. Сведения о настройке существующего брандмауэра см. в статье "Как настроить зоны доступности после развертывания?". |
Брандмауэр Azure категории "Премиум"
Ниже описаны известные проблемы в Брандмауэре Azure уровня "Премиум".
Проблема | Описание | Меры по снижению риска |
---|---|---|
Поддержка ESNI для разрешения FQDN в HTTPS | Зашифрованный SNI не поддерживается при подтверждении HTTPS. | Сейчас только Firefox поддерживает ESNI через пользовательскую конфигурацию. Предлагаемый обходной путь заключается в отключении этой функции. |
Проверка подлинности сертификации клиента не поддерживается | Клиентские сертификаты используются для создания взаимного отношения доверия между клиентом и сервером. Сертификаты клиентов используются во время согласования TLS. Брандмауэр Azure повторно согласовывает соединение с сервером и не имеет доступа к закрытому ключу сертификатов клиентов. | нет |
QUIC/HTTP3 | QUIC — это новая основная версия протокола HTTP. Это протокол на основе UDP через 80 (PLAN) и 443 (SSL). Проверка FQDN/URL/TLS не поддерживается. | Настройте передачу UDP 80/443 в качестве правил сети. |
Сертификаты, подписанные недоверенным клиентом | Подписанные клиентом сертификаты не являются доверенными брандмауэром после получения от веб-сервера на основе интрасети. | Соответствующее исправление рассматривается. |
Неверный исходный IP-адрес в предупреждениях с IDPS для HTTP (без проверки TLS). | Когда используется HTTP-трафик в виде обычного текста, IDPS выдает новое оповещение, а назначение является общедоступным IP-адресом, это значит, что отображаемый исходный IP-адрес неверен (вместо первоначального IP-адреса отображается внутренний IP-адрес). | Соответствующее исправление рассматривается. |
Распространение сертификатов | После применения сертификата ЦС на брандмауэре может потребоваться от 5 до 10 минут, чтобы сертификат вступают в силу. | Соответствующее исправление рассматривается. |
Поддержка TLS 1.3 | Протокол TLS 1.3 поддерживается частично. Туннель TLS от клиента к брандмауэру основан на TLS 1.2, а от брандмауэра к внешнему веб-серверу — на TLS 1.3. | Обновления сейчас рассматриваются. |
Срок действия промежуточного сертификата ЦС TLSi | В некоторых уникальных случаях срок действия промежуточного сертификата ЦС может истекти через два месяца до первоначальной даты окончания срока действия. | Обновите промежуточный сертификат ЦС за два месяца до первоначальной даты окончания срока действия. Соответствующее исправление рассматривается. |