Чому підмережа за клієнтом OpenVPN недоступна?

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

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

Сервер маршрутизує за клієнтом, а не за інтерфейсом

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

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

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

Записати запис iroute, який називає клієнта

iroute живе у конфігураційному файлі конкретного клієнта, а не в основній конфігурації сервера. Спрямуйте сервер на каталог опцією client-config-dir, потім створіть файл, ім'я якого збігається із загальним іменем сертифіката клієнта, і покладіть туди префікс.

Для філії, чия LAN — 10.20.0.0/24, а загальне ім'я сертифіката — branch-router, файл за цим шляхом містить рядок на кшталт iroute 10.20.0.0 255.255.255.0. Основній конфігурації потрібна лише опція каталогу; префікс живе у клієнта.

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

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

Побудова зворотного шляху в обох напрямках

Доставка пакетів у віддалену LAN — половина роботи. Клієнт також має надсилати трафік цієї LAN у тунель, що зазвичай робиться проштовхуванням маршруту клієнту: рядок на кшталт push "route 10.8.0.0 255.255.255.0" повідомляє кожному клієнту, як дістатися мережі на боці сервера. Для філії еквівалентний маршрут вказує в тунель для всього, чого вона має досягти на боці сервера.

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

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

Перевірка доступності правильними пробами

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

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

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