Hold en Windows-VPN oppe: udløs rasdial på afbrydelseshændelsen

Windows leverer ingen genopkaldspolitik til sin VPN-klient, så en forbindelse, der falder ved midnat, er stadig nede til morgenmad. En planlagt opgave, der overvåger afbrydelsen og kører rasdial, lukker det hul uden en tredjepartsklient. Om opgaven opfører sig som en operatør eller som en løkke, afhænger af tre detaljer: hvilke hændelser den matcher, hvilke legitimationsoplysninger den kan se, og hvad den gør med resultatet. Ingen af de tre er svære, og hvis man mangler en af dem, får man en opgave, der ringer for evigt.

Hvorfor en timer er den forkerte trigger

En timer ringer efter sin egen tidsplan, uanset om tunnelen er nede. Det giver forsøg, som ingen havde brug for, og et forsøg midt i en arbejdsgang kan afbryde den. En hændelsestrigger udløses kun, når forbindelsen skifter tilstand, hvilket er billigere og lettere at ræsonnere om. Hændelsen bærer også årsagen, og årsagen er det, der adskiller en netværksfejl fra en person, der afbryder med vilje.

Den forskel er forskellen mellem en nyttig opgave og en, der slås med brugeren hver aften. Det er også den del, der normalt mangler i opskrifter, som kun beskriver handlingen.

Hændelsesparet, og den der skal undertrykkes

Remote Access Service-klienten skriver livscyklusposter i Application-loggen under udbyderen RasClient. 20226 markerer en forbindelse, der sluttede, og 20227 markerer et forsøg, der mislykkedes, så begge kan begrunde et nyt opkald. Alt andet i opgaven afhænger af at matche de to identifikatorer præcist. De har været stabile i årevis, og derfor cirkulerer opskrifter bygget på dem stadig, men et byg, der omdøber udbyderen eller id'erne, får forespørgslen til at returnere intet. Kør bevisstrinnet igen efter hver funktionsopdatering i stedet for at vente på, at opgaven holder op med at udløses.

Én afslutning skal udelukkes. Fejl 631 betyder, at porten blev afbrudt af brugeren, og et nyt opkald i det øjeblik slås med den person, der lige har skiftet netværk med vilje. Sæt udelukkelsen i triggerens filter i stedet for i scriptet, så opgaven slet ikke starter. Den skal kun gælde for ét hændelses-id, fordi et EventData-prædikat kun matcher, når det navngivne element findes, og en delt klausul ville tavst droppe hver hændelse med det andet id. Læs elementnavnet ud af en rigtig post, før du skriver filteret:

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

XML'en viser de præcise Data-navne i den post. ErrorCode er den sædvanlige stavemåde, og en post, der bruger noget andet, kræver, at det navn erstattes i filteret nedenfor.

<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>

Indsæt det i triggerens brugerdefinerede filter, og bevis det som en forespørgsel, før det bliver en trigger. Den samme XPath kører fra PowerShell mod den levende log, hvilket er den billige måde at se, hvad den matcher, mens opgavehistorikken endnu ikke er involveret.

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

En trigger, der tavst ikke matcher noget, ser præcis ud som en opgave, der kører og fejler. Begge fremstår som "automatiseringen virker ikke", og ingen af dem siger, hvilken halvdel der mangler. Tjek først forespørgselsoutputtet, fordi det adskiller de to tilfælde i ét trin.

Opkaldet fejler, fordi der ikke er nogen til at skrive adgangskoden

Handlingen kører rasdial med forbindelsens navn. Når profilen ikke har nogen cachet legitimationsoplysning, fejler opkaldet med det samme, fordi der ikke er nogen til at svare på prompten. Det er den mest almindelige grund til, at en korrekt udløst opgave ikke gør noget synligt, så tjek det, før du rører triggeren. Manuelt opkald fra en kommandoprompt adskiller et legitimationsproblem fra et planlægningsproblem.

Gem legitimationsoplysningen én gang under den konto, opgaven skal køre som, og gør den konto til en del af designet. En opgave, der kører som SYSTEM, kan ikke læse en legitimationsoplysning, der er cachet af din interaktive konto, og en opgave, der kører som en anden, kan heller ikke. Navnet skal også matche profilen præcist, inklusive ethvert domænepræfiks i brugerfeltet.

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

Den første kommando viser de navne, Windows kender. Den anden ringer ved navn med den cachede legitimationsoplysning, og den tredje er den form, en PowerShell-handling bør bruge, fordi den venter og returnerer en værdi, som opgaven kan registrere.

Læs exitkoden i stedet for vinduet

En opgave, der starter en proces uden at vente, rapporterer succes, så snart processen findes. For et opkald, der kan fejle et sekund senere, er den dom værdiløs. At vente på exitkoden gør handlingen til et rigtigt resultat. Opgavehistorik alene viser kun, at en proces startede, aldrig at en tunnel kom op.

Log værdien med et tidsstempel ved hver kørsel. En enkelt fejl efter et udfald er normalt, mens tre fejl i træk med samme kode peger på legitimationsoplysningen eller profilen frem for netværket. Det mønster er det, der gør historikken værd at læse.

Tilføj et kort gentagelsesinterval som forsikring, og vær eksplicit om, hvordan det interagerer med en hændelsestrigger. En gentagelse hvert minut i fem minutter giver det andet forsøg, når internettet kom tilbage sammen med tunnelen, og under Indstillinger, "Hvis opgaven allerede kører, gælder følgende regel", vil opgaven have "Start ikke en ny forekomst", så en gentagelse ikke overlapper et opkald, der stadig er i gang. Uden den indstilling kan to rasdial-processer kæmpe om den samme port, og den anden fejler uden nogen nyttig grund.

Bevis gendannelsesvejen

Test begge retninger med vilje. Afbryd manuelt, og bekræft, at der ikke sker et nyt opkald, deaktiver derefter netværksadapteren, og bekræft, at opgaven udløses, når linket vender tilbage. De to tests dækker undertrykkelsesreglen og det rigtige fejltilfælde, og intet andet gør det.

Læs derefter opgavehistorikken i stedet for forbindelsesikonet. Historikken registrerer, hvornår opgaven kørte, hvilken konto den brugte, og hvad handlingen returnerede, og det er det bevis, der er nødvendigt, når den samme maskine falder igen i næste måned.