Я здесь новичок, а также новичок в брандмауэрах 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 из локальной сети. Угадайте, что это может быть проблема с маршрутизацией. Я пробовал оба из них на виртуальной машине, но они вроде не работают:
маршрут добавить -p 192.168.1.0 маска 255.255.255.0 10.0.8.4
маршрут добавить -p 192.168.1.0 маска 255.255.255.0 10.0.8.5
Это не имело никакого значения, и я действительно не знаю, как работает GatewaySubnet. Кажется, было бы проще с одним IP? С несколькими адресами в GatewaySubnet мне кажется, что маршрут должен быть примерно таким, но это не может быть правильным :)
маршрут добавить -p 192.168.1.0 маска 255.255.255.0 10.0.8.0/28
Каким будет способ продолжить поиск и устранение неисправностей?
Сделайте это простым и удалите вторую сетевую карту, вам не нужно выполнять маршрутизацию внутри vNET, но вам нужно маршрутизировать все внутри подсети, какой шлюз использовать, когда трафик идет в ваши локальные сети.
https://docs.microsoft.com/en-us/azure/virtual-network/tutorial-create-route-table-portal
RouteName: Route2Onprem
Префикс адреса: 192.168.1.0/24
Тип следующего перехода: Виртуальное устройство (туннель / конечная точка указывает на локальную среду)
И, как заявил Гарсия, используйте средство наблюдения за сетью для проверки и устранения неполадок. Это отличный набор инструментов для таких сценариев.
Я бы начал с попытки проверки IP-потока Наблюдателя за сетью - он сообщит вам, заблокирован ли ваш трафик правилами брандмауэра или неправильно настроенными маршрутами. https://docs.microsoft.com/en-ca/azure/network-watcher/diagnose-vm-network-traffic-filtering-problem
Убедитесь, что ваши определяемые пользователем маршруты в виртуальной сети разрешают соединение с / с 192.168.x и 10.0.x