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

Устранение неполадок подключения шлюза NAT Azure

  • Статья

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

Снижение доступности Datapath в шлюзе NAT с ошибками подключения

Сценарий

Вы наблюдаете падение доступности шлюза NAT, которое совпадает с ошибками подключения.

Возможные причины

  • Исчерпание портов преобразования сетевых адресов (SNAT).

  • Ограничения одновременного подключения SNAT.

  • Время ожидания подключения.

  • Удаление общедоступных IP-адресов или подсетей из шлюза NAT.

Устранение неполадок

  • Оцените работоспособность шлюза NAT, проверив метрику доступности datapath.

  • Проверьте метрику счетчика подключений SNAT и разделите состояние подключения путем попытки и неудачных подключений. Более нуля неудачных подключений указывают на исчерпание портов SNAT или достижение ограничения количества подключений SNAT шлюза NAT.

  • Убедитесь, что метрика счетчика подключений находится в пределах ограничений, проверяя метрику общего количества подключений SNAT. Шлюз NAT поддерживает 50 000 одновременных подключений на IP-адрес к уникальному назначению и до 2 миллионов подключений в общей сложности. Дополнительные сведения см. в статье о производительности шлюза NAT.

  • Проверьте метрику удаленных пакетов для любых удалений пакетов, которые соответствуют сбоям подключения или большому объему подключения.

  • При необходимости настройте параметры таймера таймера простоя протокола управления передачей (TCP). Таймер времени ожидания простоя, превышающий значение по умолчанию (4 минуты), удерживается на потоках дольше и может создать дополнительное давление на инвентаризацию портов SNAT.

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

Возможные решения для исчерпания портов SNAT или достижения одновременных ограничений подключения

  • Добавьте общедоступные IP-адреса в шлюз NAT до 16, чтобы масштабировать исходящее подключение. Каждый общедоступный IP-адрес предоставляет 64 512 портов SNAT и поддерживает до 50 000 одновременных подключений на уникальную конечную точку назначения для шлюза NAT.

  • Распределите среду приложения по нескольким подсетям и создайте для каждой из них собственный ресурс шлюза NAT.

  • Освободите инвентаризацию портов SNAT, уменьшая время ожидания простоя TCP до более низкого значения. Минимальное значение таймера тайм-аута простоя TCP составляет 4 минуты.

  • Рассмотрим асинхронные шаблоны опроса, чтобы освободить ресурсы подключения для других операций.

  • Подключение к службам Azure PaaS через магистраль Azure с помощью Приватный канал. Приватный канал освобождает порты SNAT для исходящих подключений к Интернету.

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

Примечание.

Важно понимать, почему происходит исчерпание портов SNAT. Убедитесь, что вы используете правильные шаблоны для масштабируемых и надежных сценариев. Добавление в систему портов SNAT без понимания причин высокого спроса допустимо применять только в крайних случаях. Если вы не понимаете, почему ваш сценарий применяет давление на инвентаризацию портов SNAT, добавление дополнительных портов SNAT путем добавления дополнительных IP-адресов будет отложить только тот же сбой исчерпания, что и масштабирование приложения. Возможно, вы будете затыкать дыры, созданные неэффективностью или антишаблоном в приложении. Дополнительные сведения см . в рекомендациях по эффективному использованию исходящих подключений.

Возможные решения для времени ожидания tcp-подключения

Используйте хранимые протоколы TCP или уровни приложений, чтобы обновить потоки простоя и сбросить таймер времени ожидания простоя. Примеры см . в примерах .NET.

Методы проверки активности TCP необходимо включить только с одной стороны подключения, чтобы поддерживать его с обеих сторон. При отправке протокола TCP с одной стороны подключения другая сторона автоматически отправляет пакет подтверждения (ACK). Затем таймер тайм-аута простоя сбрасывается на обеих сторонах подключения.

Примечание.

Увеличение времени ожидания простоя TCP является последним и может не устранить первопричину проблемы. Длительное время ожидания может привести к задержке и вызвать ненужные сбои с низкой скоростью при истечении времени ожидания.

Возможные решения для времени ожидания подключения протокола UDP

Таймер времени ожидания простоя UDP устанавливается на 4 минуты и не настраивается. Включите UDP keepalives для обоих направлений в потоке подключения для поддержания длинных подключений. Если включена поддержка UDP, она активна только для одного направления в соединении. Подключение по-прежнему может оставаться в состоянии простоя и время ожидания на другой стороне подключения. Чтобы предотвратить тайм-аут простоя подключения UDP, методы проверки активности UDP необходимо включить для обоих направлений в потоке подключения.

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

Влияние удаления общедоступных IP-адресов или подсетей из шлюза NAT

Все активные подключения, связанные с общедоступным IP-адресом, завершаются, когда общедоступный IP-адрес удаляется из шлюза NAT. Если ресурс шлюза NAT содержит несколько общедоступных IP-адресов, новый трафик распределяется между назначенными IP-адресами. Трафик также будет нарушен, если шлюз NAT удален из любой подсети с активными подключениями. Рассмотрите возможность обновления конфигураций шлюза NAT во время обслуживания, чтобы свести к минимуму влияние на исходящее подключение.

Снижение доступности Datapath в шлюзе NAT, но не происходит сбоев подключения.

Сценарий

Доступность шлюза NAT отпадает, но не наблюдается неудачных подключений.

Возможная причина

Временное падение доступности datapath, вызванное шумом в пути данных.

Действия по устранению неполадок

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

Настройте оповещение для удаления доступности datapath или используйте Azure Работоспособность ресурсов для оповещения о событиях работоспособности шлюза NAT.

Отсутствие исходящего подключения к Интернету

Сценарий

Вы не наблюдаете исходящее подключение к шлюзу NAT.

Возможные причины

  • Неправильное настройка шлюза NAT.

  • Интернет-трафик перенаправляется из шлюза NAT и принудительно туннелируется на виртуальное устройство или в локальное место назначения с VPN или ExpressRoute.

  • Правила группы безопасности сети (NSG) настраиваются, блокируют интернет-трафик.

  • Доступность NAT шлюза данных NAT снижается.

  • Неправильно настроена система доменных имен (DNS).

Действия по устранению неполадок

  • Убедитесь, что шлюз NAT настроен по крайней мере с одним общедоступным IP-адресом или префиксом и подключен к подсети. Шлюз NAT не работает до присоединения общедоступного IP-адреса и подсети. Дополнительные сведения см. в разделе Основы конфигурации шлюза NAT.

  • Проверьте таблицу маршрутизации подсети, подключенной к шлюзу NAT. Любой трафик 0.0.0.0/0 принудительно туннелируется в сетевое виртуальное устройство (NVA), ExpressRoute или VPN-шлюз будет иметь приоритет через шлюз NAT. Дополнительные сведения см. в статье о выборе маршрута в Azure.

  • Проверьте наличие правил NSG, настроенных для сетевого интерфейса на виртуальной машине, которая блокирует доступ к Интернету.

  • Проверьте, находится ли доступность шлюза NAT в состоянии снижения уровня доступности NAT. Ознакомьтесь с рекомендациями по устранению неполадок при сбое подключения, если шлюз NAT находится в состоянии пониженного состояния.

  • Проверьте параметры DNS, если DNS не разрешается должным образом.

Возможные решения для потери исходящего подключения

  • Подключите общедоступный IP-адрес или префикс к шлюзу NAT. Кроме того, убедитесь, что шлюз NAT подключен к подсетям из одной виртуальной сети. Убедитесь, что шлюз NAT может подключаться к исходящему трафику.

  • Внимательно рассмотрите требования к маршрутизации трафика перед внесением изменений в маршруты трафика для виртуальной сети. Определяемые пользователем маршруты (UDR), отправляющие трафик 0.0.0.0/0 на виртуальное устройство или шлюз виртуальной сети, переопределяют шлюз NAT. Дополнительные сведения о том, как настраиваемые маршруты влияют на маршрутизацию сетевого трафика.

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

  • Обновите правила безопасности NSG, которые блокируют доступ к Интернету для любой из виртуальных машин. Дополнительные сведения см. в статье об управлении группами безопасности сети.

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

Общедоступный IP-адрес шлюза NAT не используется для подключения к исходящему трафику

Сценарий

Шлюз NAT развертывается в виртуальной сети Azure, но для исходящих подключений используются непредвиденные IP-адреса.

Возможные причины

  • Неправильное настройка шлюза NAT.

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

  • Частные IP-адреса используются для подключения к службам Azure конечными точками службы или Приватный канал.

  • Подключения к учетным записям хранения приходят из того же региона, что и виртуальная машина, из которую вы выполняете подключение.

  • Интернет-трафик перенаправляется из шлюза NAT и принудительно туннелируется в NVA или брандмауэр.

Устранение неполадок

  • Убедитесь, что шлюз NAT имеет по крайней мере один общедоступный IP-адрес или префикс, связанный по крайней мере с одной подсетью.

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

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

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

  • Убедитесь, что виртуальная машина находится в том же регионе, что и хранилище Azure при подключении к хранилищу.

  • Убедитесь, что общедоступный IP-адрес, используемый для подключений, происходит из другой службы Azure в виртуальной сети Azure, например сетевого виртуального устройства (NVA).

Возможные решения для общедоступного IP-адреса шлюза NAT, не используемые для подключения к исходящему трафику

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

  • Проверьте и устраните проблемы, связанные с виртуальными машинами, удерживаемыми на старых IP-адресах SNAT из другого метода исходящего подключения:

    • Убедитесь, что вы устанавливаете новое подключение и что существующие подключения не будут повторно использоваться в ОС или что браузер кэширования подключений. Например, при использовании curl в PowerShell необходимо указать параметр -DisableKeepalive, чтобы принудительно создать новое соединение. Если вы используете браузер, подключения также можно использовать в пуле.

    • Перезагружать виртуальную машину в подсети, настроенной для шлюза NAT, не требуется. Но при перезагрузке виртуальной машины состояние подключения будет сброшено. При очистке состояния подключения все подключения начинаются с IP-адреса или адресов ресурса шлюза NAT. Такое поведение является побочным эффектом перезагрузки виртуальной машины, а не признаком необходимости перезагрузки.

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

  • Пользовательские маршруты, направляющие трафик 0.0.0.0/0 в NVA, будут иметь приоритет над шлюзом NAT для маршрутизации трафика в Интернет. Чтобы шлюз NAT перенаправлял трафик в Интернет вместо NVA, удалите настраиваемый маршрут для трафика 0.0.0.0/0/0 на виртуальном устройстве. Трафик 0.0.0.0/0 возобновляется с использованием маршрута по умолчанию к Интернету и шлюзу NAT.

Внимание

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

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

Примечание.

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

Сбои подключения в общедоступном назначении в Интернете

Сценарий

Подключения шлюза NAT к назначениям Интернета завершаются сбоем или истечением времени ожидания.

Возможные причины

  • брандмауэр или другие компоненты управления трафиком в месте назначения;

  • ограничение скорости API, накладываемое со стороны места назначения;

  • устранение рисков объемных атак DDoS или формирование трафика транспортного уровня;

  • Конечная точка назначения отвечает фрагментированных пакетов.

Устранение неполадок

  • Для сравнения проверьте подключение к конечной точке в том же регионе или в другом месте.

  • Проводите запись пакетов с сторон источника и назначения.

  • Просмотрите количество пакетов в источнике и назначении (если доступно), чтобы определить, сколько попыток подключения было выполнено.

  • Просмотрите удаленные пакеты, чтобы узнать, сколько пакетов удалено шлюзом NAT.

  • Анализ пакетов. TCP-пакеты с фрагментированных пакетов ПРОТОКОЛА IP указывают на фрагментацию IP-адресов. Шлюз NAT не поддерживает фрагментацию IP-адресов, поэтому подключения с фрагментированных пакетов завершаются сбоем.

  • Убедитесь, что общедоступный IP-адрес шлюза NAT указан как разрешенный в местах назначения партнеров с брандмауэрами или другими компонентами управления трафиком.

Возможные решения для сбоев подключения в интернете

  • Убедитесь, что общедоступный IP-адрес шлюза NAT указан как разрешенный в назначении.

  • Если вы создаете большой объем или тестируете скорость транзакций, проверьте, уменьшится ли частота возникновения сбоев, если снизить скорость.

  • Если снижение скорости подключений уменьшается, проверьте, достигнут ли целевой объект ограничения скорости API или другие ограничения.

Сбои подключения на FTP-сервере для активного или пассивного режима

Сценарий

При использовании шлюза NAT с активным или пассивным режимом FTP отображаются сбои подключения на FTP-сервере.

Возможные причины

  • Режим активного FTP включен.

  • Режим пассивного FTP включен, а шлюз NAT использует несколько общедоступных IP-адресов.

Возможное решение для режима Active FTP

FTP использует два отдельных канала между клиентом и сервером, командами и каналами данных. Каждый канал взаимодействует с отдельными TCP-подключениями, один для отправки команд и других для передачи данных.

В активном режиме FTP клиент устанавливает канал команд, а сервер устанавливает канал данных.

Шлюз NAT несовместим с активным режимом FTP. Активный FTP использует команду PORT из FTP-клиента, которая сообщает FTP-серверу, какой IP-адрес и порт для сервера следует использовать на канале данных для подключения к клиенту. Команда PORT использует частный адрес клиента, который нельзя изменить. Клиентский трафик SNATed по шлюзу NAT для обмена данными через Интернет, поэтому команда PORT рассматривается как недопустимая FTP-сервером.

Вместо этого можно использовать пассивный режим FTP. Однако для использования шлюза NAT в пассивном режиме FTP необходимо учитывать некоторые аспекты .

Возможное решение для пассивного режима FTP

В пассивном режиме FTP клиент устанавливает подключения как в командах, так и в каналах данных. Клиент запрашивает ответ сервера на порт, а не пытается установить подключение обратно к клиенту.

Исходящий пассивный FTP не работает для шлюза NAT с несколькими общедоступными IP-адресами в зависимости от конфигурации FTP-сервера. Если шлюз NAT с несколькими общедоступными IP-адресами отправляет исходящий трафик, он случайно выбирает один из его общедоступных IP-адресов для исходного IP-адреса. FTP завершается ошибкой, если каналы управления и данные используют разные исходные IP-адреса в зависимости от конфигурации FTP-сервера.

Чтобы предотвратить возможные пассивные сбои ftp-подключения, выполните следующие действия.

  1. Убедитесь, что шлюз NAT подключен к одному общедоступному IP-адресу, а не к нескольким IP-адресам или префиксу.

  2. Убедитесь, что пассивный диапазон портов из шлюза NAT разрешено передавать любые брандмауэры в конечной точке назначения.

Примечание.

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

Исходящие подключения через порт 25 блокируются

Сценарий

Не удается подключиться к исходящему трафику шлюза NAT через порт 25 для трафика SMTP.

Причина

Платформа Azure блокирует исходящие ПОДКЛЮЧЕНИЯ SMTP через TCP-порт 25 для развернутых виртуальных машин. Это позволяет улучшить безопасность для партнеров и клиентов Microsoft, защитить платформу Microsoft Azure и обеспечить соответствие отраслевым стандартам.

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

Дополнительные сведения см. в руководстве по устранению неполадок.

Запись дополнительных сетевых данных

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

  • Проверьте ответ порта пробы, используя ps ping одну из внутренних виртуальных машин в виртуальной сети и результаты записи (например: ps ping 10.0.0.4:3389).

  • Если в этих тестах связи нет ответа, выполните одновременную netsh трассировку на серверной виртуальной машине и тестовую виртуальную машину виртуальной сети при запуске PsPing, а затем остановите netsh трассировку.

Рекомендации по исходящему подключению

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

Использование пула соединений

Во время объединения подключений в пул избегайте создания новых сетевых подключений для вызовов к одному и тому же адресу и порту. Можно реализовать в приложении схему пула подключений, в которой запросы распределяются внутри фиксированного набора подключений (каждое из которых повторно используется, если это возможно). Такая конфигурация ограничивает количество используемых портов SNAT и делает среду более прогнозируемой. Пул подключений позволяет сократить задержку и использование ресурсов, а также улучшает производительность приложений.

Сведения об объединении подключений HTTP в пул см. в разделе Объединение подключений HTTP в пул с помощью HttpClientFactory.

Повторное использование подключений

Вместо создания отдельных атомарных TCP-подключений для каждого запроса настройте повторное использование подключений в приложениях. Повторное использованием позволяет повысить производительность операций TCP. В частности, это относится к таким протоколам, как HTTP/1.1, в которых подключения используются повторно по умолчанию. Это повторное использование применяется к другим протоколам, где в качестве транспорта используется HTTP, например REST.

Использование менее агрессивной логики повторных попыток

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

В зависимости от настроенного времени ожидания простоя, если повторные попытки слишком агрессивны, подключения не имеют достаточно времени для закрытия и выпуска портов SNAT для повторного использования.

Дополнительные инструкции и примеры см. в статье Шаблон повторений.

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

Дополнительные сведения о времени ожидания простоя TCP см. в разделе "Время ожидания простоя TCP".

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

Чтобы создать Приватный канал, ознакомьтесь со следующими краткими руководствами:

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

Мы всегда стремимся улучшить опыт наших клиентов. Если вы столкнулись с проблемами шлюза NAT, которые не устранены или устранены этой статьей, предоставьте отзыв через GitHub в нижней части этой страницы.

Дополнительные сведения о шлюзе NAT см. в следующих статьях: