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

sc.exe qc-ից ստացված DEPENDENCIES տողը այն ցանկն է, որը պետք է պահպանեք, որովհետև 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-ը վերջապես ընդունեց այն։ Այդ մեկ տողը պատասխանում է այն հարցին, որ կտա հաջորդ ինժեները, և դրա ստեղծումը գրեթե ոչինչ չարժե։ Առանց դրա հաջորդ հետաքննությունը սկսվում է նույն գուշակությունից, ինչ այս մեկը։

Կանգնեցրեք ավտոմատացումը սահմանված թվով փորձերից հետո և հաղորդեք ձախողման մասին՝ անվերջ կրկնելու փոխարեն։ Բեռնումը, որն ավարտվում է հստակ «ռեսուրսը երբեք չհայտնվեց» հաղորդագրությամբ, ավելի արժեքավոր է, քան այն, որ շարունակում է ծառայությունը վերսկսել մթության մեջ։ Երբ այդ հաղորդագրությունը հայտնվի, երկրորդ բաժնում գրած ռեսուրսի անունը հենց այն է, ինչ կփնտրի հաջորդ մարդը։