Один Pi, два екземпляри OpenVPN: що читає кожен модуль
Два демони OpenVPN на одному Pi читають різні файли конфігурації й виходять через різні перехоплювачі. Зіставте кожен екземпляр, а потім окремо перевірте шлях корисного навантаження.
Порахуйте процеси OpenVPN, перш ніж торкатися профілю. Pi, який приймає роумінгових користувачів і водночас під'єднується до вищого сервісу, запускає два демони, і кожен читає файл конфігурації, вибраний набраним вами іменем екземпляра. Шаблони пакета потім дають кожному демону власний робочий каталог, власний файл стану виконання й власний тунельний пристрій. Якщо розділити це неправильно, ви проведете вечір, змінюючи правильне налаштування у файлі, який робочий процес ніколи не відкриває.
Кожне ім'я екземпляра вибирає свій файл
У файлах модулів, що постачаються з OpenVPN 2.6, аргументи запуску містять підстановку екземпляра, яка заповнюється текстом після знака @. Шаблон сервера працює з каталогу конфігурації сервера й розв'язує свій аргумент щодо %i.conf там, а шаблон клієнта робить те саме з каталогу клієнта. Тому [email protected] читає admits.conf у каталозі сервера, а [email protected] читає uplink.conf у каталозі клієнта, і жодне з цих імен не має ніякого сенсу в іншому каталозі.
Перевірте відповідність на самій машині, а не припускайте, що пакет зберіг вищі значення за замовчуванням. Drop-in дистрибутива може повністю замінити робочий каталог або аргумент конфігурації.
systemctl cat [email protected]
systemctl cat [email protected]Прочитайте рядок WorkingDirectory і аргумент конфігурації в цьому виводі, бо лише ввімкнений модуль вирішує, який файл завантажується. Drop-in, що додає --config до ExecStart, перемагає шаблон навіть тоді, коли шлях шаблону виглядає правильним. Запитуйте шляхи фрагментів і drop-in, коли хочете знати, чи діє локальне перевизначення. Якщо обидві ролі розв'язуються в один файл, у вас один процес, який намагається бути і сервером, і клієнтом, і пізніший параметр у цьому файлі тихо перемагає.
Локальний транспорт і переспрямоване навантаження потрапляють у різні перехоплювачі
Зашифроване з'єднання сервера з кожним роумінговим користувачем створюється на самому Pi, тому його зовнішні відповіді виходять через локальний перехоплювач виводу. З'єднання клієнта з його вищим партнером теж є локально створеним виводом, хоча й досягає віддаленої мережі. Переспрямоване корисне навантаження — третя категорія, і ядро зіставляє його лише після того, як уже вибрало вихідний пристрій для пакета.
| Flow | Hook that sees it | What to inspect |
|---|---|---|
| Roaming user handshakes to the server | Local input and local output | Listener socket, bind address, rule admitting the UDP port |
| User payload leaving through the upstream tunnel | Forward | IPv4 forwarding switch, selected route, permission rule, any translation |
| Pi's own connection to the upstream peer | Local output | Underlay route to the provider endpoint, not the tunnel route |
Правило, що зіставляє вихідний інтерфейс усередині ланцюжка forward, може дозволити або відкинути пакет, який маршрутизація вже призначила цьому інтерфейсу, але воно ніколи не вибирає інтерфейс. Коли один вузол завершує один тунель і починає інший, політика, що надсилає користувацьке навантаження у вищий тунель, і політика, що захищає власні зашифровані відповіді Pi, — два окремі рішення. Вони випадково опиняються на одній фізичній мережевій картці, тому їх плутають.
Ця різниця пояснює частий частковий збій. Користувачі під'єднуються, рукостискання завершується, а їхній трафік усе одно виходить не туди, бо рукостискання було локальним, навантаження — переспрямованим, і перевірено було лише одне з двох.
Імпортований маршрут може проковтнути відповіді вашим користувачам
Налаштування безпеки клієнтського профілю вирішує, що вища сторона може проштовхнути в таблицю маршрутизації Pi, і широке переспрямування — це варіант, який перетворює робочий вузол із двома ролями на зламаний. Якщо проштовхнутий маршрут охоплює публічні адреси роумінгових користувачів, відповіді, які сервер створює для них, можуть піти новим маршрутом у вищий тунель замість виходу через нижній рівень. Люди часто переконуються, що тунель до провайдера ще працює, і на цьому зупиняються, бо цей трафік — власний транспорт тунелю, і він продовжує текти, поки все інше поводиться неправильно.
Політика на основі джерела або мітки — це спосіб тримати два потоки окремо. Опція mark Linux в OpenVPN позначає власні зашифровані пакети демона міткою міжмережевого екрана, яку правило маршрутизації потім може надіслати в окрему таблицю. Адреси джерела працюють так само добре, коли зовнішні відповіді сервера завжди виходять з однієї адреси нижнього рівня. Будь-який підхід потребує дійсних маршрутів у вибраній таблиці й винятку для точки присутності провайдера, інакше сам тунель більше не піднімається.
Перш ніж писати хоч одне правило, запитайте в ядра, який шлях відповідь справді обере. Адреси нижче — заповнювачі для адреси нижнього рівня Pi та публічної адреси одного роумінгового користувача.
ip rule show
ip route get 198.51.100.7 from 192.0.2.10Перевірте поділ, потім зупиняйте по одній ролі
Перевіряйте три потоки окремо, бо робоче рукостискання нічого не доводить про два інші. Прийміть нове вхідне з'єднання, надішліть один дозволений застосунок через вищий вихід і переконайтеся, що обидва процеси досі досягають своїх партнерів.
Потім зупиніть роль клієнта й подивіться, що зберігає роль сервера. Це найдешевший спосіб знайти правило маршруту або мітки, яке призначалося одному екземпляру, а застосувалося до обох.
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerВи хочете побачити, що слухач досі прив'язаний, тунельний пристрій на місці, а журнал вільний від нових помилок, поки роль клієнта зупинена. Якщо зупинка клієнта обриває й відповіді сервера наявним користувачам, дві ролі поділяють щось, що мало бути обмежене однією з них. Записуйте, якого екземпляра, якого файлу конфігурації й якого власника потоку торкнулася кожна зміна, інакше наступна людина, що налагоджуватиме цей вузол, повторить те саме відкриття з нуля.