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 конечно го прифати. Таа единствена линија одговара на прашањето што ќе го постави следниот инженер, и нејзиното создавање речиси ништо не чини. Без неа следната истрага започнува од истото погодување како оваа.

Запрете ја автоматизацијата по определен број обиди и пријавете грешка наместо вечно повторување. Подигнување што завршува со јасна порака „ресурсот никогаш не се појави“ вреди повеќе од она што продолжува да престартува услуга во темница. Кога таа порака ќе се појави, името на ресурсот што го запишавте во вториот дел е она што следната личност ќе го бара.