Проблема с подключением в виртуальных машинах на Azure - PullRequest
0 голосов
/ 07 июня 2019

В моем сценарии

Ресурсная группа1 имеет VNet1 с адресным пространством 15.0.0.0/16 и виртуальную машину Windows Server 2016. Она создана в северной части центрального региона США.

Ресурсная группа2 имеет VNet2 с адресным пространством 16.0.0.0/16 и виртуальную машину Windows 10. Она создана в западном регионе США.

Теперь мне нужно подключить обе виртуальные сети, чтобы Windows 10 могла присоединиться к Windows Server 2016. Контроллер домена настроен на Windows Server 2016.

Я получил помощь по ссылке

https://www.assistanz.com/steps-to-create-vnet-to-vnet-vpn-using-azure-portal/

и

http://www.msserverpro.com/configuring-vnet-vnet-vpn-gateway-connection-using-azure-portal/

Я успешно создал подсеть шлюза в обеих виртуальных сетях.

При создании шлюза виртуальной сети я создавался как сервер-клиент и клиент-сервер. Я выбрал Северную Центральную часть США в качестве местоположения «Сервер-Клиент» и выбрал Западную часть США в качестве региона «Клиенты-Сервер».

Кажется, что оба виртуальных сетевых шлюза созданы и успешно подключены

введите описание изображения здесь

но обе виртуальные машины не проверяют друг друга. Даже ни одна виртуальная машина не проверяет IP своего шлюза.

введите описание изображения здесь

и

введите описание изображения здесь

Я включил общий доступ к файлам и принтерам (Echo Request - ICMPv4-In) и общий доступ к файлам и принтерам (Echo Request - ICMPv4-Out) в обеих виртуальных машинах.

Я проверил обнаружение сети и часовой пояс на обеих виртуальных машинах

Однако они не разрешены.

Пожалуйста, помогите мне решить эту проблему.

Ответы [ 3 ]

0 голосов
/ 08 июня 2019

Вместо того, чтобы полагаться на Vnet Gateway и VPN S2S, вы также можете использовать Vnet Peering между регионами.

https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview

0 голосов
/ 08 июня 2019

Я согласен с другими ответами.Global VNet Peering устранит необходимость использования VPN GW, что значительно упрощает среду и устраняет ежемесячную стоимость размещения пары GW.Предполагая, что вам нужны эти GW для других локальных подключений к VPN-устройствам, вы все равно можете использовать этот дизайн.

Как отметил Ханнел, вы используете публичные диапазоны для своих частных сетей.Это тоже нормально, но маршрутизация будет затронута для виртуальных машин в этих подсетях, если они попытаются перейти к фактическим публичным IP-адресам в этих диапазонах.Обратите внимание, что Hewlett Packard владеет большими частями этих диапазонов, поэтому, если вашей виртуальной машине необходимо получать информацию с веб-сайта HP, вам придется создавать ручные UDR, чтобы направлять этот трафик в Next Hop Internet.

Итак, проверьте свои эффективные маршруты на своих сетевых картах.Вы можете проверить это из NIC, а также из Network Watcher.Это должно помочь вам определить, имеет ли приоритет другой маршрут или даже если у вас есть маршрут, отправляющий трафик на виртуальное устройство.

Убедитесь, что вы выбрали VNet-to-VNet при настройке соединения.Если вы выбрали IPSec, вам необходимо правильно настроить шлюзы локальной сети.

0 голосов
/ 08 июня 2019

Возможно, вам придется создавать маршруты, вы не используете рекомендованное личное адресное пространство, поэтому маршруты не созданы для вас.

Azure автоматически создает маршруты по умолчанию для следующих префиксов адресов: 10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16: зарезервировано для частного использования в RFC 1918. 100.64.0.0/10: Зарезервировано в RFC 6598.

Проверка эффективных маршрутов к следующему прыжку для трафика в одноранговом адресном пространстве.

https://docs.microsoft.com/en-us/azure/virtual-network/diagnose-network-routing-problem

Дополнительная информация о маршрутизации VNet

https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview

...