Назад | Перейти на главную страницу

Виртуальная машина Azure не может получить доступ к себе через общедоступный IP-адрес

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

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

Пример. В старом регионе виртуальная машина имела общедоступный IP-адрес 192.0.0.1. В новом регионе 192.0.100.1. В обоих регионах он находится в виртуальной сети и имеет IP-адрес виртуальной сети 10.0.1.1.

Раньше виртуальная машина могла получить доступ к себе, подключившись к 192.0.0.1 или подключившись к общедоступному DNS-имени, связанному с ее общедоступным IP-адресом. После миграции DNS-запись была обновлена, чтобы указать на новый IP-адрес, и я дождался периода TTL (1 час), чтобы убедиться, что срок действия старого IP-адреса истек из кешей. Однако теперь виртуальная машина не может получить доступ к себе ни через DNS, ни с помощью своего нового прямого общедоступного IP-адреса 192.0.100.1.

Я попытался добавить правило брандмауэра в NSG, которое разрешает весь трафик с 10.0.1.1 на 192.0.100.1, но это ничего не изменило.

Примером использования для этого является веб-API и его база данных, работающие на одном сервере. Веб-API пытается подключиться к базе данных, используя свое DNS-имя, которое указывает на его общедоступный IP-адрес.

Обходной путь, который я сделал на данный момент, - просто добавить DNS-имя для SQL-сервера в файл HOSTS и указать его на 10.0.1.1. Однако это не объясняет изменения в поведении.

Вопрос: почему виртуальная машина не может получить доступ к самой себе через публичный IP-адрес (когда раньше это было возможно)? Могу ли я внести какие-либо изменения в конфигурацию сети или брандмауэры, чтобы эта функция снова заработала?

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

Надеюсь, это кому-то поможет!

Некоторые вещи, которые вы можете попробовать.

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

Вариант 2. Создайте виртуальную машину в той же подсети и попробуйте отправить несколько пакетов по протоколу ICMP.

Вариант 3: перейдите в Наблюдатель за сетями> Проверка IP-потока, вы можете устранить неполадки при отправке некоторых пакетов на виртуальную машину.

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

С уважением
Виктор Вильяр