Що OpenVPN route-nopull насправді заважає серверу надіслати

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

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

Що прапорець вимикає під час з'єднання

Клієнт OpenVPN, що працює в режимі отримання налаштувань, зазвичай після автентифікації бере від сервера пакет: маршрути, перенаправлення шлюзу за замовчуванням, сервери DNS і кілька директив тонкого налаштування. Коли route-nopull увімкнено, клієнт усе одно приймає сеанс, усе одно перевіряє сертифікати, усе одно узгоджує шифри й keepalive та все одно піднімає інтерфейс. Що він відкидає, то це застосування надісланих рядків route і надісланих рядків dhcp-option, включно з DNS.

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

Чому живий тунель усе одно може нікуди не маршрутизувати

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

Тому читання профілю доводить дуже мало. Натомість прочитайте робочий стан на з'єднаній машині:

ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10

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

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

Вибір між прапорцем і фільтром за префіксом

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

pull-filter це зіставлювач префіксів із трьома дієсловами, тож він може прийняти родину рядків, тихо їх проігнорувати або взагалі відкинути з'єднання, коли з'являється префікс. Варто знати саме про останню поведінку: правило відхилення перетворює розбіжність у політиці на невдале рукостискання, а не на тихий пропуск. Посібник OpenVPN 2.6 перелічує прийняті префікси й точну семантику кожного дієслова.

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

Додавання маршрутів і резолвера вручну

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

route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53

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

resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.com

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

Перевірка результату: адреса, ім'я та зовнішній шлях

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

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

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