Azure - невозможно подключиться к виртуальной машине через VPN типа "сеть-сеть"
Я новичок здесь, а также новичок в брандмауэрах Sophos XG и в Azure, и я не специалист по сетям, что может быть не лучшим сочетанием. С другой стороны, может быть что-то очень простое, что я пропустил:)
Я следовал этому руководству, чтобы установить соединение между брандмауэром Sophos XG и Azure: https://community.sophos.com/kb/en-us/127546
И Sophos, и Azure говорят, что туннель запущен и работает, и я случайно узнал, что могу проверить связь с двумя IP-адресами. -адреса в подсети GatewaySubnet как из локальной сети, так и из виртуальной машины.
Но я не могу выполнить эхо-запрос с виртуальной машины Azure на любой IP-адрес в сети Sophos, я также могу проверить связь с виртуальной машиной с любого клиента или из Sophos. Я также пробовал использовать RDP из обеих сетей, но это тоже не сработало.
Одна вещь, о которой, вероятно, стоит упомянуть, - это то, что сначала у виртуальной машины был только один сетевой адаптер, у обоих были внутренний и внешний IP. Я добавил вторую подсеть в vnet виртуальных машин:
SERVER1-vnet
по умолчанию 10.0.7.0/24 250
Second_NIC_subnet 10.0.8.32/27 26
GatewaySubnet 10.0.8.0/28 10
Затем добавил вторую сетевую карту к виртуальной машине.
Итак, точнее, я могу выполнить эхо-запросы 10.0.8.4 и 10.0.8.5 с виртуальной машины. Я также могу пинговать 10.0.8.4 и 10.0.8.5 из локальной сети. Угадайте, что это может быть проблема с маршрутизацией. Я пробовал оба из них на виртуальной машине, но они кажутся отключенными:
route add -p 192.168.1.0 mask 255.255.255.0 10.0.8.4
route add -p 192.168.1.0 mask 255.255.255.0 10.0. 8.5
Это не имело никакого значения, и я на самом деле не знаю, как работает GatewaySubnet. Кажется, было бы проще с одним IP? С несколькими адресами в GatewaySubnet мне кажется, что маршрут должен быть примерно таким, но это не может быть правильным :)
route add -p 192.168.1.0 mask 255.255.255.0 10.0.8.0/28
Каков был бы пробный способ продолжить поиск и устранение неисправностей?
Я бы начал с проверки IP-потока Наблюдателя за сетью - он сообщит вам, заблокирован ли ваш трафик правилами брандмауэра или неправильно настроенными маршрутами. https://docs.microsoft.com/en-ca/azure/network-watcher/diagnose-vm-network-traffic-filtering-problem
Убедитесь, что ваши определяемые пользователем маршруты в виртуальной сети разрешают соединение с / из 192.168.x и 10.0.x
Не усложняйте задачу и удалите вторую сетевую карту, вам не нужно выполнять маршрутизацию внутри vNET, но вам нужно маршрутизировать все внутри подсети, которая шлюз, используемый, когда трафик идет в ваши локальные сети.
https://docs.microsoft.com/en-us/azure/virtual-network/tutorial-create-route-table-portal
RouteName : Route2Onprem
Префикс адреса : 192.168.1.0/24
Тип следующего перехода : Виртуальное устройство (туннель / конечная точка, указывающая на локальную сеть)
И, как заявил Гарсия, используйте Наблюдатель за сетью для проверки и устранения неполадок. Это отличный набор инструментов для таких сценариев.