Это можно решить с помощью NAT; это просто не очень элегантно.
Таким образом, в предположении, что вы не можете решить эту проблему, имея внутренние сети, которые имеют настолько необычные номера сетей, что никогда не вступают в конфликт, вот принцип:
Поскольку как локальная, так и удаленная подсети имеют идентичные номера сети, трафик от вашего клиента никогда не поймет, что он должен пройти через туннельный шлюз, чтобы достичь пункта назначения. И даже если мы представим, что это возможно, ситуация для удаленного хоста будет такой же, как и при отправке ответа.
Поэтому оставайтесь со мной и делайте вид, что пока нет побочных проблем, так как я пишу, что для полного подключения вам потребуется NAT с обоих концов внутри туннеля, чтобы дифференцировать хосты и обеспечить маршрутизацию.
Делаем несколько сетей здесь:
- Ваша офисная сеть использует 192.0.2.0/24
- Ваш удаленный офис использует 192.0.2.0/24
- Шлюз VPN вашей офисной сети скрывает 192.0.2.0/24 хоста за номером сети NAT 198.51.100.0/24
- VPN-шлюз удаленной офисной сети скрывает 192.0.2.0/24 хоста за номером сети NATed 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 в NAT шлюза vpn офиса
- Хост удаленного офиса 192.0.2.5/24 статически сопоставлен как 203.0.113.5/24 в NAT удаленного офиса шлюза vpn
Поэтому, когда хост 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 разделенной или неразделенной.
- Если вы не можете отобразить 1-к-1, это будет грязно; тщательная бухгалтерия является необходимостью.
- Естественно, существует риск использования адресов NAT, которые также оказываются дубликатами :-)
Таким образом, решение этого требует тщательного проектирования. Если ваш удаленный офис действительно состоит из дорожных воинов, вы добавите в него ряд проблем:
- они никогда не знают заранее, когда они заканчивают на перекрывающихся сетевых идентификаторах.
- NAT шлюза удаленного офиса должен быть реализован на их ноутбуках.
- офисному шлюзу потребуются две VPN, одна без NAT и одна с NAT, чтобы покрыть оба сценария. В противном случае, если кто-то выберет одну из подсетей, выбранных вами для метода NAT, ничего не получится .
В зависимости от вашего VPN-клиента вы можете автоматически выбрать одну VPN-сеть или другую в зависимости от сетевого адреса локального сегмента.
Заметьте, что все упоминания NAT в этом контексте обозначают функцию NAT, которая, так сказать, имеет место в перспективе туннеля. В процессе статическое преобразование NAT должно быть выполнено до того, как пакет «войдет» в туннель, то есть до того, как он будет инкапсулирован в транспортный пакет, который должен передать его через Интернет на другой VPN-шлюз.
Это означает, что не следует путать общедоступные IP-адреса шлюзов VPN (которые на практике также могут быть NAT: ed, но в то же время полностью вне перспективы передачи на удаленный сайт через VPN) с уникальными частными адресами, используемыми в качестве маскарадов. для дублирования частных адресов. Если эту абстракцию трудно изобразить, иллюстрация того, как NAT может быть физически отделена от шлюза VPN для этой цели, сделана здесь:
Использование NAT в перекрывающихся сетях .
Сжатие одного и того же изображения в логическом разделении внутри одной машины, способной выполнять функции шлюза NAT и VPN, просто делает тот же пример на шаг вперед, но при этом делает больший акцент на возможностях программного обеспечения под рукой. Взломать его вместе с, например, OpenVPN и iptables и опубликовать здесь решение было бы достойной задачей.
Программно это, безусловно, возможно:
PIX / ASA 7.x и более поздние версии
: пример IPsec VPN от локальной сети к локальной сети с перекрывающимися сетями и пример :
настройка туннеля IPSec между маршрутизаторами с дублирующимися подсетями локальной сети
Таким образом, фактическая реализация зависит от множества факторов, операционных систем, сопутствующего программного обеспечения и его возможностей, что немаловажно. Но это, безусловно, выполнимо. Вам нужно подумать и немного поэкспериментировать.
Я узнал об этом от Cisco, как видно по ссылкам.