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 нарэшце яго прыняў. Гэты адзіны радок адказвае на пытанне, якое задасць наступны інжынер, і яго стварэнне амаль нічога не каштуе. Без яго наступнае расследаванне пачынаецца з тых жа здагадак, што і гэтае.

Спыніце аўтаматызацыю пасля вызначанай колькасці спроб і паведаміце пра няўдачу замест бясконцага паўтору. Загрузка, якая сканчаецца ясным паведамленнем «рэсурс так і не з'явіўся», каштоўнейшая за тую, што працягвае перазапускаць службу ў цемры. Калі гэтае паведамленне з'явіцца, назва рэсурсу, якую вы запісалі ў другім раздзеле, — гэта тое, што будзе шукаць наступны чалавек.

Падобныя артыкулы