RRAS startuje, zanim tunel OpenVPN będzie gotowy przy rozruchu

Serwer uruchamia się ponownie, OpenVPN startuje, a RRAS wstaje, podczas gdy adapter lub trasa, od których zależy, wciąż nie istnieją. Ręczne ponowne uruchomienie RRAS minutę później naprawia to, przez co problem wydaje się rozwiązany, a prawdziwy zostaje ukryty. Mieszają się tu dwa różne warunki: usługa warunku wstępnego działa oraz zasób sieciowy, którego RRAS naprawdę potrzebuje, stał się użyteczny. Zależność usługi Windows może wyrazić pierwszy warunek i nigdy drugi, więc dodanie jej bez zdefiniowania zasobu daje schludniejszy rozruch i ten sam błąd.

Jak wygląda objaw przy zimnym rozruchu

Wskazówką jest różnica między zimnym startem a ponownym uruchomieniem. Przy zimnym starcie RRAS zgłasza, że działa, podczas gdy adapter tunelu jest nieobecny, trasa zniknęła lub adres peera jeszcze się nie rozwiązuje. Ręczne ponowne uruchomienie wtedy się udaje, bo w tym momencie zasób istnieje, a usługa po prostu czyta ponownie świat, którego nie mogła zobaczyć minutę wcześniej. Dziennik usługi w obu przypadkach pokaże czysty start, dlatego sam podgląd zdarzeń rzadko to wyjaśnia.

Zapisz oba stany, zanim cokolwiek zmienisz: co RRAS zgłasza przy rozruchu i co istnieje w chwili, gdy ręczne ponowne uruchomienie się udaje. Jeśli te dwa spostrzeżenia są identyczne, kolejność rozruchu nie jest twoim wyjaśnieniem i zależność nie pomoże. Porównanie zajmuje dziesięć minut i oszczędza tydzień zgadywania.

Zależność dodana na podstawie „działa po ponownym uruchomieniu” tylko opóźnia ten sam błąd o czas, jakiego usługa warunku wstępnego potrzebuje na zgłoszenie RUNNING. Utrudnia też zrozumienie rozruchu, bo ograniczenie kolejności wygląda teraz jak wyjaśnienie. Zapytaj, jaki obiekt gwarantuje zależność i czy tym obiektem jest ten, którego RRAS nie mógł zobaczyć.

Nazwij zasób, nie tylko usługę

Zapisz konkretną rzecz, której brakuje. Może to być adapter tunelu z adresem, trasa do podsieci peera, odpowiedź DNS albo certyfikat, który wciąż jest wydawany. „Usługa VPN działa” nie jest opisem zasobu, a zielona ikona w kliencie też nie. Dopóki nie potrafisz nazwać obiektu i polecenia, które go pokazuje, nie zdefiniowałeś warunku, na który próbujesz czekać.

Ustal też, jak uruchamiana jest ta instancja OpenVPN. Tunel zarządzany przez GUI i tunel zarządzany przez usługę mają różne cykle życia rozruchu, a nazwa usługi musi pochodzić z maszyny przed tobą, nie z przykładu napisanego dla innego instalatora. Wypisz kandydatów, zamiast ufać zapamiętanej nazwie.

Get-Service | Where-Object Name -match 'vpn|openvpn' | Select-Object Name, Status, StartType

Przeczytaj łańcuch zależności, zanim coś dodasz

Menedżer sterowania usługami zgłasza stany takie jak START_PENDING i RUNNING, a SERVICE_STATUS reference dokładnie definiuje, co oznacza każde pole. Żaden z tych stanów nie obiecuje, że peer, nazwa DNS lub aplikacja niższego poziomu są osiągalne. Ta luka jest całym powodem, dla którego ten błąd przeżywa poprawnie skonfigurowaną zależność.

Get-Service -Name RemoteAccess | Select-Object Status, StartType
sc.exe qc RemoteAccess
Get-Service -Name RemoteAccess | Select-Object -ExpandProperty DependentServices

Linia DEPENDENCIES z sc.exe qc to lista, którą musisz zachować, ponieważ sc.exe config RemoteAccess depend= zastępuje całą listę, a nie dodaje do niej. Pominięcie niepowiązanego warunku wstępnego przy dodawaniu usługi VPN tworzy drugi błąd, który pojawia się przy innym rozruchu, i znacznie trudniej go zdiagnozować niż pierwotny. Skopiuj istniejącą listę do rejestru zmian, zanim jej dotkniesz.

Zależności zmieniają też zachowanie przy wyłączaniu, bo zatrzymanie warunku wstępnego zatrzymuje usługi, które od niego zależą. Sprawdź, co dzieje się podczas konserwacji, zanim podłączysz RRAS do czegoś, co często się restartuje.

Uzależnij ponowne uruchomienie od warunku, nie od timera

Stałe oczekiwanie zakłada, że tunel zawsze będzie gotowy w tym oknie, a dokładnie to założenie zawodzi przy rozruchu, gdy certyfikat jest wolny albo łącze jest wyłączone. Sprawdź sam zasób, z terminem, i pozwól sprawdzeniu zdecydować, czy ponowne uruchomienie jest w ogóle potrzebne.

Get-NetAdapter | Where-Object Status -eq 'Up'
Get-NetRoute -DestinationPrefix 0.0.0.0/0
Get-WinEvent -LogName System -MaxEvents 40 |
  Where-Object ProviderName -eq 'Service Control Manager'

Zaplanowane zadanie przy rozruchu, które wykonuje te sprawdzenia i restartuje RRAS tylko wtedy, gdy adapter lub trasa wciąż nie istnieją, jest ograniczone, audytowalne i łatwe do usunięcia. Alternatywa, restartowanie RRAS przy każdym ponownym połączeniu, przerywa zdrowe sesje i zamienia niestabilne łącze w pętlę restartów. Ta pętla jest gorsza od pierwotnego błędu, bo dotyka teraz użytkowników, którym wszystko działało.

Daj sprawdzeniu maksymalne oczekiwanie odpowiadające czasowi, jakiego tunel rozsądnie potrzebuje na twoim sprzęcie, i pozwól zadaniu zakończyć się statusem różnym od zera, gdy się podda. Ciche zadanie, które po prostu przestaje próbować, jest nieodróżnialne od udanego.

Zarejestruj przejście, aby następny rozruch sam się wyjaśnił

Zapisz trzy znaczniki czasu w jednym wierszu: kiedy usługa zależności osiągnęła RUNNING, kiedy pojawił się wymagany zasób i kiedy RRAS w końcu go zaakceptował. Ten jeden wiersz odpowiada na pytanie, które zada następny inżynier, a jego wytworzenie prawie nic nie kosztuje. Bez niego następne dochodzenie zaczyna się od tych samych domysłów co to.

Zatrzymaj automatyzację po określonej liczbie prób i zgłoś błąd, zamiast ponawiać bez końca. Rozruch, który kończy się wyraźnym komunikatem „zasób nigdy się nie pojawił”, jest wart więcej niż taki, który dalej restartuje usługę po ciemku. Gdy ten komunikat się pojawi, nazwa zasobu zapisana w drugiej sekcji jest tym, czego będzie szukać następna osoba.