Дві службові адреси на одному клієнті OpenVPN: iroute і lo

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

Псевдонім локальний, володіння віддалене

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

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

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

Додайте адресу на клієнті постійно

Розмістіть службову адресу на loopback з префіксом хоста, щоб хост вважав її локальним вводом, а не підмережею, до якої треба дістатися. ip address add 10.66.0.10/32 dev lo робить це для однієї адреси, а повторення команди для другої адреси моделює дві служби.

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

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

Зажадайте її у файлі CCD, який концентратор справді читає

На сервері декларація володіння потрапляє у файл окремого клієнта, який вибирається автентифікованим спільним ім’ям, усередині каталогу, названого в client-config-dir. Рядок — iroute 10.66.0.10 255.255.255.255, по одному на адресу, і він каже серверу, який партнер має отримувати трафік для цього призначення.

Дві деталі ламають це тихо. Ім’я файлу має збігатися з ім’ям, яке сервер справді використовує, а воно відрізняється, коли задіяно username-as-common-name. І iroute діє лише в режимі TUN із налаштованим каталогом конфігурації клієнта, тому той самий рядок нічого не робить у мостовому розгортанні. Додавайте рядки до наявного файлу, а не замінюйте його, бо він може вже містити фіксовану адресу або параметри push. Довідник OpenVPN 2.6 документує і каталог, і директиву володіння.

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

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

Перевірте політику вводу та зворотний шлях

Пакет, адресований псевдоніму, приходить на хост-володілець як локальний ввід, тож питання в тому, чи дозволяє локальний міжмережевий екран це джерело й порт. Дозвольте конкретний порт служби з діапазону джерел VPN замість відкриття всієї адреси.

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

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

Тестуйте адреси й володіння окремо

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

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