Я только что завершил миграцию виртуальной машины 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. В параметрах виртуальной машины есть параметр повторного развертывания, который иногда может решить проблемы с подключением.
С уважением
Виктор Вильяр