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


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

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

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

Сценарий

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

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

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

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

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

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

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

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

  • Проверьте метрику количества подключений 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 с помощью Private Link. Приватный канал освобождает порты SNAT для исходящих подключений к Интернету.

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

Примечание.

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

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

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

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

Примечание.

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

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

Таймер времени ожидания простоя UDP устанавливается на 4 минуты и не настраивается. Включите UDP keepalives для обоих направлений в потоке подключения для поддержания длинных подключений. Если активирован UDP keepalive, он действует только в одном направлении соединения. Подключение по-прежнему может оставаться в состоянии простоя и время ожидания на другой стороне подключения. Чтобы предотвратить тайм-аут бездействия подключения 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 ухудшена.

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

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

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

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

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

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

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

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

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

  • Если используется общедоступный IP-адрес IPv6, убедитесь, что виртуальная сеть или подсеть, связанная с шлюзом NAT StandardV2, является двойным стеком. Если это не двойной стек, добавьте адресное пространство IPv6 в виртуальную сеть или добавьте общедоступный IP-адрес IPv4 в шлюз 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 с помощью Конечных Точек Службы или Private Link.

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

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

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

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

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

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

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

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

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

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

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

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

    • Убедитесь, что вы устанавливаете новое подключение и что существующие подключения не используются повторно в ОС или что браузер не кэширует подключения. Например, при использовании 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.

Примечание.

Private Link является рекомендованным вариантом по сравнению с конечными точками для частного доступа к службам, размещенным в 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 использует частный адрес клиента, который нельзя изменить. Клиентский трафик проходит через шлюз NAT и SNAT для интернет-общения, поэтому команда 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 для повторного использования.

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

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

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

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

Чтобы создать частную ссылку, ознакомьтесь с приведёнными ниже краткими руководствами:

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

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

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