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