У нас есть VPN-подключения типа site-to-site с использованием Azure VPN Gateway и различных локальных сетевых устройств в соответствующих клиентских расположениях. Мы пытаемся подключить новое подключение, но имеем конфликт диапазона IP с сетью на другом конце. Приведенная ниже диаграмма, хотя и является вольной интерпретацией на стороне клиента, поскольку у меня нет всех подробностей на их стороне, объясняет это, вероятно, лучше всего, но вот факты:
Конфликт диапазонов IP-адресов на обоих концах туннеля Azure VPN S2S
- Сеть A (192.168.1.0/24) находится за нашим шлюзом Azure VPN и находится под нашей ответственностью.
- Сеть B (192.168.2.0/24) является целевой сетью для пакетов, исходящих из сети A, находится в зоне ответственности нашего клиента и размещена в частном облаке.
- Сеть C (192.168.1.0/24) — это еще одна сеть в частном облаке, которая не имеет отношения к нашему трафику, за исключением того, что она представляет собой конфликт диапазонов IP-адресов в частном облаке клиента.
Поддержка Azure указала, что единственным средством является повторное назначение IP-адреса одной из конфликтующих сетей, поскольку конфликтующие диапазоны в настоящее время не поддерживаются. По их словам, NAT не является жизнеспособным решением на обоих концах туннеля. Добавление новой подсети за шлюзом Azure VPN и пересылка/NAT трафика в сеть A также не поддерживается.
Из-за последствий переадресации сети A мы не хотим переадресовывать ее. Неудивительно, что клиент также не хочет переадресовывать свою сеть, сеть C. Может быть, я просто отрицаю, но кто-нибудь еще сталкивался с этим сценарием и успешно обходил или решал его?безпереадресация IP? Если да, то любая документация или конфигурации, поддерживающие решение, на которые можно сослаться, были бы весьма признательны.
Заранее благодарю за любую помощь.
решение1
- конкретная маршрутизация
Вы написали, что вас интересует маршрутизация между сетями 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, в то время как перед тем, как покинуть узел, он будет dNAT-кодирован / сопоставлен с 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 с «обновленными» значениями, чтобы клиенты связывались с «правильными» конечными точками.