rasdial zgłasza „połączono”. Kiedy sieć jest naprawdę gotowa?

Skrypt, który otwiera okno VPN i potem czeka dziesięć sekund, zgaduje, a to zgadywanie jest błędne w obie strony: albo zaczyna kopiowanie, zanim tunel jest użyteczny, albo czeka dłużej, choć praca mogła już się zacząć. Żaden z tych wyników nie mówi, czy uwierzytelnianie się zakończyło. Użyj wyniku samego polecenia, a potem zadaj usłudze pytanie, na które naprawdę potrafi odpowiedzieć. Kolejność tych dwóch kroków to cały zamysł.

Co właściwie zgłasza polecenie

Dla natywnego profilu Windows, który rozumie zainstalowane narzędzie wiersza poleceń, rasdial.exe wybiera nazwany wpis i zwraca kod wyjścia procesu. Ten kod opisuje próbę połączenia: zero oznacza, że połączenie dla tego profilu zostało nawiązane, a wartość różna od zera — że nie udało się na etapie, który kod wskazuje. Czytaj go jako wynik jednej warstwy, a nie całego zadania.

Wynik nie mówi nic o przydzielaniu adresu, prywatnym DNS, dodanych trasach ani o uprawnieniu do dotarcia do konkretnego serwera. Wszystko to dzieje się po udanym połączeniu i każde z tych ogniw nadal może być błędne. Właśnie z powodu tej luki ikona połączenia i nieudane kopiowanie tak często współistnieją.

Przechwyć wynik, zanim cokolwiek innego ruszy

Zacznij od potwierdzenia, że profil istnieje dla konta, które będzie wykonywać zadanie, nie tylko dla konta, na którym testujesz:

Get-VpnConnection -Name "Contoso-Office"
Get-VpnConnection -Name "Contoso-Office" -AllUserConnection

Potem połącz się i od razu odczytaj kod. PowerShell trzyma natywny wynik w $LASTEXITCODE tylko do uruchomienia następnego zewnętrznego polecenia, więc przypadkowy ping między połączeniem a sprawdzeniem niszczy wartość, którą chciałeś odczytać. Najpierw przypisz ją do własnej zmiennej, a potem zdecyduj, co robić.

& rasdial.exe "Contoso-Office"
$dial = $LASTEXITCODE
if ($dial -ne 0) { throw "rasdial failed with $dial" }

Zapisuj kod razem z niebędącym tajemnicą tekstem błędu, ponieważ brakujący wpis, odrzucone dane logowania i przekroczenie czasu wymagają różnych reakcji. Tabela łączy typowe wyniki z następnym krokiem.

Gotowość to zasób, nie tunel

Gdy połączenie się powiedzie, przetestuj to, czego potrzebuje zadanie. Udział sieciowy, punkt końcowy API albo port bazy danych to lepsza próba gotowości niż publiczna strona, bo publiczna witryna odpowiada dowolną działającą drogą i niczego nie dowodzi o drodze prywatnej. Wybierz próbę, od której zależy sama aplikacja. Udane połączenie TCP mówi, że routing i filtrowanie są otwarte, a to większość tego, czego potrzebuje pierwszy zapis:

Test-NetConnection -ComputerName files.contoso.example -Port 445

Ogranicz liczbę prób i zapisz, który etap zawiódł. Odrzucone dane logowania powinny zatrzymać skrypt, a nie karmić pętlę ponowień; nazwa DNS, która jeszcze się nie pojawiła, zasługuje na kilka krótkich ponowień; port, który nigdy się nie otwiera, to problem routingu lub polityki ponad klientem.

Tam, gdzie połączenie istniało już przed rozpoczęciem zadania, zostaw je w spokoju. Rozłączanie sesji, której nie otworzyłeś, przerywa inną pracę użytkownika, więc zapisz, do kogo należy sesja i jakie zamknięcie jest właściwe.

Ogranicz profil do konta, które wykonuje zadanie

Zaplanowane zadanie działa pod własną tożsamością i sesją, a profil, który działa na twoim pulpicie, może być tam niewidoczny. Uruchom ponownie sprawdzenie widoczności i połączenie na koncie zadania, zanim zaufasz harmonogramowi. Trzymaj hasło z dala od wiersza poleceń: argumenty widać w innych procesach i często trafiają do logów.

Jeśli wdrożenie wymaga monitu w przeglądarce, dotknięcia karty inteligentnej albo zatwierdzenia MFA, ta interakcja jest częścią projektu i nie da się jej zautomatyzować przez symulowanie naciśnięć klawiszy. W takim przypadku użyj obsługiwanego klienta i pozwól, by krok wykonał człowiek.

Kształt końcowego skryptu pozostaje krótki: sprawdź profil, połącz się, odczytaj kod, przetestuj zasób, a potem zacznij pracę. Każdy krok odpowiada na pytanie, którego poprzedni nie mógł, i żaden nie opiera się na czekaniu.