Это Канонический вопрос о разрешении конфликтов подсети IPv4 между локальной сетью VPN-клиента и сетью через VPN-канал от него.
После подключения к удаленному местоположению через OpenVPN клиенты пытаются получить доступ к серверу в сети, которая существует в такой подсети, как 192.0.2.0/24. Однако иногда сеть в локальной сети клиента имеет один и тот же адрес подсети: 192.0.2.0/24. Клиенты не могут подключиться к удаленному серверу, введя его IP-адрес из-за этого конфликта. Они не могут даже получить доступ к общедоступному Интернету при подключении к VPN.
Проблема в том, что эта подсеть 192.0.2.0/24 должна быть маршрутизирована через VPN, но она также должна быть маршрутизирована как клиентская LAN.
Кто-нибудь знает, как решить эту проблему? У меня есть доступ к серверу OpenVPN.
Если вам нужен временный грязный обходной путь для одного или нескольких известных IP-адресов сервера, самым простым решением должна быть опция статической маршрутизации на стороне клиента.
В моем случае я добавил желаемый целевой сервер (192.168.1.100) в свою таблицу маршрутизации на моем Linux-клиенте через:
route add 192.168.1.100 dev tun0
После этого удалите этот статический маршрут с помощью команды удаления маршрута.
Это можно решить с помощью NAT; это просто не очень элегантно.
Итак, предполагая, что вы не можете решить эту проблему, имея внутренние сети с настолько необычными номерами сетей, что никогда не вступают в конфликт, вот принцип:
Поскольку и локальная, и удаленная подсети имеют одинаковые номера сетей, трафик от вашего клиента никогда не поймет, что он должен пройти через туннельный шлюз, чтобы достичь места назначения. И даже если бы мы вообразили, что это возможно, ситуация для удаленного хоста будет такой же, когда он собирается отправить ответ.
Так что оставайтесь со мной и притворяйтесь, что пока нет побочных проблем, поскольку я пишу, что для полного подключения вам потребуется NAT на обоих концах внутри туннеля, чтобы различать хосты и разрешать маршрутизацию.
Делаем здесь сети:
Итак, внутри VPN-туннеля хосты офиса теперь 198.51.100.x, а хосты удаленного офиса - 203.0.113.x. Кроме того, давайте представим, что все хосты сопоставлены 1: 1 в NAT их соответствующих шлюзов VPN. Пример:
Поэтому, когда хост 192.0.2.5/24 в удаленном офисе хочет подключиться к хосту с тем же IP-адресом в офисной сети, ему необходимо сделать это, используя адрес 198.51.100.5/24 в качестве пункта назначения. Происходит следующее:
Таким образом, пока есть решение, есть ряд проблем, которые необходимо решить, чтобы оно работало на практике:
Поэтому решение этой проблемы требует тщательного проектирования. Если ваш удаленный офис действительно состоит из бригадиров, вы добавляете ряд проблем:
В зависимости от вашего VPN-клиента вы можете автоматически выбирать одну или другую VPN в зависимости от сетевого адреса локального сегмента.
Обратите внимание, что все упоминания NAT в этом контексте обозначают функцию NAT, которая, так сказать, имеет место в туннельной перспективе. В технологическом плане статическое сопоставление NAT должно выполняться до того, как пакет «войдет» в туннель, то есть до того, как он будет инкапсулирован в транспортный пакет, который должен доставить его через Интернет на другой шлюз VPN.
Это означает, что не следует путать общедоступные IP-адреса VPN-шлюзов (которые на практике также могут быть NAT: ed, но в этом случае полностью вне перспективы транспортировки на удаленный сайт через VPN) с уникальными частными адресами, используемыми как маскарады. для повторяющихся частных адресов. Если эту абстракцию сложно представить, то здесь можно проиллюстрировать, как NAT может быть физически отделен от шлюза VPN для этой цели:
Использование NAT в перекрывающихся сетях.
Сжатие одной и той же картины до логического разделения внутри одной машины, способной выполнять функции как шлюза NAT, так и шлюза VPN, - это просто продвижение того же примера на один шаг вперед, но при этом больший упор делается на возможности имеющегося программного обеспечения. Взломать его вместе, например, с OpenVPN и iptables и опубликовать решение здесь было бы достойной задачей.
Программно, конечно, возможно:
PIX / ASA 7.x и более поздние версии: LAN-to-LAN IPsec VPN с примером конфигурации перекрывающихся сетей
и:
Настройка туннеля IPSec между маршрутизаторами с дублирующимися подсетями LAN
Таким образом, фактическая реализация зависит от множества факторов, не в последнюю очередь от используемых операционных систем, связанного программного обеспечения и его возможностей. Но это, безусловно, выполнимо. Вам нужно будет немного подумать и поэкспериментировать.
Я узнал об этом от Cisco, как видно по ссылкам.
ага, это худшее. для меня это происходило постоянно из гостиничных номеров, прежде чем администраторы VPN поняли, что им следует использовать более неясные диапазоны IP. 10.0.0.0/24 и 10.1.1.1/24 хуже всех. Если вы можете помочь, никогда не используйте IP в такой беспроводной сети.
поэтому ответ - "исправить" wap, чтобы использовать другую внутреннюю сеть (например, 10.255.255.0/24), а затем дать вам аренду diff (т.е. ip в диапазоне, который может маршрутизировать обратно в корпоративный vpn), или если у вас нет / не могу получить администратора на wap, просто зайдите в Starbucks. или 20 минут вардрайтинга :)
если это только в лабораторных условиях, просто используйте другие диапазоны.
Я использую Mac под управлением El Capitan. Хотя приведенные выше предложения не сработали для меня, они привели меня к рабочему решению:
ifconfigзапустить 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
введите:
sudo route add 192.168.1.79 192.168.42.74
Сначала я тестировал ping а затем я доказал, что это работает, обратившись к серверу git.
Когда я пытался использовать dev ppp0 для конца команды маршрута, как упоминалось выше, он пожаловался.
У меня есть простое решение, которое я использую в коворкинге с конфликтующим диапазоном IP-адресов (10.x)
Я подключился к сети с помощью мобильного телефона, а затем поделился сетевым подключением через Bluetooth со своим ноутбуком. Теперь я могу использовать VPN для своего удаленного работодателя.
Я уверен, что это будет работать точно так же через USB, если вам нужно более быстрое соединение.
Ответ от Айдына К. предназначен для Linux. Если вам нужна такая же функциональность для окон, вы можете ввести
route ADD 192.168.1.10 <IP of tunnel adapter>
или
route ADD 192.168.1.10 IF <interface id>
вы можете получить идентификатор интерфейса с помощью команды:
route print
Если вам просто нужно выбрать несколько IP-адресов, добавьте оператор маршрута в файл конфигурации ovpn следующим образом:
маршрут 192.168.1.10 255.255.255.255
маршрут 192.168.1.11 255.255.255.255
Он добавит маршрут только для этих IP-адресов при подключении vpn и удалит его, когда vpn отключится.
Все равно работал у меня в Windows.
Напоминаем: вся эта проблема возникла из-за многолетней нехватки IPv4-адресов и широкого использования диапазон частных IP-адресов за NAT для обхода этой нехватки!
Идеальное и окончательное решение этой проблемы довольно простое (хотя это может и займет некоторое время для глобального развертывания): IPv6...
В мире IPv6 нет дефицита общедоступных IP (и не будет, событие через несколько десятилетий). Таким образом, нет причин не иметь общедоступный IP-адрес на каждом устройстве в каждой сети. А если вам нужна сетевая изоляция, продолжайте фильтровать с помощью брандмауэра, но без уродливого NAT ...