Hold en Windows-VPN oppe: utløs rasdial på frakoblingshendelsen

Windows tilbyr ingen gjenoppringingspolicy for VPN-klienten sin, så en forbindelse som faller ved midnatt er fortsatt nede til frokost. En planlagt oppgave som overvåker bruddet og kjører rasdial, lukker dette hullet uten en tredjepartsklient. Om oppgaven oppfører seg som en operatør eller som en løkke, avhenger av tre detaljer: hvilke hendelser den matcher, hvilke påloggingsdata den kan se, og hva den gjør med resultatet. Ingen av de tre er vanskelige, og å mangle én av dem er det som lager en oppgave som ringer for alltid.

Hvorfor en timer er feil utløser

En timer ringer etter sin egen plan, uansett om tunnelen er nede. Det gir forsøk ingen trengte, og et forsøk midt i en arbeidsøkt kan avbryte den. En hendelsesutløser fyrer bare når forbindelsen skifter tilstand, noe som er billigere og lettere å resonnere om. Hendelsen bærer også årsaken, og årsaken er det som skiller en nettverksfeil fra en person som kobler fra med vilje.

Den forskjellen er forskjellen mellom en nyttig oppgave og en som slåss med brukeren hver kveld. Det er også den delen som vanligvis mangler i oppskrifter som bare beskriver handlingen.

Hendelsesparet, og den som skal undertrykkes

Remote Access Service-klienten skriver livssyklusposter til Application-loggen under leverandøren RasClient. 20226 markerer en forbindelse som tok slutt, og 20227 markerer et forsøk som mislyktes, så begge kan rettferdiggjøre en ny oppringing. Alt annet i oppgaven avhenger av å matche de to identifikatorene nøyaktig. De har vært stabile i årevis, og derfor sirkulerer oppskrifter bygget på dem fortsatt, men en bygging som gir leverandøren eller ID-ene nye navn gjør at spørringen ikke returnerer noe. Kjør bevissteget på nytt etter hver funksjonsoppdatering i stedet for å vente på at oppgaven skal slutte å fyre.

Én avslutning må utelukkes. Feil 631 betyr at brukeren koblet fra porten, og en ny oppringing i det øyeblikket slåss med personen som nettopp byttet nettverk med vilje. Legg utelukkelsen i utløserens filter i stedet for i skriptet, slik at oppgaven ikke starter i det hele tatt. Den må bare gjelde én hendelses-ID, fordi et EventData-predikat bare matcher når det navngitte elementet finnes, og en delt klausul ville stille droppe hver hendelse med den andre ID-en. Les elementnavnet ut av en ekte 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 nøyaktige Data-navnene i den posten. ErrorCode er den vanlige stavemåten, og en post som bruker noe annet trenger at navnet 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>

Lim det inn i utløserens egendefinerte filter, og bevis det som en spørring før det blir en utløser. Den samme XPath-en kjører fra PowerShell mot den levende loggen, noe som er den billige måten å se hva den matcher mens oppgavehistorikken ennå ikke er involvert.

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 utløser som stille ikke matcher noe, ser nøyaktig ut som en oppgave som kjører og feiler. Begge fremstår som "automatiseringen virker ikke", og ingen av dem sier hvilken halvdel som mangler. Sjekk utdataene fra spørringen først, fordi det skiller de to tilfellene i ett trinn.

Oppringingen feiler fordi ingen er der til å skrive passordet

Handlingen kjører rasdial med forbindelsesnavnet. Når profilen ikke har noen bufret påloggingsdata, feiler oppringingen med en gang fordi ingen er der til å svare på forespørselen. Det er den vanligste grunnen til at en riktig utløst oppgave ikke gjør noe synlig, så sjekk det før du rører utløseren. Manuell oppringing fra en ledetekst skiller et påloggingsproblem fra et planleggingsproblem.

Lagre påloggingsdataene én gang under kontoen oppgaven skal kjøre som, og gjør den kontoen til en del av designet. En oppgave som kjører som SYSTEM kan ikke lese påloggingsdata som er bufret av den interaktive kontoen din, og en oppgave som kjører som noen andre kan heller ikke. Navnet må også stemme nøyaktig med profilen, inkludert eventuelt domeneprefiks i brukerfeltet.

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

Den første kommandoen lister navnene Windows kjenner. Den andre ringer ved navn med de bufrede påloggingsdataene, og den tredje er formen en PowerShell-handling bør bruke, fordi den venter og returnerer en verdi oppgaven kan registrere.

Les avslutningskoden i stedet for vinduet

En oppgave som starter en prosess uten å vente, rapporterer suksess så snart prosessen finnes. For en oppringing som kan feile et sekund senere, er den dommen verdiløs. Å vente på avslutningskoden gjør handlingen til et ekte resultat. Oppgavehistorikken alene viser bare at en prosess startet, aldri at en tunnel kom opp.

Logg verdien med tidsstempel ved hver kjøring. En enkelt feil etter et avbrudd er normalt, mens tre feil på rad med samme kode peker på påloggingsdataene eller profilen og ikke på nettverket. Det mønsteret er det som gjør historikken verdt å lese.

Legg til et kort gjentakelsesintervall som forsikring, og vær tydelig på hvordan det samspiller med en hendelsesutløser. En gjentakelse hvert minutt i fem minutter gir det andre forsøket når internett kom tilbake sammen med tunnelen, og under Innstillinger, "Hvis oppgaven allerede kjører, gjelder følgende regel", vil oppgaven ha "Ikke start en ny forekomst" slik at en gjentakelse ikke overlapper en oppringing som fortsatt pågår. Uten den innstillingen kan to rasdial-prosesser kjempe om samme port, og den andre feiler uten noen nyttig grunn.

Bevis gjenopprettingsveien

Test begge retninger med vilje. Koble fra manuelt og bekreft at ingen ny oppringing skjer, deaktiver deretter nettverksadapteren og bekreft at oppgaven fyrer når lenken kommer tilbake. De to testene dekker undertrykkelsesregelen og det ekte feiltilfellet, og ingenting annet gjør det.

Les oppgavehistorikken etterpå i stedet for tilkoblingsikonet. Historikken registrerer når oppgaven kjørte, hvilken konto den brukte og hva handlingen returnerte, og det er beviset som trengs når samme maskin faller igjen neste måned.