Utrzymaj VPN w Windows włączony: uruchamiaj rasdial przy zdarzeniu rozłączenia

Windows nie oferuje żadnej polityki ponownego wybierania dla swojego klienta VPN, więc połączenie, które padnie o północy, przy śniadaniu nadal jest zerwane. Zaplanowane zadanie, które obserwuje rozłączenie i uruchamia rasdial, zamyka tę lukę bez klienta firmy trzeciej. To, czy zadanie zachowuje się jak operator, czy jak pętla, sprowadza się do trzech szczegółów: z którymi zdarzeniami się zgadza, jakie poświadczenia widzi i co robi z wynikiem. Żaden z tych trzech nie jest trudny, a pominięcie któregokolwiek z nich tworzy zadanie, które wybiera na zawsze.

Dlaczego timer jest złym wyzwalaczem

Timer wybiera według własnego harmonogramu, niezależnie od tego, czy tunel jest zerwany. To tworzy próby, których nikt nie potrzebował, a próba w trakcie sesji pracy może ją przerwać. Wyzwalacz zdarzenia uruchamia się tylko wtedy, gdy połączenie zmienia stan, co jest tańsze i łatwiejsze do przemyślenia. Zdarzenie niesie też powód, a powód jest tym, co oddziela awarię sieci od osoby, która świadomie się rozłącza.

Ta różnica to różnica między użytecznym zadaniem a takim, które każdego wieczoru walczy z użytkownikiem. To także ta część, której zwykle brakuje w przepisach opisujących tylko samą akcję.

Para zdarzeń i to, które trzeba wyciszyć

Klient usługi Remote Access Service zapisuje rekordy cyklu życia w dzienniku Application pod dostawcą RasClient. 20226 oznacza zakończone połączenie, a 20227 – nieudaną próbę, więc oba mogą uzasadnić nowe wybranie. Wszystko inne w zadaniu zależy od dokładnego dopasowania tych dwóch identyfikatorów. Są stabilne od lat, dlatego przepisy na nich oparte wciąż krążą, ale kompilacja, która zmienia nazwę dostawcy lub identyfikatorów, sprawia, że zapytanie nic nie zwraca. Uruchamiaj ponownie krok dowodu po każdej aktualizacji funkcji, zamiast czekać, aż zadanie przestanie się uruchamiać.

Jedno zakończenie trzeba wykluczyć. Błąd 631 oznacza, że użytkownik rozłączył port, a ponowne wybranie w tym momencie walczy z osobą, która właśnie świadomie zmieniła sieć. Wykluczenie umieść w filtrze wyzwalacza, a nie w skrypcie, żeby zadanie w ogóle się nie zaczynało. Musi dotyczyć tylko jednego identyfikatora zdarzenia, bo predykat EventData pasuje tylko wtedy, gdy nazwany element istnieje, a wspólna klauzula po cichu odrzuciłaby każde zdarzenie drugiego identyfikatora. Przeczytaj nazwę elementu z prawdziwego rekordu, zanim napiszesz filtr:

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

XML pokazuje dokładne nazwy Data w tym rekordzie. ErrorCode to zwykła pisownia, a rekord, który używa czegoś innego, wymaga podstawienia tej nazwy w filtrze poniżej.

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

Wklej to do niestandardowego filtra wyzwalacza i udowodnij jako zapytanie, zanim stanie się wyzwalaczem. Ten sam XPath działa z PowerShell przeciwko dziennikowi na żywo, co jest tanim sposobem sprawdzenia, z czym się zgadza, dopóki historia zadań nie jest jeszcze zaangażowana.

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

Wyzwalacz, który po cichu nie pasuje do niczego, wygląda dokładnie jak zadanie, które się wykonuje i zawodzi. Oba wyglądają jak „automatyzacja nie działa”, a żaden nie mówi, której połowy brakuje. Sprawdź najpierw wynik zapytania, bo rozdziela oba przypadki w jednym kroku.

Wybieranie zawodzi, bo nie ma nikogo, kto wpisze hasło

Akcja uruchamia rasdial z nazwą połączenia. Gdy profil nie ma żadnych buforowanych poświadczeń, wybieranie natychmiast zawodzi, bo nie ma nikogo, kto odpowie na pytanie. To najczęstsza przyczyna tego, że poprawnie uruchomione zadanie nie robi nic widocznego, więc sprawdź to, zanim dotkniesz wyzwalacza. Ręczne wybieranie z wiersza poleceń oddziela problem z poświadczeniami od problemu z harmonogramem.

Zapisz poświadczenia raz pod kontem, na którym będzie działać zadanie, i uczyń to konto częścią projektu. Zadanie działające jako SYSTEM nie może odczytać poświadczeń zapisanych w pamięci podręcznej przez Twoje konto interaktywne, a zadanie działające jako ktoś inny też nie może. Nazwa musi też dokładnie odpowiadać profilowi, łącznie z dowolnym prefiksem domeny w polu użytkownika.

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

Pierwsze polecenie wymienia nazwy, które zna Windows. Drugie wybiera po nazwie, używając buforowanych poświadczeń, a trzecie to forma, której powinna używać akcja PowerShell, bo czeka i zwraca wartość, którą zadanie może zapisać.

Czytaj kod wyjścia, a nie okno

Zadanie, które uruchamia proces bez czekania, zgłasza sukces, gdy tylko proces istnieje. Dla wybierania, które może zawieść sekundę później, taki werdykt jest bezwartościowy. Czekanie na kod wyjścia czyni akcję prawdziwym wynikiem. Historia zadań sama pokazuje tylko, że proces się rozpoczął, nigdy że tunel się podniósł.

Zapisuj wartość ze znacznikiem czasu przy każdym uruchomieniu. Pojedyncza porażka po awarii jest normalna, natomiast trzy porażki z rzędu z tym samym kodem wskazują na poświadczenia lub profil, a nie na sieć. To ten wzorzec czyni historię wartą czytania.

Dodaj krótki interwał powtarzania jako ubezpieczenie i wyraźnie powiedz, jak współdziała z wyzwalaczem zdarzenia. Powtarzanie co minutę przez pięć minut daje drugą próbę, gdy internet wrócił razem z tunelem, a w Ustawieniach, „Jeśli zadanie jest już uruchomione, obowiązuje następująca reguła”, zadanie chce „Nie uruchamiaj nowego wystąpienia”, żeby powtórzenie nie nakładało się na trwające wybieranie. Bez tego ustawienia dwa procesy rasdial mogą rywalizować o ten sam port, a drugi zawodzi bez żadnego pożytecznego powodu.

Udowodnij ścieżkę odzyskiwania

Przetestuj oba kierunki celowo. Rozłącz ręcznie i potwierdź, że nie następuje ponowne wybieranie, potem wyłącz kartę sieciową i potwierdź, że zadanie uruchamia się, gdy łącze wraca. Te dwa testy obejmują regułę wyciszania i rzeczywisty przypadek awarii, i nic innego tego nie robi.

Potem czytaj historię zadań zamiast ikony połączenia. Historia rejestruje, kiedy zadanie działało, jakiego konta użyło i co zwróciła akcja, i to jest dowód potrzebny, gdy ta sama maszyna znowu padnie w przyszłym miesiącu.