Я только что завершил миграцию виртуальной машины 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-адрес (когда раньше это было возможно)? Могу ли я внести какие-либо изменения в конфигурацию сети или брандмауэры, чтобы эта функция снова заработала?
Некоторые вещи можно попробовать.
Вариант 1: Посмотрите на действующие правила безопасности в сетевой карте ВМ, возможно, у вас есть NSG на уровне vnet/subnet и на уровне ВМ.
Вариант 2: Создайте виртуальную машину в той же подсети и попробуйте отправить несколько пакетов по протоколу ICMP.
Вариант 3: Перейдите в Network Watcher > Проверка IP-потока, вы можете найти и устранить неполадки, связанные с отправкой некоторых пакетов на ВМ.
Вариант 4: В опциях виртуальной машины есть возможность переадресации, иногда это может решить проблемы с подключением.
Regards
Виктор Виллар
Мне удалось решить эту проблему, создав новое правило для входящего трафика в NSG с общедоступным IP-адресом сервера, установленным в качестве его источника, а затем, конечно, с соответствующим рассматриваемым портом.
Надеюсь, это кому-то поможет!