Хто має володіти маршрутами та DNS, коли openfortivpn підключається?

У робочій сесії openfortivpn чотири етапи накладаються один на одного. Клієнт автентифікується на шлюзі й починає TLS-з'єднання, потім запускає PPP усередині цього з'єднання, потім отримує адресу й відомості DNS і нарешті застосовує маршрути хоста та налаштування резолвера. Кожен етап може бути живим, поки наступний ні, і тому «підключено» — таке слизьке слово в гілках підтримки.

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

Чотири етапи, що виглядають як одне з'єднання

Перший етап — допуск. іменований домен автентифікації або одноразовий код, і отримує параметри, потрібні для продовження. Коли клієнт друкує, що він підключений до шлюзу, це означає, що транспорт TLS працює. Це не означає, що PPP домовився, і вже точно не означає, що внутрішній застосунок доступний.

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

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

Хто редагує таблицю маршрутизації

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

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

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

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

Хто володіє DNS і файлом резолвера

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

На сучасному хості Linux резолвером може керувати локальний stub, і перезапис файлу резолвера за спиною цього stub створює конфігурацію, яка виглядає правильною й поводиться непослідовно. Якщо хост уже запускає менеджер резолвера, дозвольте йому володіти DNS і передайте йому сервери тунелю через його підтримуваний інтерфейс. Параметр no-dns клієнта — правильний вибір там, а не обхідний шлях.

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

Права, готовність і передача

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

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

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