Один хаб OpenVPN, три мережі LAN: план адрес і файли iroute

Чотири неперетинні префікси, один маршрут ядра на філію, один iroute на власника. Порядок роботи для хаба на три майданчики, який тихо відмовляє, коли ім'я неправильне.

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

Виконуйте кроки по порядку. Кожен залежить від плану попереднього кроку, і жоден не потребує нового засвідчувального центру.

Почніть із плану, який нікому не треба вгадувати

Запишіть чотири неперетинні префікси, перш ніж торкатися файлу конфігурації: власна мережа LAN хаба, мережа LAN кожної філії та пул, який видають мандрівним клієнтам. Неперетинність — це те, що зберігає простоту всього іншого, бо перекривані діапазони перетворюють маршрутизацію на головоломку найдовшого збігу, яку не виправить жодна конфігурація для окремих клієнтів. Потім підтвердьте, яка машина є шлюзом за замовчуванням для кожної мережі LAN, оскільки маршрутизатору філії, що не є шлюзом власної мережі, потрібно встановлювати віддалені маршрути зовсім в іншому місці. Насамкінець закріпіть автентифіковані імена, що ідентифікують кожну філію, бо саме ці імена є ключами, за якими шукають файли для окремих клієнтів.

Ілюстративний план тримає пул далеко від трьох мереж LAN. Ваш буде іншим, і єдине жорстке правило — жодні два діапазони не перекриваються.

Hub LAN        172.20.0.0/24
Branch A LAN   172.21.0.0/24
Branch B LAN   172.22.0.0/24
VPN pool       10.77.0.0/24

identity branch-a owns 172.21.0.0/24
identity branch-b owns 172.22.0.0/24

Скажіть ядру хаба, де розташовані філії

Хабу потрібні дві відомості на кожну філію: маршрут ядра, який надсилає префікс у тунельний пристрій, і запис iroute, що повідомляє процесу OpenVPN, який клієнт ним володіє. Лише маршрут ядра доставляє пакети в тунель і на цьому зупиняється, бо демон усе ще має вирішити, який вузол повинен їх отримати. Лише запис iroute залишає ці пакети в ядрі без маршруту, яким можна йти. Обидва рядки належать конфігурації, яку демон справді завантажує, і це варто перевірити, перш ніж зневаджувати будь-що інше.

dev tun
topology subnet
server 10.77.0.0 255.255.255.0
disable-dco

route 172.21.0.0 255.255.255.0
push "route 172.20.0.0 255.255.255.0"
client-config-dir /etc/openvpn/ccd
route 172.22.0.0 255.255.255.0

Тримайте client-to-client вимкненим, коли ядро має бути точкою застосування правил. Ця опція передає трафік між вузлами всередині демона, що зручно і водночас означає, що ваші правила пересилання ніколи не бачать потік. Усе нижче припускає, що ядро бачить кожен пакет між філіями.

Дайте кожній філії потрібні маршрути

Кожній філії потрібні маршрути до інших філій і до мережі LAN хаба, а маршрут до власної під'єднаної мережі їй не потрібен. Проштовхуйте віддалені префікси з хаба, а не вклеюйте їх у кожен маршрутизатор, щоб четвертий майданчик згодом означав один новий файл на клієнта замість чотирьох правок. Файл на клієнта містить також рядок iroute, який тримає власність і оголошення в одному місці. Зробіть каталог і його файли читабельними згідно з моделлю привілеїв сервера, інакше пошук завершиться невдачею без повідомлення.

# /etc/openvpn/ccd/branch-a
iroute 172.21.0.0 255.255.255.0
push "route 172.22.0.0 255.255.255.0"

Четвертий майданчик дотримується тієї самої схеми: окреме автентифіковане ім'я, власний префікс, маршрут ядра на хабі, запис iroute і оголошення лише тим майданчикам, яким дозволено до нього дістатися.

Перевірте в обидва боки, перш ніж вважати готовим

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

Перевірте з хоста в мережі LAN однієї філії до сервісу в іншій, потім змініть напрямок, потім перевірте з філії до мережі LAN хаба. Ці три результати — різні докази, і жоден не передбачає інших. Якщо маршрутизатор філії не є шлюзом за замовчуванням її мережі, встановіть віддалені префікси на справжньому шлюзі та включіть також пул, коли тунельним клієнтам потрібно починати з'єднання в цю мережу.

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

Проєкт тримається купи, бо кожен шар має одне завдання: план зберігає унікальність префіксів, маршрут ядра переміщує пакети, iroute називає власника, а міжмережевий екран вирішує, що дозволено. Коли щось ламається, цей список — ще й порядок перевірки.

Схожі статті