Panatilihing buhay ang VPN ng Windows: i-trigger ang rasdial sa pangyayari ng pagkaputol

Walang ibinibigay na patakaran sa muling pag-dial ang Windows para sa kliyenteng VPN nito, kaya ang koneksyong bumabagsak sa hatinggabi ay down pa rin sa almusal. Isang naka-iskedyul na gawain na nagmamatyag sa pagkaputol at nagpapatakbo ng rasdial ang nagsasara ng puwang na iyon nang walang kliyente ng ikatlong partido. Kung ang gawain ay kikilos tulad ng operator o tulad ng loop ay nakasalalay sa tatlong detalye: aling mga pangyayari ang tinutugma nito, aling kredensyal ang nakikita nito, at ano ang ginagawa nito sa resulta. Wala sa tatlo ang mahirap, at ang makaligtaan ang alinman sa mga ito ang lumilikha ng gawaing tumatawag magpakailanman.

Bakit maling trigger ang timer

Tumatawag ang timer ayon sa sarili nitong iskedyul nasa down man o hindi ang tunnel. Gumagawa iyon ng mga pagtatangkang walang kailangan, at ang pagtatangka habang may sesyon ng trabaho ay maaaring makagambala rito. Ang trigger ng pangyayari ay pumipintig lamang kapag nagbago ang estado ng koneksyon, na mas mura at mas madaling isipin. Dala rin ng pangyayari ang dahilan, at ang dahilan ang naghihiwalay ng pagkabigo ng network mula sa taong sinasadyang nagdi-disconnect.

Ang pagkakaibang iyon ang pagkakaiba ng kapaki-pakinabang na gawain at ng gawaing nakikipag-away sa gumagamit tuwing gabi. Ito rin ang bahaging karaniwang nawawala sa mga recipe na naglalarawan lamang ng aksyon.

Ang pares ng pangyayari, at ang dapat sugpuin

Ang kliyente ng Remote Access Service ay nagsusulat ng mga talaan ng lifecycle sa log ng Application sa ilalim ng provider na RasClient. Minarkahan ng 20226 ang koneksyong natapos, at minarkahan ng 20227 ang pagtatangkang nabigo, kaya maaaring bigyang-katwiran ng alinman sa dalawa ang bagong tawag. Ang lahat ng iba pa sa gawain ay nakasalalay sa eksaktong pagtutugma ng dalawang identifier na iyon. Matatag sila nang maraming taon, kaya umiikot pa rin ang mga recipe na binuo sa kanila, ngunit ang isang build na nagpapalit ng pangalan ng provider o ng mga identifier ay ginagawang walang ibinabalik ang query. Patakbuhin muli ang hakbang ng patunay pagkatapos ng bawat update ng feature sa halip na hintayin na tumigil sa pag-trigger ang gawain.

May isang pagtatapos na dapat ibukod. Ang error 631 ay nangangahulugang ang gumagamit ang nag-disconnect ng port, at ang muling pag-dial sa sandaling iyon ay nakikipag-away sa taong karara lang sinasadyang nagpalit ng network. Ilagay ang pagbubukod sa filter ng trigger at hindi sa script, para hindi magsimula ang gawain. Dapat itong mailapat sa isang ID ng pangyayari lamang, dahil ang EventData predicate ay tumutugma lamang kapag may elemento na pinangalanan, at ang isang shared clause ay tahimik na magtatapon ng bawat pangyayari ng kabilang ID. Basahin ang pangalan ng elemento mula sa tunay na talaan bago isulat ang filter:

Get-WinEvent -LogName Application -MaxEvents 5 -FilterXPath "*[System[Provider[@Name='RasClient'] and EventID=20226]]" | Select-Object -First 1 -ExpandProperty ToXml

Ipinapakita ng XML ang eksaktong mga pangalan ng Data sa talaang iyon. Ang ErrorCode ang karaniwang baybay, at ang talaang gumagamit ng iba ay nangangailangan na palitan ang pangalang iyon sa filter sa ibaba.

<QueryList><Query Id="0" Path="Application"><Select Path="Application">*[System[Provider[@Name='RasClient'] and (EventID=20226 or EventID=20227)]] and (EventData[Data[@Name='ErrorCode'] != '631'] or System[EventID=20227])</Select></Query></QueryList>

I-paste iyon sa custom na filter ng trigger, at patunayan ito bilang query bago ito maging trigger. Ang parehong XPath ay tumatakbo mula sa PowerShell laban sa live na log, na siyang murang paraan upang makita kung ano ang tinutugma nito habang hindi pa kasangkot ang kasaysayan ng gawain.

Get-WinEvent -LogName Application -MaxEvents 40 -FilterXPath "*[System[Provider[@Name='RasClient'] and (EventID=20226 or EventID=20227)]] and (EventData[Data[@Name='ErrorCode'] != '631'] or System[EventID=20227])" | Select-Object TimeCreated,Id,Message

Ang trigger na tahimik na walang tinutugma ay mukhang eksaktong gawaing tumatakbo at nabibigo. Pareho silang lumilitaw bilang "hindi gumagana ang automation", at wala sa kanila ang nagsasabi kung aling kalahati ang nawawala. Suriin muna ang output ng query, dahil hinihiwalay nito ang dalawang kaso sa isang hakbang.

Nabibigo ang tawag dahil walang tao para mag-type ng password

Pinapatakbo ng aksyon ang rasdial kasama ang pangalan ng koneksyon. Kapag walang naka-cache na kredensyal ang profile, agad na nabibigo ang tawag dahil walang tao para sagutin ang prompt. Ito ang pinakakaraniwang dahilan kung bakit ang tamang na-trigger na gawain ay walang ginagawang nakikita, kaya suriin ito bago hawakan ang trigger. Ang manu-manong pag-dial mula sa command prompt ay naghihiwalay ng problema sa kredensyal mula sa problema sa iskedyul.

I-save ang kredensyal nang isang beses sa ilalim ng account na pagpapatakbuhin ng gawain, at gawing bahagi ng disenyo ang account na iyon. Ang gawaing tumatakbo bilang SYSTEM ay hindi mababasa ang kredensyal na na-cache ng iyong interactive na account, at gayundin ang gawaing tumatakbo bilang ibang tao. Dapat ding tumugma nang eksakto ang pangalan sa profile, kasama ang anumang prefix ng domain sa field ng user.

rasdial
rasdial "Office VPN"
(Start-Process rasdial -ArgumentList '"Office VPN"' -Wait -PassThru -NoNewWindow).ExitCode

Inililista ng unang command ang mga pangalang kilala ng Windows. Ang pangalawa ay tumatawag ayon sa pangalan gamit ang naka-cache na kredensyal, at ang pangatlo ang form na dapat gamitin ng aksyon ng PowerShell, dahil naghihintay ito at nagbabalik ng halagang maaaring itala ng gawain.

Basahin ang exit code sa halip na ang window

Ang gawaing naglulunsad ng proseso nang walang paghihintay ay nag-uulat ng tagumpay sa sandaling umiral ang proseso. Para sa tawag na maaaring mabigo makalipas ang isang segundo, walang halaga ang hatol na iyon. Ang paghihintay sa exit code ay ginagawang tunay na resulta ang aksyon. Ang kasaysayan ng gawain lamang ay nagpapakita na nagsimula ang isang proseso, hindi kailanman na umangat ang isang tunnel.

Itala ang halaga na may timestamp sa bawat pagtakbo. Ang isang pagkabigo pagkatapos ng outage ay normal, samantalang ang tatlong magkakasunod na pagkabigo na may parehong code ay tumutukoy sa kredensyal o profile at hindi sa network. Ang pattern na iyon ang nagpapahalaga sa kasaysayan.

Magdagdag ng maikling agwat ng pag-uulit bilang seguro, at sabihin nang malinaw kung paano ito nakikipag-ugnayan sa trigger ng pangyayari. Ang pag-uulit bawat minuto sa loob ng limang minuto ay nagbibigay ng pangalawang pagtatangka kapag bumalik ang internet kasama ang tunnel, at sa ilalim ng Settings, "Kung tumatakbo na ang gawain, nalalapat ang sumusunod na patakaran", gusto ng gawain ang "Huwag magsimula ng bagong instance" para hindi magsanib ang pag-uulit sa tawag na tumatakbo pa. Kung wala ang setting na iyon, dalawang proseso ng rasdial ang maaaring mag-agawan sa parehong port at nabibigo ang pangalawa nang walang kapaki-pakinabang na dahilan.

Patunayan ang landas ng pagbawi

Subukan ang parehong direksyon nang sadya. Mag-disconnect nang manu-mano at kumpirmahing walang muling pag-dial, pagkatapos i-disable ang network adapter at kumpirmahing nag-trigger ang gawain kapag bumalik ang link. Sinasaklaw ng dalawang pagsubok na iyon ang patakaran ng pagsugpo at ang tunay na kaso ng pagkabigo, at wala nang ibang gumagawa niyon.

Pagkatapos ay basahin ang kasaysayan ng gawain sa halip na ang icon ng koneksyon. Itinatala ng kasaysayan kung kailan tumakbo ang gawain, aling account ang ginamit at ano ang ibinalik ng aksyon, at iyon ang ebidensyang kailangan kapag bumagsak muli ang parehong makina sa susunod na buwan.