Винятки VPN для окремих застосунків ламаються, коли спільна служба завантажує дані

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

У цих заявках зазвичай дві речі ламаються разом: виключається неправильний компонент, а виняток потім ніколи не звужується.

Знайдіть процес, а не вікно

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

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

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

Ставтеся до DNS як до окремого шляху

Системне розв'язання імен може взагалі не йти за виключеним застосунком, тому виключений браузер усе ще може зазнавати невдачі на приватному імені хоста, хоча його трафік коректно перебуває поза тунелем. Браузер було виключено; розв'язувач — ні.

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

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

Не розширюйте спільний помічник

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

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

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

Перевіряйте весь робочий процес, а не невдалий крок

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

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

Залиште причину, а не список імен

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

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