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

Это канонический вопрос о разрешении конфликтов подсети IPv4 между локальной сетью VPN-клиента и одной из них по каналу VPN-подключения от него.

После подключения к удаленному расположению через OpenVPN клиенты пытаются получить доступ к серверу в сети, которая существует в подсети, такой как 192.0.2.0/24. Однако иногда сеть в локальной сети клиента имеет один и тот же адрес подсети: 192.0.2.0/24. Из-за этого конфликта клиенты не могут подключиться к удаленному серверу, введя его IP-адрес. Они не могут даже получить доступ к общедоступному Интернету, когда подключены к VPN.

Проблема заключается в том, что эта подсеть 192.0.2.0/24 должна маршрутизироваться VPN, но также маршрутизироваться как локальная сеть клиента.

Кто-нибудь знает, как смягчить эту проблему? У меня есть доступ к серверу OpenVPN.

Это можно решить с помощью 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, как видно по ссылкам.

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

В моем случае я добавил желаемый целевой сервер (192.168.1.100) в свою таблицу маршрутизации на моем клиенте Linux через:

route add 192.168.1.100 dev tun0

После этого удалите этот статический маршрут с помощью команды route delete.

да это худшее. для меня это происходило все время из гостиничных номеров, прежде чем администраторы vpn поняли, что им следует использовать более неясные диапазоны ip. 10.0.0.0/24 и 10.1.1.1/24 - худшие. если вы можете помочь, то никогда не делайте ip-соединение с такой беспроводной сетью.

поэтому ответ «исправить» wap, чтобы использовать другую внутреннюю сеть (например, 10.255.255.0/24), а затем дать вам аренду diff (то есть ip в диапазоне, который может перенаправить обратно в corp vpn), или если у вас нет / не могу получить админ на WAP, просто зайдите в Starbucks. или 20 минут вождения :)

если это просто в лабораторных условиях, просто используйте разные диапазоны.

Я работаю на эль Капитан. Хотя приведенные выше предложения не помогли мне, они привели меня к рабочему решению:

1. перед запуском VPN выполните ifconfig

2. запустите VPN, сделайте ifconfigи отметьте, какой новый интерфейс. В моем случае это был ppp0 с IP-адресом 192.168.42.74

   ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
       inet 192.168.42.74 --> 192.0.2.1 netmask 0xffffff00
   

3. введите:

   sudo route add 192.168.1.79  192.168.42.74
   

Сначала я проверил с помощью a, pingа затем доказал, что он работает, получив доступ к git-серверу.

Когда я попытался использовать dev ppp0 для конца команды route, как упоминалось выше, он жаловался.

У меня есть простое решение, которое я использую в рабочей области с конфликтующим диапазоном IP-адресов (10.x)

Я подключился к сети с моего мобильного телефона, затем я поделился сетевым подключением через Bluetooth с моим ноутбуком. Теперь я могу использовать VPN для моего удаленного работодателя.

Я уверен, что это будет работать точно так же через USB, если вам нужно более быстрое соединение.

Если вам просто нужно набрать один или два IP-адреса, добавьте инструкцию route в ваш файл конфигурации ovpn следующим образом:

Маршрут 192.168.1.10 255.255.255.255

Маршрут 192.168.1.11 255.255.255.255

Он добавит маршрут только для тех Ip'ов, когда вы подключите свой vpn, и удалите его, когда vpn отключил.

У меня все равно работало на Windows.

Ответ Айдына К. для linux. Если вы хотите одинаковую функциональность для окон, вы можете набрать

route ADD 192.168.1.10 <IP of tunnel adapter>

или

route ADD 192.168.1.10 IF <interface id>

Вы можете получить идентификатор интерфейса с помощью команды:

route print

Напомним, что эта проблема вызвана нехваткой адресов IPv4 в течение многих лет и широким использованием частного IP-диапазона за NAT для решения этой проблемы!

Идеальное и окончательное решение этой проблемы довольно простое (хотя оно может и будет занимать некоторое время для глобального развертывания): IPv6 ...

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