Соединение с удаленным сервером через VPN, когда адрес подсети локальной сети конфликтует с удаленной сетью

Это можно решить, используя NAT; это просто не очень элегантно.

Итак, предполагая, что вы не можете решить эту проблему, имея внутренние сети с такими необычными номерами сетей, что никогда не вступают в конфликт, вот принцип:

Как локальные, так и удаленные подсети имеют одинаковые сетевые номера, трафик от вашего клиента никогда не поймет, что он должен пройти через шлюз туннеля, чтобы достичь места назначения. И даже если мы вообразим, что это возможно, ситуация для удаленного хоста будет такой же, как и для удаленного хоста, когда он собирается отправить ответ.

Так что оставайтесь со мной и притворимся, что пока что нет никаких побочных проблем, пока я пишу это для полного подключения вам потребуется NAT на обоих концах туннеля, чтобы различать хосты и разрешать маршрутизацию.

Создание некоторых сетей здесь:

• В вашей офисной сети используется 192.0.2.0/24[12185 providedYour удаленный офис использует 192.0.2.0/24
• VPN-шлюз вашей офисной сети скрывает 192.0.2.0/24 хоста за сетевым номером 198.51.100.0/24
• VPN-шлюз вашей сети удаленного офиса скрывает 192.0.2.0/24 хоста за номер сети с NAT 203.0.113.0/24

Итак, внутри VPN-туннеля офисных хостов теперь 198. 51.100.x, а хосты удаленного офиса - 203.0.113.x. Кроме того, давайте представим, что все хосты сопоставлены 1: 1 в NAT их соответствующих шлюзов VPN. Пример:

• Ваш офисный сетевой хост 192.0.2.5/24 статически сопоставлен как 198.51.100.5/24 в офисном vpn-шлюзе NAT
• Ваш удаленный офисный сетевой хост 192.0.2.5/24 статически сопоставлен как 203.0.113.5 / 24 в шлюзе vpn удаленного офиса NAT

Поэтому, когда хост 192.0.2.5/24 в удаленном офисе хочет подключиться к хосту с тем же IP-адресом в офисной сети, он должен сделать это, используя адрес 198.51.100.5 / 24 в качестве пункта назначения. Происходит следующее:

• В удаленном офисе хост 198.51.100.5 - это удаленный пункт назначения, доступный через VPN и маршрутизируемый туда.
• В удаленном офисе хост 192.0.2.5 маскируется как 203.0.113.5 при прохождении пакета функция NAT.
• В офисе, хост 198.51.100.5 преобразуется в 192.0.2.5, поскольку пакет передает функцию NAT.
• В офисе обратный трафик на хост 203.0.113.5 проходит через тот же процесс в обратном направлении.

Таким образом, пока есть решение, существует ряд проблем, которые необходимо решить, чтобы это работало на практике:

• Замаскированный IP-адрес должен использоваться для удаленного подключения; DNS становится сложным. Это связано с тем, что конечные точки должны иметь уникальный IP-адрес, если смотреть со стороны подключающегося хоста.
• Функция NAT должна быть реализована на обоих концах как часть решения VPN.
• Статическое сопоставление хостов является обязательным условием доступности для других конец.
• Если трафик является однонаправленным, только принимающей стороне требуется статическое отображение всех задействованных хостов; при желании клиент может обойтись без динамического преобразования NAT.
• Если трафик двунаправленный, на обоих концах требуется статическое сопоставление всех задействованных хостов.
• Подключение к Интернету не должно ухудшаться, независимо от разделения или без разделения VPN.
• Если вы не можете сопоставить один-к-одному, это становится беспорядочным; тщательный учет является необходимостью.
• Естественно, есть риск использования адресов NAT, которые также оказываются дубликатами: -)

Поэтому решение этой проблемы требует тщательного проектирования. Если ваш удаленный офис действительно состоит из «бродяг», вы добавляете слой проблем:

• они никогда не знают заранее, когда они заканчивают на перекрывающихся сетевых идентификаторах.
• шлюз удаленного офиса NAT должен быть реализован на их ноутбуках .
• офисному шлюзу потребуются две сети VPN, одна без NAT и одна с NAT, чтобы охватить оба сценария. В противном случае , если кто-то выберет одну из подсетей, выбранных вами для метода NAT, ничего не сработает .

В зависимости от вашего VPN-клиента вы можете иметь возможность автоматически выбирать одну или другую VPN в зависимости от сетевого адреса локального сегмента.

Обратите внимание, что все упоминания NAT в этом контексте обозначают функцию NAT, которая, так сказать, происходит в туннельной перспективе. В технологическом плане статическое преобразование NAT должно выполняться до того, как пакет «войдет» в туннель, то есть до того, как он будет инкапсулирован в транспортный пакет, который должен доставить его через Интернет на другой шлюз VPN.

Это означает, что нельзя. путайте общедоступные IP-адреса VPN-шлюзов (которые на практике также могут быть NAT, но тогда полностью выходят за рамки транспортировки на удаленный сайт через VPN) с уникальными частными адресами, используемыми в качестве маскировки для дублированных частных адресов. Если эту абстракцию трудно изобразить, то здесь можно проиллюстрировать, как NAT может быть физически отделен от шлюза VPN для этой цели:
Использование NAT в перекрывающихся сетях .

Сжатие той же картины до логического разделение внутри одной машины, способной выполнять функции как шлюза NAT, так и шлюза VPN, просто продвигает тот же пример на один шаг вперед, но делает больший акцент на возможностях имеющегося программного обеспечения. Взломать его вместе, например, с OpenVPN и iptables и опубликовать решение здесь было бы достойной задачей.

В программном отношении это определенно возможно:
PIX / ASA 7.x и более поздние версии: IPsec VPN LAN-to-LAN с перекрытием Пример конфигурации сети
и:
Настройка туннеля IPSec между маршрутизаторами с дублированными подсетями LAN

Фактическая реализация, таким образом, зависит от множества факторов, задействованных операционных систем, связанного программного обеспечения и его возможностей, не в последнюю очередь. Но это, безусловно, выполнимо. Вам нужно будет немного подумать и поэкспериментировать.

Я узнал об этом от Cisco, как видно по ссылкам.