S2S VPN через NAT с перекрывающимися адресами

Reply to S2S VPN через NAT с перекрывающимися адресами on Mon, 02 Mar 2026 12:41:18 GMT

ralpho2 — Mon, 02 Mar 2026 12:41:18 GMT

большое спасибо, Кристиан

Reply to S2S VPN через NAT с перекрывающимися адресами on Mon, 02 Mar 2026 12:41:17 GMT

ralpho2 — Mon, 02 Mar 2026 12:41:17 GMT

IP-адреса находятся на удаленном сайте. Это NAT-адреса (10.150.1.65 и 66), которые маршрутизируются через туннель (сеть маршрутизируется по адресу 10.150.1.65/29, а не по отдельным IP-адресам). Да, они находятся в ACL, но я не уверен насчет proxy-ACL. Это что-то другое?

Reply to S2S VPN через NAT с перекрывающимися адресами on Mon, 02 Mar 2026 12:41:16 GMT

Cristian Matei — Mon, 02 Mar 2026 12:41:16 GMT

Привет, @ralpho2
Эти IP-адреса находятся на вашей стороне или на удаленной стороне? Эти IP-адреса реальные или NAT-адреса? Включены ли эти IP-адреса в прокси-ACL, трафик, который необходимо отправить через туннель? Эти IP-адреса маршрутизируются через туннель? Спасибо, Кристиан.

Reply to S2S VPN через NAT с перекрывающимися адресами on Mon, 02 Mar 2026 12:41:15 GMT

ralpho2 — Mon, 02 Mar 2026 12:41:15 GMT

Большое спасибо, туннель появился. Один вопрос, пожалуйста. Администратор другой компании дал мне два IP-адреса, которые должны быть доступны для пинга. Я могу инициировать туннель, вижу, как пакеты проходят внутрь, но ничего не возвращается. Поэтому я не могу пинговать эти адреса. Может быть, проблема в моей стороне или в другой стороне? Я думаю, что я не могу это проверить, верно?

Reply to S2S VPN через NAT с перекрывающимися адресами on Mon, 02 Mar 2026 12:41:14 GMT

ralpho2 — Mon, 02 Mar 2026 12:41:14 GMT

Привет, Кристиан, рад тебя видеть
![]
Туннель основан на политике. Ниже приведены несколько скриншотов из NAT и Tunnel. Кстати, я думаю, что мне нужно отключить опцию «Исключить VPN-трафик из преобразования сетевых адресов»? С уважением и благодарностью Ральф ![Bildschirmfoto 2026-02-03 um 09.02.54.png]
![Bildschirmfoto 2026-02-03 um 08.41.51.png]
![Bildschirmfoto 2026-02-03 um 09.07.47.png]

Reply to S2S VPN через NAT с перекрывающимися адресами on Mon, 02 Mar 2026 12:41:13 GMT

Cristian Matei — Mon, 02 Mar 2026 12:41:13 GMT

Привет, @ralpho2
Невозможность подключения IPsec-туннеля может быть связана с вашей конфигурацией NAT (если она основана на политиках, то это может быть связано, если на маршрутах, то нет). Можете ли вы опубликовать всю соответствующую конфигурацию IPsec-туннеля с вашей стороны, а также конфигурацию NAT? Кроме того, можете ли вы еще раз проверить то, что вы написали в отношении NAT, поскольку, похоже, есть несоответствие между выделенным пространством NAT и IP-адресами, которые вы намереваетесь использовать при выполнении преобразования на вашей стороне. Спасибо, Кристиан.

Reply to S2S VPN через NAT с перекрывающимися адресами on Mon, 02 Mar 2026 12:41:12 GMT

Cristian Matei — Mon, 02 Mar 2026 12:41:12 GMT

Привет, @ralpho2
Очистите счетчики IPsec с помощью команды CLI
clear crypto ipsec sa counters
, сгенерируйте трафик через туннель, выполните команду CLI
show crypto ipsec sa peer x.x.x.x
и, если вы увидите зашифрованные (и, возможно, не расшифрованные) пакеты, это означает, что с вашей стороны не нужно ничего делать, попросите другую сторону провести расследование. Пока вы видите зашифрованные пакеты, другая сторона должна видеть расшифрованные пакеты, и их задача — исправить/понять, почему они отбрасывают входящие расшифрованные пакеты и не могут маршрутизировать ответы обратно (они не видят зашифрованных пакетов на своей стороне туннеля). Спасибо, Кристиан.

Reply to S2S VPN через NAT с перекрывающимися адресами on Mon, 02 Mar 2026 12:41:11 GMT

Cristian Matei — Mon, 02 Mar 2026 12:41:11 GMT

Привет, @ralpho2
Да, вам нужно будет снять флажок «Исключить VPN-трафик из преобразования сетевых адресов»; убедитесь, что у вас есть исходящий маршрут по умолчанию на вашем VPN-интерфейсе (вне...), либо настроен статический маршрут для 10.150.1.64.29 на вашем VPN-интерфейсе, чтобы согласование туннеля запускалось при обнаружении интересного трафика; кроме того, вам нужно будет создать дополнительный ручной NAT статического типа для вашего вторичного хоста, который должен быть доступен через этот VPN-туннель, а именно
172.16.5.7, и использовать для него другой IP-адрес, например 10.150.72.74; убедитесь, что ваш ACP разрешает трафик в направлении local-> remote, от исходного local к NAT'ed remote; убедитесь, что ваш ACP разрешает трафик в направлении remote -> local, от NAT'ed remote к исходному local. Используйте packet-tracer для проверки функциональности с вашей стороны. Сгенерируйте трафик, если туннель не появляется, убедитесь, что удаленная сторона настроена правильно, включите следующие отладки из FTD LINA на вашей стороне: debug crypto condition peer x.x.x.x
debug crypto ikev2 platform 127
debug crypto ikev2 protocol 127
debug crypto ipsec 127 Спасибо, Кристиан.