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


35

Це канонічне запитання щодо вирішення конфліктів підмережі IPv4 між локальною мережею VPN-клієнта та мережею через посилання VPN.

Після підключення до віддаленого місця через OpenVPN, клієнти намагаються отримати доступ до сервера в мережі, який існує в підмережі, наприклад 192.0.2.0/24. Однак іноді мережа в локальній мережі клієнта має однакову адресу підмережі: 192.0.2.0/24. Через цей конфлікт клієнти не можуть підключитися до віддаленого сервера через введення IP-адреси. Вони не можуть навіть отримати доступ до загальнодоступного Інтернету під час підключення до VPN.

Проблема полягає в тому, що ця підмережа 192.0.2.0/24 повинна бути маршрутизована VPN, але вона також повинна бути маршрутизована як локальна мережа клієнта.

Хтось знає, як пом’якшити це питання? У мене є доступ до сервера OpenVPN.


3
Ви можете спробувати встановити статичний маршрут для / 32 адреси хоста, до якого ви намагаєтесь досягти та використовувати одноранговий VPN як свій шлюз, і подивитися, що відбувається.
SpacemanSpiff

якщо концентратор vpn шанує клієнтські маршрути, то, можливо, вам знадобиться допомога по периметру. Я отримую доступ до облікової мережі, додаю маршрут до інженерного діапазону, і тоді я можу підключитися без проблем. хитрі брандмауери, як sonicwall, роблять це
nandoP

@SpacemanSpiff: Хоча це може вирішити проблему на стороні клієнта, сервер все ще не зможе відповісти, оскільки він бачить, що з'єднання надходить із власної мережі, а не від VPN-клієнта.
Массімо

Відповіді:


18

Це можна вирішити за допомогою NAT; це просто не дуже елегантно.

Отже, за припущенням, ви не могли цього вирішити, маючи внутрішні мережі, які мають настільки незвичайні мережеві номери, що ніколи насправді не вступають у конфлікт, ось такий принцип:

Оскільки локальна та віддалена підмережа мають однакові номери мережі, трафік від вашого клієнта ніколи не зрозуміє, що він повинен пройти через тунельний шлюз, щоб досягти місця призначення. І навіть якщо ми можемо уявити, що це могло б, ситуація була б такою ж, як для віддаленого хоста, як саме він збирається надіслати відповідь.

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

Створення тут сіток:

  • Ваша офісна мережа використовує 192.0.2.0/24
  • Ваш віддалений офіс використовує 192.0.2.0/24
  • Шлюз VPN мережі вашого офісу ховає 192.0.2.0/24 хостів за NATED мережевим номером 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.
  • Статистичне відображення хостів є необхідним для досяжності з іншого кінця.
  • Якщо трафік є односпрямованим, тільки приймаючий кінець потребує статичного відображення всіх залучених хостів; клієнт може піти від того, що він бажано динамічно НАТАТИВАТИ, якщо бажано.
  • Якщо трафік двосторонній, обом кінцям потрібно статичне відображення всіх залучених хостів.
  • Підключення до Інтернету не повинно бути порушене незалежно від розділеного або нерозбитого VPN.
  • Якщо ви не в змозі зіставити карту 1 на 1, вона стає брудною; ретельна бухгалтерія - необхідність.
  • Природно, ризикує використовувати NAT-адреси, які також виявляються дублікатами :-)

Тому для вирішення цього потрібен ретельний дизайн. Якщо ваш віддалений офіс насправді складається з дорожніх воїнів, ви додасте в цьому шар проблем:

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

Залежно від вашого 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, як це видно за посиланнями.


Чи може NAT працювати також з багатьма VPN-підключеннями та їх перекладами? Я тут не зовсім зрозумів випадок. У мене тут нитка unix.stackexchange.com/q/284696/16920 про те, як робити VPN від сайту до сайту з перекриваються підмережами Unix-Way?
Лео Леопольд Герц 준영

17

Якщо вам потрібен тимчасовий брудний спосіб вирішення одного або декількох відомих серверів ips, найпростішим рішенням повинен стати параметр статичної сторони клієнта.

У моєму випадку я додав потрібний сервер призначення (192.168.1.100) до таблиці маршрутизації на моєму клієнті Linux через:

route add 192.168.1.100 dev tun0

Після цього видаліть цей статичний маршрут за допомогою команди delete маршрут.


2
Це ідеальне рішення та навіть ідеальний термін! :)
Yuval A

Як довго це зберігається? Поки ви не відключите? До перезавантаження?
карбокація

1
У моїй системі Linux (xfce з ubuntu / mint) налаштування "втрачаються" після відключення vpn та так, і після перезавантаження. Ви можете перевірити, чи налаштування активне за допомогою команди маршруту (там буде запис із ip та пристроєм tun0, як правило, внизу)
Айдін К.

Версія OSX для маршруту сприймає інтерфейс інакше, тому замість цього dev tun0вам потрібно-interface tun0
Sirens

5

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

тож відповідь - "виправити" wap для використання іншої внутрішньої мережі (тобто 10.255.255.0/24), а потім дасть вам різну оренду (тобто ip в діапазоні, який може перейти назад до corp vpn), або якщо у вас немає / не можу отримати адміністратора на wap, просто перейдіть до Starbucks. або 20 хвилин догляду :)

якщо це просто в лабораторних умовах, просто використовуйте різні діапазони.


Данг справді? Немає кращого варіанту?
Джон Рассел

1
не те, що я знаю .... це завжди була проблемою ... схоже, що хтось заперечив мою відповідь, але насправді не пропонував рішення .... ха вбий посланця!
nandoP

3

Я на Mac, що працює під керуванням El Capitan. Хоча запропоновані вище пропозиції для мене не спрацювали, вони привели мене до робочого рішення:

  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 для закінчення команди маршруту, як згадувалося вище, він скаржився.


2
З чого 192.168.1.79виходить цей обмін?
карбокація

Сервер призначення, до якого ви підключаєтесь. Цей сервер знаходиться в тій самій мережі, що і ваша VPN, а не локальне з'єднання.
Карло дель Мундо

1

У мене є просте рішення, яке я використовую в просторі для співпраці, який має суперечливий діапазон IP (10.x)

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

Я впевнений, що це буде працювати так само через USB, якщо вам потрібно швидше з'єднання.


1
Гей, це насправді досить розумне рішення.
Натан Осман

1

Якщо вам просто потрібно натиснути декілька однієї або двох ip-адрес, додайте виписку маршруту до свого файлу конфігурації ovpn таким чином:

маршрут 192.168.1.10 255.255.255.255

маршрут 192.168.1.11 255.255.255.255

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

Працював для мене в Windows в будь-якому випадку.


1

Відповідь Айдіна К. призначена для Linux. Якщо ви хочете однакову функціональність для Windows, ви можете набрати

route ADD 192.168.1.10 <IP of tunnel adapter>

або

route ADD 192.168.1.10 IF <interface id>

ви можете отримати ідентифікатор інтерфейсу за допомогою команди:

route print

0

Як нагадування: вся ця проблема пов’язана з роками нестачі адрес IPv4 та широким використанням приватного діапазону IP позаду NAT для усунення цього дефіциту!

Ідеальне і остаточне вирішення цього питання є досить простим (хоча воно може, і буде, потребує певного часу, щоб бути глобально розгорнутим): IPv6 ...

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.