Два тунелі OpenVPN на одному хості Linux: кому належить маршрут?

Два профілі підключені, і один із них тихо несе трафік, призначений іншому. Хост Linux може запускати обидва OpenVPN-клієнти одночасно без труднощів. Чого він не може — вирішити за вас, який процес має право претендувати на який префікс. Це рішення треба ухвалити до того, як підніметься другий тунель, а не після того, як ресурс перестане відповідати.

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

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

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

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

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

Перекривані пули ламаються раніше за маршрутизацію

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

Погляньте й на локальну LAN. Домашня мережа з номером 192.168.1.0/24, яку теж відкриває один тунель, створює ту саму неоднозначність, а симптом — ім'я хоста, яке розв'язується, поки з'єднання так і не встановлюється. Це виглядає як збій розв'язання імен, доки ви не надрукуєте маршрути.

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

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

Дайте кожному профілю власний юніт, а кожному префіксу — власника

Кожен профіль отримує власне ім'я екземпляра й власний файл конфігурації, тож екземпляр з іменем office завантажує office.conf, а екземпляр з іменем lab — lab.conf. Підтвердьте це зіставлення через менеджер служб, а не довіряючи лістингу каталогу, оскільки drop-in може змінити, який файл завантажується. Помилка в зіставленні означає, що ви налаштовуєте профіль, який не працює.

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

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

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

Мітки утримують відповіді на тому інтерфейсі, звідки вони прийшли

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

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

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

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

Доведіть ізоляцію, зупинивши один канал

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

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

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