Используя VPN для шлюза Azure, я создал соединение между сайтами с другим устройством vpn (контрольная точка), над которым у меня нет контроля (конечная точка клиента).
Я создал соединение, используя их общедоступный IP-адрес, объявил секретный ключ и для локального адресного пространства обсудил с клиентом, какой «локальный» IP-адрес желателен с обеих сторон. Мы согласились на IP-адрес в диапазоне 172.0.0.0.
Соединение шлюза сообщает об успешном / подключенном, и я вижу очень мало трафика в поле вывода данных (kb, а не mb).
Однако, когда я пытаюсь проверить связь с локальным адресным пространством (172.xxx.xxx.xxx) с моей виртуальной машины Windows Server 2016, я получаю только ошибки времени ожидания запроса.
Мне нужно создавать дополнительные маршруты в окнах? Я пробовал добавить маршрут
route -p ADD 172.xxx.xxx.xxx MASK 255.255.255.255 0.0.0.0
но хост по-прежнему недоступен.
Любые идеи? Спасибо
РЕДАКТИРОВАТЬ: добавлен некоторый прогресс ниже
Спасибо, я разрешил пинг, и теперь я могу пинговать свой VPN-шлюз с моей виртуальной машины Azure (это 10.XXX.XXX.4). Затем я добавил маршрут «route -p ADD 172.xxx.xxx.xxx MASK 255.255.255.255 10.XXX.XXX.4»
и через tracert я вижу, что адрес 172 маршрутизируется на / через шлюз de vpn, но затем время ожидания истекает. Означает ли это, что проблема теперь находится на стороне сервера?
Редактировать 2
К настоящему времени при запуске vpn diag. log Я вижу трафик, но все равно не могу добраться до другой стороны.
Connectivity State : Connected
Remote Tunnel Endpoint : XXX.XXX.XXX.XXX
Ingress Bytes (since last connected) : 360 B
Egress Bytes (since last connected) : 5272 B
Ingress Packets (since last connected) : 3 Packets
Egress Packets (since last connected) : 130 Packets
Ingress Packets Dropped due to Traffic Selector Mismatch (since last connected) : 0 Packets
Egress Packets Dropped due to Traffic Selector Mismatch (since last connected) : 0 Packets
Bandwidth : 0 b/s
Peak Bandwidth : 0 b/s
Connected Since : 9/18/2017 5:33:18 AM
Какой тип VPN вы предоставили? Если вы не используете Basic, BGP автоматически настроит для вас необходимые маршруты.
Если он базовый, вам нужно будет самостоятельно настроить таблицу маршрутов в Azure, чтобы направлять трафик в правильную сеть.
Настройте таблицу маршрутов следующим образом:
У вас должны быть GatewaySubnet и ваша локальная подсеть в таблице, а следующим переходом будет шлюз виртуальной сети.
Если это не сработает, используйте Проверка IP-потока возможность обеспечить прохождение трафика через ваши группы безопасности. По умолчанию RDP должен быть доступен, даже если нет ping, поэтому попробуйте другие порты.
Согласно вашему описанию, похоже, ваша пользовательская сеть отключила ICMP. Это может быть реализация пограничного сетевого брандмауэра или брандмауэра Windows.
Я предлагаю вам использовать тест с другой службой (например, RDP или http). Кроме того, вы можете использовать tcping для определения сетевого подключения.
Для отладки вашей проблемы я предлагаю вам проверить журнал своего VPN-шлюза, пожалуйста, обратитесь к этому ссылка на сайт.
Обновить:
Согласно журналу VPN-шлюза OP.
Connectivity State : Connected
Remote Tunnel Endpoint :
Ingress Bytes (since last connected) : 0 B
Egress Bytes (Since last connected) : 107604 B
Connected Since : 9/14/2017 6:35:28 AM
VPN-туннель настроен неправильно. Вам нужно еще раз проверить настройку VPN.
Прежде всего, проверьте, не блокирует ли брандмауэр Windows ICMP.
Найдите брандмауэр Windows и щелкните, чтобы открыть его.
Во-вторых, убедитесь, что у вас есть правильная маршрутизация. Серверы в вашей локальной среде должны знать, как подключиться к среде Azure. Если ваш шлюз может пинговать серверы Azure, и обратное тоже верно, тогда все хорошо, за исключением того, что единственное устройство, которое знает этот маршрут, - это ваш GW. Убедитесь, что серверы в вашей сети знают, как подключиться к сети Azure, добавив маршрут к сети Azure через GW. Пример:
Следующий переход также является локальной VPN:
VMs -> Default Windows Gw/Vpn Device -> Azure VPN Gw
route -p add <azure_network> mask <azure_net_mask> gw <azure_vpn_gw_ip>
Поскольку следующим прыжком ваших виртуальных машин обычно является Windows Gw по умолчанию, это гарантирует, что следующий прыжок azure_network это azure_vpn_gw_ip. Убедитесь, что в таблицах маршрутов (конфигурация локального шлюза в Azure) также указан сегмент локальной сети.