У меня есть виртуальная сеть с несколькими виртуальными машинами в Azure. В виртуальной сети есть VPN-соединение типа "сеть-сеть" с моими помещениями. С локальных клиентов я могу успешно подключаться к частным IP-адресам виртуальных машин. Однако локальные клиенты не могут подключиться к общедоступному IP-адресу виртуальной машины. С другой стороны, если я попытаюсь подключиться к виртуальной машине через другое интернет-соединение (3G на телефоне или из дома), то я могу без проблем подключиться к общедоступному адресу. На локальном сетевом оборудовании нет сетевых ACL, которые могли бы блокировать этот трафик (на самом деле трассировка к общедоступному IP-адресу отключается на адресе ntwk.msn.net). Есть мысли о том, в чем может быть проблема?
ОБНОВЛЕНИЕ 2: я создал новую виртуальную сеть для отдельного диапазона IP-адресов и новую виртуальную машину с общедоступным IP-адресом. Подключение к общедоступному IP-адресу этой виртуальной машины работает нормально. Что-то в VPN / маршрутизации исходной VNET, кажется, является частью проблемы, поскольку без VPN все в порядке.
ОБНОВЛЕНИЕ: я начинаю думать, что это связано с сетевой картой на виртуальной машине. Сетевые адаптеры Azure имеют частный и общедоступный IP-адрес на одном и том же сетевом адаптере, но виртуальная машина не видит общедоступный IP-адрес. Теперь виртуальная сеть, в которой находится сетевая карта, имеет определенные правила маршрутизации, которые указывают, что определенный трафик должен маршрутизироваться в локальную сеть через нашу VPN. Я думаю, что локальный запрос успешно попадает на общедоступный IP-адрес виртуальной машины через общедоступный Интернет, но ответ отправляется с частного IP-адреса через VPN, и клиент отбрасывает его, поскольку он поступил с другого IP-адреса. Поскольку ОС на виртуальной машине не знает публичный IP-адрес, я не знаю, как это исправить.
ОБНОВЛЕНИЕ 3: я использовал Wireshark для прослушивания пакетов на виртуальной машине и обнаружил, что когда я подключаюсь к внешнему IP-адресу из локальной сети, виртуальная машина не получает пакетов. Таким образом, проблема может заключаться в виртуальной сети, SNAT общедоступного IP-адреса или маршрутизации на самой виртуальной машине.
Проблема может быть вызвана вашим клиентом или локальным пограничным устройством интрасети организации, например брандмауэром, прокси, NAT. Я думаю, что это возможно из-за локального или локального брандмауэра.
Тем не менее, вам все же следует проверить некоторые моменты. Следующие шаги в качестве примера относятся к виртуальной машине Windows (идея устранения неполадок также подходит для виртуальной машины Linux):
Проверьте граничное устройство интрасети вашей организации на наличие:
а. Внутренний брандмауэр, блокирующий соединения HTTPS или RDP с Интернетом.
б) прокси-сервер, предотвращающий подключения к удаленному рабочему столу.
c. Программное обеспечение для обнаружения вторжений или мониторинга сети, работающее на устройствах в вашей пограничной сети, которое препятствует подключению к удаленному рабочему столу.
Ваша группа безопасности сети блокирует трафик RDP из Интернета.
Подробные инструкции по устранению неполадок RDP для проблем с подключением к виртуальной машине Windows в Azure см. В этом документ.
Подробные инструкции по устранению неполадок SSH при подключении к виртуальной машине Linux в Azure см. В этой документ.