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

Порівняння трьох механізмів за тим, що вони гарантують, краще за ранжування за елегантністю. Кожен збоїть по-своєму, і саме режим збою ви потім терпите.

Чому вхід запускається занадто рано

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

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

Три хуки в порівнянні

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

MechanismReacts toCovers a mid-session reconnectTypical failure
Network profile eventA network connect recordYes, when the event repeatsRuns on the wrong network
Resource poll with backoffThe resource becoming reachableYesLog noise and a wasted window
Stored credentials aloneNothing; it removes a promptNoStill fires before the tunnel

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

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

Побудуйте тригер події правильно

Запис міститься в журналі Microsoft-Windows-NetworkProfile/Operational, а ID 10001 позначає мережу, яка щойно підключилася. Створіть завдання з тригером «Під час події», націленим на цей журнал, це ім'я постачальника й цей ідентифікатор. Кожна мережа, до якої приєднується машина, запустить його, тому дії потрібна захисна умова, а не припущення, і вона має виконуватися лише поки користувач увійшов, якщо робота торкається підключених дисків.

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

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

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

schtasks /query /tn "VpnPostConnect" /v /fo LIST
Get-WinEvent -LogName Microsoft-Windows-NetworkProfile/Operational -MaxEvents 10
Test-Path \\fileserver\share
whoami

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

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

Схожі статті