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

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