RRAS стартира преди тунелът на OpenVPN да е готов при зареждане

Сървърът се рестартира, 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 най-накрая го прие. Този един ред отговаря на въпроса, който следващият инженер ще зададе, и производството му почти не струва нищо. Без него следващото разследване започва от същите догадки, от които и това.

Спрете автоматизацията след определен брой опити и отчетете неуспех, вместо да опитвате вечно. Зареждане, което завършва с ясно съобщение „ресурсът така и не се появи“, струва повече от такова, което продължава да рестартира услуга в тъмното. Когато това съобщение се появи, името на ресурса, което записахте във втория раздел, е това, което следващият човек ще търси.