Який компонент насправді володіє лімітом маршрутів OpenVPN?
Ліміт маршрутів може належати рушію OpenVPN, плагіну NetworkManager або серверу. Назвіть власника, перш ніж редагувати профіль чи піднімати число.
Профіль із двомастами маршрутами працює на одній машині й встановлює сорок на іншій. Рушій, інтеграція, що його запускає, і сервер, що його живить, мають кожен свій голос, і кожен може зупинити список у різній точці. Прочитання збою як одного ліміту веде вас до не того файлу. Механізм має три етапи, і етап, що зупинився, залишає видимі сліди, коли ви знаєте, що шукати.
Три етапи, три різні ліміти
Спершу рушій розбирає параметр і вирішує, чи розуміє його ця версія. Далі інтеграція встановлює те, що повідомляє рушій, і її власний код може обмежити або переформувати список. Насамкінець сервер вирішує, скільки маршрутів він надішле певній сутності, перш ніж якийсь клієнтський етап щось побачить. Три етапи, три стелі, і лише одна з них — число в профілі.
Підняття однієї стелі нічого не робить для інших. Відхилений надісланий маршрут може бути рішенням політики на сервері, перекриттям, яке вирішив клієнт, або лімітом інсталятора, що відкинув надлишок. Кожен із цих випадків має інше виправлення.
Розділіть ці три, перш ніж щось міряти. Помилка розбірника називає токен, ліміт інсталятора залишає коротку таблицю маршрутів, а рішення політики не залишає нічого. Сліди підказують, який етап перевіряти першим.
| Stage | Who decides | What you can see |
|---|---|---|
| Parse | Client engine | An error naming the option |
| Install | Activation owner | A route count below the pushed count |
| Offer | Server policy | A route absent from the pushed list |
Розбірник говорить першим
Невідомий параметр падає гучно й рано, а текст помилки називає токен. Це найлегший для розпізнавання етап: порівняйте точне повідомлення зі встановленою версією рушія, бо параметр, доданий в одному випуску, невідомий у попередньому. Профіль, скопійований із новішого розгортання, — звичайне джерело цієї розбіжності. Розбірник ніколи не ігнорує мовчки директиву, якої не впізнає.
Прийнятий параметр нічого не каже про результат. Розбір проходить, а список усе одно може бути обрізаний інсталятором або взагалі не запропонований сервером. Вважайте чистий розбір дозволом продовжувати, а не доказом.
Запишіть рядок версії з бінарника, який справді працював, а не з уявлення менеджера пакетів про те, що встановлено. Ці двоє розходяться частіше, ніж очікується.
В інсталятора своя стеля
Компонент, що володіє активацією, може бути плагіном NetworkManager, а не бінарником рушія, і він може нав'язати власний ліміт ще до появи будь-якого тунелю. Його редактор може показувати поле, яке чинний рушій ніколи не читає, або читати поле, яке редактор не показує. Обидві ситуації ззовні виглядають як помилка клієнта. Жодну не виправляє редагування профілю.
Лічіть те, що прийшло, а не те, що було налаштовано. Команда ip route show dev tun0 перелічує встановлені маршрути, і порівняння цього числа з надісланим списком відокремлює відкинутий маршрут від того, який ніколи не надсилався. Число, що збігається з надсиланням, повертає підозру серверу.
Обгортка-скрипт навколо бінарника рушія, щоб вичавити більше число, затуманює оновлення й перетворює відкат на здогад. Вона також ховає справжній ліміт від кожного, хто прочитає конфігурацію наступним.
Сервер вирішує, що вам запропонували
Політика для кожного клієнта може зменшити список до передавання. Файл, специфічний для клієнта, може додати маршрути для однієї сутності, або групова політика може їх пропустити, і клієнт не може відрізнити відфільтрований маршрут від того, який ніколи не визначався. Саме ця неоднозначність робить запис сервера важливим. Просіть фактичний список надсилання для цієї сутності, а не шаблон.
Порівняйте запис сервера з отриманим списком. Розрив між ними — це шар політики, і зазвичай він менший, ніж підказує профіль.
Коли проєкт це дозволяє, узагальнюйте суміжні мережі та видаляйте застарілі записи. Менше й більші маршрути вирішують більше випадків, ніж вища стеля.
Змініть число в правильному місці
Використовуйте документоване налаштування компонента, який справді володіє лімітом. Якщо поля немає в плагіні, перевірте, чи плагін старіший за можливість або чи маршрутами володіє інша основа. Потім запишіть версії рушія, плагіна й сервера поряд із вибраним значенням. Наступне оновлення знову відкриває питання, і саме нотатка робить його вирішуваним.
Перевіряйте знову після кожного оновлення будь-чого з трьох. Ліміт, піднятий у правильному місці, усе одно зсувається, коли змінюється компонент, що його застосовує. Запис версій — єдине, що робить цей зсув передбачуваним.