У нас есть VPN-соединения типа "сеть-сеть" с использованием шлюза VPN Azure и различных локальных сетевых устройств в соответствующих клиентских местоположениях. Мы пытаемся установить новое соединение, но диапазон IP-адресов конфликтует с сетью на другом конце. Диаграмма ниже, хотя и является вольной интерпретацией на стороне клиента, поскольку у меня нет всех подробностей с их стороны, вероятно, лучше всего это объясняет, но вот факты:
Конфликт диапазона IP-адресов на любом конце туннеля Azure VPN S2S
Служба поддержки Azure указала, что единственным выходом является повторное IP-адрес одной из конфликтующих сетей, поскольку конфликтующие диапазоны в настоящее время не поддерживаются. По их мнению, NAT не является жизнеспособным решением на любом конце туннеля. Добавление новой подсети за шлюзом Azure VPN и пересылка / NAT трафика в сеть A также не поддерживается.
Из-за последствий повторного IP-адресации сети A мы не хотим повторно использовать IP-адрес. Неудивительно, что клиент также не хочет повторно IP-адрес своей сети, сети C. Возможно, я просто отрицаю, но кто-нибудь еще столкнулся с этим сценарием и успешно его обошел или разрешил без пере IP'инг? В таком случае мы будем очень благодарны за любую документацию или конфигурации, поддерживающие решение, на которое можно сослаться.
Заранее благодарю за любую помощь.
Вы писали, что вас интересует маршрутизация между сетями A и B, которые не конфликтуют ... В случае, если SonicWall выполняет маршрутизацию между этими "внутренними клиентскими сетями" и можно не использовать определенные IP-адреса в сети C, вы можете выполнять маршрутизацию через сеть не для всего 192.168.1.0/24, а для определенных IP-адресов как / 32. При выборе маршрута «лучший матч побеждает». В этом случае конкретный трафик будет правильно маршрутизироваться от B к A, а остальной будет передан в сеть C ...
В зависимости от типа VPN, может быть проще или сложнее (если возможно) настроить на SonicWall, но технически это может быть и без NAT. В худшем случае у вас может быть дополнительное устройство, завершающее VPN в Azure, а в SonicWall есть правило статического маршрута для направления этих IP-адресов на этот дополнительный узел.
Таким образом, сторона Azure никогда не будет доступна из C, но это не будет проблемой в зависимости от того, что вы написали.
Как вы уже писали, Azure VPN GW не предлагает эту функцию, единственный вариант - сделать это на другой стороне туннеля - SonicWall Appliance. Со стороны B, C вы можете адресовать «удаленный» сайт, как любой неиспользуемый диапазон IP-адресов (например, 172.16.0.0/24), и как только он достигнет SonicWall, он может быть перенаправлен на VPN, а перед тем, как покинуть узел, он будет назначен / сопоставлен на 192.168.1.0/24, а, например, сохранение последнего значения октета или отображение 1: 1 со списком всех необходимых IP-адресов). Таким образом, для трафика VPN удаленный IP-адрес на стороне Azure будет «правильным» 192.168.0.0/24, а сторона Azure не будет иметь представления о NAT.
В случае, если вы не можете сделать это на SonicWall по какой-либо причине, можно разместить другое устройство, способное сделать это / под собственным управлением, которое завершит VPN-туннель, и из локальной сети будет назначен трафик 172.16.0.0/24 (маршрут на локальном роутере).
Единственными проблемными моментами могут быть случаи, когда вы используете DNS-ответ с адресами 192.168.1.0/24 и сертификатами, использующими IP для идентификации. В случае с DNS вам нужна локальная зона DNS с «обновленными» значениями, чтобы клиенты связывались с «правильными» конечными точками.
