Вопрос или проблема
Используя Azure gateway VPN, я создал соединение сайт-сайт с другим VPN-устройством (checkpoint), которым я не управляю (конечная точка клиента).
Я создал соединение, используя их публичный IP, объявил секретный ключ и для локального адресного пространства обсудил с клиентом, какой ‘локальный’ IP желателен с обеих сторон. Мы согласились на IP в диапазоне 172.0.0.0.
Соединение шлюза говорит “успешно/подключено”, и я вижу очень мало трафика в поле передачи данных (в кб, а не в мб).
Однако, когда я пытаюсь выполнить ping локального адресного пространства (172.xxx.xxx.xxx) с моего Windows Server 2016 VM, я получаю только ошибки “Запрос истек по тайм-ауту”.
Нужно ли мне создавать дополнительные маршруты в Windows? Я пытался добавить маршрут
route -p ADD 172.xxx.xxx.xxx MASK 255.255.255.255 0.0.0.0
но хост все еще недоступен.
Какие-нибудь идеи? Спасибо
РЕДАКТИРОВАНИЕ: добавлен некоторый прогресс ниже
Спасибо, я разрешил ping и теперь могу выполнять ping своего VPN-шлюза с моей Azure VM (которая имеет IP 10.XXX.XXX.4). Затем я добавил маршрут
“route -p ADD 172.xxx.xxx.xxx MASK 255.255.255.255 10.XXX.XXX.4”
и с помощью tracert я могу видеть, что адрес 172 маршрутизируется к/через vpn-шлюз, но затем возникает тайм-аут. Значит ли это, что проблема теперь на стороне локальной сети?
Редактирование 2
К этому времени, при выполнении проверки журнала vpn, я вижу некоторый трафик, но все еще не могу достичь другой стороны.
Состояние подключения : Подключено
Удаленная точка туннеля : XXX.XXX.XXX.XXX
Входящие байты (с момента последнего подключения) : 360 B
Исходящие байты (с момента последнего подключения) : 5272 B
Входящие пакеты (с момента последнего подключения) : 3 пакета
Исходящие пакеты (с момента последнего подключения) : 130 пакетов
Входящие пакеты, отброшенные из-за несоответствия селектора трафика (с момента последнего подключения) : 0 пакетов
Исходящие пакеты, отброшенные из-за несоответствия селектора трафика (с момента последнего подключения) : 0 пакетов
Пропускная способность : 0 б/с
Пиковая пропускная способность : 0 б/с
Подключено с : 18/09/2017 5:33:18 AM
Во-первых, проверьте, не блокирует ли Windows Firewall ICMP.
Найдите Windows Firewall и откройте его.
- Выберите Advanced Settings слева.
- В левой части окна выберите Inbound Rules.
- В правой части найдите правила с именем File and Printer Sharing (Echo Request – ICMPv4-In).
- Щелкните правой кнопкой мыши каждое правило и выберите Enable Rule.
Во-вторых, убедитесь, что у вас установлены правильные маршруты. Серверы в вашей локальной среде должны знать, как достичь среду Azure. Если ваш шлюз может выполнять ping серверов Azure и наоборот, тогда все в порядке, за исключением того, что единственное устройство, которое знает этот маршрут, это ваш GV. Убедитесь, что серверы в вашей сети также знают, как достичь сети Azure, добавив маршрут к сети Azure через GV. Пример:
Следующий хоп также находится на локальном VPN:
VMs -> Default Windows Gw/Vpn Device -> Azure VPN Gw
route -p add <azure_network> mask <azure_net_mask> gw <azure_vpn_gw_ip>
Поскольку следующий хоп ваших виртуальных машин обычно это Default Windows Gw, это обеспечит, что следующий хоп для достижения azure_network будет azure_vpn_gw_ip. Убедитесь, что таблицы маршрутизации (локальная конфигурация шлюза в Azure) также имеют ваш локальный сегмент сети.
Согласно вашему описанию, кажется, что ваша пользовательская сеть отключила ICMP. Возможно, реализован межсетевой экран на уровне сети или Windows Firewall.
Я предлагаю протестировать другие сервисы (например, RDP или HTTP). Кроме того, вы можете использовать tcping для определения сетевой доступности.
Чтобы отладить вашу проблему, я предлагаю проверить журнал вашего VPN-шлюза, пожалуйста, обратитесь к этой ссылке.
Обновление:
Согласно логу VPN-шлюза Открытого кода.
Состояние подключения : Подключено
Удаленная точка туннеля :
Входящие байты (с момента последнего подключения) : 0 B
Исходящие байты (С момента последнего подключения) : 107604 B
Подключено с : 14/09/2017 6:35:28 AM
Конфигурация VPN-туннеля выполнена неправильно. Вам необходимо снова проверить вашу конфигурацию VPN.
Какой тип VPN вы настроили? Если вы не используете Basic, BGP автоматически настроит необходимые маршруты для вас.
Если это Basic, то вам нужно будет самостоятельно настроить таблицу маршрутов в Azure для направления трафика в правильную сеть.
Настройте таблицу маршрутов так:
У вас должны быть GatewaySubnet и ваша локальная подсеть в таблице с следующим хопом, являющимся виртуальным сетевым шлюзом.
Если это не работает, используйте опцию проверить поток IP, чтобы убедиться, что трафик может проходить через ваши группы безопасности. По умолчанию RDP должен быть доступен, даже если ping недоступен, поэтому попробуйте разные порты.
.
Ответ или решение
Когда речь идет о проблеме с подключением Azure VPN Site-to-site, первой важной задачей является определение и устранение неполадок. В представленной вами ситуации подключение VPN отображается как успешное, однако узел остается недоступным. Рассмотрим возможные причины и подходы к решению данной проблемы.
Теория
Для успешного подключения Site-to-site VPN необходимо, чтобы трафик корректно передавался через сети Azure и локальной сети. Это включает в себя настройки маршрутизации и правила брандмауэра, чтобы IP-пакеты могли свободно проходить между сетями.
- Маршрутизация: Если маршруты не заданы правильно, пакеты могут не достигать целевого узла. В Azure необходимо настроить таблицы маршрутизации и убедиться, что они содержат корректные записи для передачи трафика из вашей виртуальной сети в локальную сеть.
- Брандмауэр: Часто брандмауэры как на стороне Azure, так и на стороне клиента могут блокировать определенные виды трафика, например ICMP (ping).
- Конфигурация VPN: Конфигурация VPN также играет важную роль. Необходимо проверить настройки аутентификации (например, секретные ключи) и параметры IPsec/IKE.
Пример
Пример возможного решения приведенной проблемы может выглядеть следующим образом:
-
Проверка правил брандмауэра: Убедитесь, что на вашем Windows Server 2016 включены правила, разрешающие ICMP-трафик. Это можно сделать через раздел "Входящие правила" в расширенных настройках брандмауэра.
-
Маршрутизация в Windows: Вы добавили маршрут, указав в качестве шлюза 10.XXX.XXX.4. Этот маршрут должен направлять трафик через VPN-шлюз Azure, но если трафик не проходит, возможно, эти настройки неверны. Попробуйте тестировать с помощью утилиты
tracert, чтобы определить, где конкретно происходит обрыв соединения. -
Журналы и мониторинг VPN: Проведите диагностику с использованием журналов VPN в Azure. Это поможет определить, переправляется ли трафик через туннель и сталкивается ли он с какими-либо проблемами на базе туннеля.
Применение
С учетом специфики вашей задачи, я бы рекомендовал следующие шаги:
- Перепроверьте и обновите все параметры маршрутизации в Azure, убедитесь, что есть записи, указывающие на локальную подсеть.
- Проверьте и при необходимости измените настройки локальных маршрутов и приоритизацию этих маршрутов.
- Используйте инструмент диагностики VM Connectivity по адресу Azure Portal для проверки взаимодействия между подсетями.
- Рассмотрите возможность использования другого типа подключения (например, BGP), если ваше текущее подключение не является Basic, так как это может автоматически упростить управление маршрутами.
Кратко, основными усилиями должны быть фокус на правильной конфигурации маршрутизации и брандмауэра, чтобы добиться полноценного и стабильного соединения между сетями.