Запуск задачи при подключении VPN: событие, опрос или учётные данные?
Скрипт входа выполняется до того, как появится туннель. Сравните триггер сетевого события, опрос ресурса и сохранённые учётные данные по тому, что каждый из них гарантирует.
Скрипт входа, который подключает диск или запускает задачу синхронизации, выполняется до того, как у туннеля появится адрес, поэтому он тихо сбоит, и пользователь каждое утро исправляет его вручную. Windows не предлагает большинству клиентов обратный вызов при подключении для каждого VPN, но записывает изменение сети, и эта запись может запустить работу в нужный момент. Выбор стоит между реакцией на эту запись, опросом ресурса и удалением запроса, который делал сбой видимым.
Сравнение трёх механизмов по тому, что они гарантируют, лучше, чем ранжирование по изяществу. Каждый сбоит по-своему, и именно режим сбоя вы потом терпите.
Почему вход запускается слишком рано
Вход и запуск выполняются до того, как VPN-адаптер получит свой адрес, поэтому подключение диска, внутренний URL или соединение с базой данных, предпринятые в этот момент, не имеют ни маршрута, ни резолвера. Запрос сбоит, и сеанс остаётся в состоянии, которое пользователь должен исправить вручную. Перенос того же скрипта в папку автозагрузки ничего не меняет, потому что проблема порядка переезжает вместе с ним. Триггером должно быть изменение сети, а не событие сеанса.
Запланированная задача при входе с произвольной задержкой выглядит как исправление, а на самом деле является догадкой. Она работает на быстром канале и сбоит на медленном, а это наименее полезный вид надёжности.
Три хука в сравнении
Механизмы различаются тем, что они наблюдают, как быстро реагируют и что делают при повторном подключении позже в течение дня. Таблица сравнивает их по этим трём пунктам, а не по тому, насколько умно каждый звучит.
| Mechanism | Reacts to | Covers a mid-session reconnect | Typical failure |
|---|---|---|---|
| Network profile event | A network connect record | Yes, when the event repeats | Runs on the wrong network |
| Resource poll with backoff | The resource becoming reachable | Yes | Log noise and a wasted window |
| Stored credentials alone | Nothing; it removes a prompt | No | Still 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Запись в истории задач, которая существует, когда ни одно сетевое событие не совпадает, означает, что неверен триггер, а не действие. Если события появляются, а задача не запускается, задача может работать под учётной записью, которая не видит ресурс, и вывод учётной записи — это ключ. Проверка ресурса, которая проходит, пока подключение всё ещё отсутствует, указывает на контекст сеанса, а не на связность. Каждое из этих трёх наблюдений ведёт к своему исправлению.
Записывайте одну строку журнала на каждый запуск с адресом, результатом по ресурсу и итогом. Следующий сбой тогда покажет, запустилась ли задача рано, запустилась ли в неверной сети или не запустилась вовсе.