Два клієнти OpenVPN на одному шлюзі Linux: поділіть політику

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

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

Вирішує ядро, а не демон

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

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

Дайте кожному екземпляру власний набір ресурсів

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

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

route-nopull тримає маршрути, які проштовхує сервер, поза локальною таблицею, і це саме те, що потрібно, коли таблиці політики мають бути явними. Чи проштовхує конкретний сервер також параметр redirect-gateway і чи підтримує ваша версія клієнта форму з фільтром, варто перевіряти за посібником, а не припускати.

Напишіть матрицю: джерело, таблиця, пристрій

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

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

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

Власний транспорт тунелю не в групі клієнтів

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

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

Вибір шляху не дає дозволу

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

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

Що відбувається, коли один тунель падає

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

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

Схожі статті