Вихід чи відключення: два різні результати VPN

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

Документація клієнта — єдине надійне місце, де можна дізнатися, що є що.

Чотири елементи керування, можливо чотири поведінки

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

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

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

Зчитуйте стан до і після кожної дії

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

systemctl status wg-quick@wg0 --no-pager
pgrep -a -f 'openvpn|wireguard|vpnagent'
ip link show | grep -E 'tun|wg'
nft list ruleset | grep -E 'drop|reject' | head -20
scutil --nc list

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

Ручне відключення — не збій

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

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

Виберіть той недоступний стан, який вам справді потрібен

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

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

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