RRAS запускається раніше, ніж тунель OpenVPN готовий під час завантаження

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

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

Як виглядає симптом під час холодного завантаження

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

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

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

Назвіть ресурс, а не лише службу

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

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

Get-Service | Where-Object Name -match 'vpn|openvpn' | Select-Object Name, Status, StartType

Прочитайте ланцюжок залежностей, перш ніж щось додавати

Диспетчер керування службами повідомляє стани, як-от START_PENDING і RUNNING, а SERVICE_STATUS reference точно визначає, що означає кожне поле. Жоден із цих станів не обіцяє, що партнер, ім'я DNS або нижчий застосунок доступні. Саме ця прогалина — уся причина, чому ця помилка переживає правильно налаштовану залежність.

Get-Service -Name RemoteAccess | Select-Object Status, StartType
sc.exe qc RemoteAccess
Get-Service -Name RemoteAccess | Select-Object -ExpandProperty DependentServices

Рядок DEPENDENCIES з sc.exe qc — це список, який треба зберегти, бо sc.exe config RemoteAccess depend= замінює весь список, а не додає до нього. Якщо прибрати не пов'язану попередню умову під час додавання служби VPN, виникне друга несправність, яка проявиться під час іншого завантаження, і її значно важче діагностувати, ніж початкову. Скопіюйте наявний список у журнал змін, перш ніж його торкатися.

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

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

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

Get-NetAdapter | Where-Object Status -eq 'Up'
Get-NetRoute -DestinationPrefix 0.0.0.0/0
Get-WinEvent -LogName System -MaxEvents 40 |
  Where-Object ProviderName -eq 'Service Control Manager'

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

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

Записуйте перехід, щоб наступне завантаження пояснювало себе саме

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

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

Схожі статті