RST на соединении между двумя виртуальными машинами в Azure VNET

Вопрос или проблема

У меня есть устаревшее приложение, работающее на Windows 11 Azure VM (10.0.0.7 в трассировке). (Оно успешно работало в моей локальной сети в течение 18 лет, и я недавно перенес его в облако.)

W365 Cloud ПК в той же VNET (10.0.0.6 в трассировке) создают постоянное соединение с устаревшим приложением. Устаревшее приложение легковесное, и данные, передаваемые через него, минимальны.

Соединения с устаревшим приложением работают идеально в течение примерно 10-20 минут, затем клиент зависает. Я провел сетевую трассировку (см. скриншот Wireshark) и обнаружил, что машина, на которой размещено устаревшее приложение (10.0.0.7), отправляет RST. Устаревшее приложение не инициирует это.

  1. В этой среде нет балансировщика нагрузки.
  2. Я отключил фаерволы и антивирусы на 10.0.0.7, и на этой виртуальной машине больше ничего нет, кроме ОС и того, что устанавливается вместе с ней.
  3. Я отключил авторазъединение с помощью “net config server /autodisconnect:-1”

Ни одно из этих изменений не помогло.

Есть идеи, что может быть причиной этого? Я в отчаянии!

Скриншот Wireshark

Ответ или решение

Ваша ситуация, связанная с проблемами подключения между двумя виртуальными машинами (ВМ) в Azure VNET, вызывает немало вопросов и требует детального анализа. Давайте разберем возможные причины возникновения RST-пакетов, которые нарушают работу приложения, и определим пути к возможным решениям.

Теоретическая основа (Theory)

RST (Reset) — это TCP-сообщение, посылаемое одной из сторон соединения для разрыва установленного TCP-соединения. RST может быть сгенерирован в ситуации, когда конечная точка не может обработать пакет, либо когда происходит ошибка, либо когда устройство неожиданно прекращает соединение. Причины, почему RST могут быть отправлены:

  1. Программные проблемы: Приложение или ОС принимающего узла могут вызывать RST, если происходит сбой в обработке данных или если приложение заброшено.

  2. Сетевые конфигурации: Неправильные сетевые настройки, такие как тайм-ауты TCP-соединений, могут вызывать RST.

  3. Проблемы с виртуальными машинами (ВМ): Платформа Azure имеет свои особенности в управлении сетевыми ресурсами, которые могут включать автоматическое разрывание соединений при определенных условиях.

  4. Неожиданные нагрузки: Несмотря на то, что вы утверждаете, что приложение легковесное, любые всплески трафика или сетевые аномалии могут повлиять на работу компонентов ОС, что приводит к отправке RST.

Практический пример и его анализ (Example)

В вашем случае, важная деталь заключается в периодичности проблемы: соединение разрывается через 10-20 минут. Это может быть связано с конфигурацией ресурсов платформы Azure или с политиками безопасности, которые предустановлены в VNET.

Вы провели несколько важных диагностических шагов:

  • Отключили межсетевой экран и антивирус на машине 10.0.0.7.
  • Убрали автоматическое отключение с помощью команды "net config server /autodisconnect:-1".

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

Применение и рекомендации (Application)

Для решения вашей проблемы рассмотрите следующие идеи:

  1. Мониторинг ресурсов Azure: Воспользуйтесь инструментами мониторинга Azure (например, Azure Monitor), чтобы отслеживать показатели потребления ресурсов ВМ 10.0.0.7. Обратите внимание на пиковые нагрузки CPU или памяти в момент возникновения RST.

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

  3. Анализ и оптимизация сетевой конфигурации: Проверьте настройки маршрутизации и подсети VNET. Убедитесь, что не возникаются конфликты IP или проблемы с переводом сетевых адресов, если другой подсети работают в том же сетевом пространстве.

  4. Использование сетевых инструментов: Дополните ваш анализ Wireshark использованием сетевых инструментов Azure, таких как Network Watcher, для глубже анализа сетевых потоков и выявления аномалий.

  5. Обновление операционной системы и приложения: Убедитесь, что на 10.0.0.7 установлены последние обновления ОС. Иногда устаревшие компоненты могут вызывать непредвиденные сбои в сетевых взаимодействиях.

  6. Запуск тестов в изолированной среде: Попробуйте развернуть аналогичную конфигурацию в другом региональном центре Azure или на альтернативной площадке, чтобы исключить специфические для региона или оборудования проблемы.

Заключение

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

Оцените материал
Добавить комментарий

Капча загружается...