vpn.persistent продовжує намагатися, але не тримає вас підключеними

NetworkManager надає одну властивість, vpn.persistent, і люди просять її одночасно відповідати на чотири різні питання. Її документація вищого рівня обережна: стійкість діє, коли служба VPN її підтримує і профіль її вмикає, і тоді з'єднання просять пережити зміни каналу та збої аж до явного відключення. Та сама документація показує, що типове значення властивості — false, а це не те, що припускає більшість планів відновлення. Читайте це як прохання про спробу, а не як обіцянку результату.

До чого налаштування справді зобов'язує

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

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

Ставлення до властивості як до спроби задає і правильне очікування від тестування. Ви перевіряєте не те, чи встановлено прапорець; ви перевіряєте, чи щось сталося, коли канал упав. Це різні експерименти, і лише один із них вартий пообіддя.

Чотири питання, злиті в одне

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

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

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

Контрольний список, який їх розділяє

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

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

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

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

Автентифікація є частиною відновлення

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

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

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

Стійкість — не kill switch

Властивість намагається зберегти або відновити зв'язок із VPN. Вона не вирішує, що можна робити застосункам, поки VPN вимкнено, і сама по собі нічого не блокує.

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

Запишіть обидві половини в нотатках про відновлення: що намагався зробити VPN і який трафік застосунків було дозволено, поки тривала спроба.