RRAS startar innan OpenVPN-tunneln är klar vid uppstart

Servern startar om, OpenVPN startar och RRAS kommer upp medan adaptern eller rutten som det beror på ännu saknas. Att starta om RRAS manuellt en minut senare åtgärdar det, vilket får problemet att se löst ut och döljer det verkliga. Här blandas två olika villkor ihop: förutsättningstjänsten körs, och nätverksresursen som RRAS faktiskt behöver har blivit användbar. Ett Windows-tjänstberoende kan uttrycka det första villkoret och aldrig det andra, så att lägga till ett utan att definiera resursen ger en snyggare uppstart och samma fel.

Hur symptomet ser ut vid en kallstart

Tecknet är skillnaden mellan kallstart och omstart. Vid kallstart rapporterar RRAS att det körs medan tunneladaptern saknas, rutten är borta eller peer-adressen ännu inte löses upp. En manuell omstart lyckas då eftersom resursen finns vid det laget, och tjänsten läser helt enkelt om en värld som den inte kunde se en minut tidigare. Tjänsteloggen visar en ren start i båda fallen, och därför förklarar händelsevisaren sällan detta på egen hand.

Registrera båda tillstånden innan du ändrar något: vad RRAS rapporterar vid uppstart och vad som finns i stunden då den manuella omstarten lyckas. Om de två observationerna är identiska är startordningen inte din förklaring och ett beroende hjälper inte. Jämförelsen kostar tio minuter och sparar en vecka av gissningar.

Ett beroende som läggs till på grundval av ”det fungerar efter en omstart” skjuter bara upp samma fel med den tid som förutsättningstjänsten behöver för att rapportera RUNNING. Det gör också uppstarten svårare att resonera kring, eftersom ordningsbegränsningen nu ser ut som en förklaring. Fråga vilket objekt beroendet garanterar och om det objektet är det som RRAS inte kunde se.

Namnge resursen, inte bara tjänsten

Skriv ned den konkreta sak som saknas. Det kan vara en tunneladapter med adress, en rutt till ett peer-subnät, ett DNS-svar eller ett certifikat som fortfarande tillhandahålls. ”VPN-tjänsten körs” är ingen resursbeskrivning, och en grön ikon i en klient är det inte heller. Tills du kan namnge objektet och ett kommando som visar det har du inte definierat villkoret du försöker vänta på.

Fastställ också hur denna OpenVPN-instans startas. En GUI-hanterad tunnel och en tjänstehanterad tunnel har olika startlivscykler, och tjänstenamnet måste komma från maskinen framför dig, inte från ett exempel skrivet för en annan installatör. Lista kandidaterna i stället för att lita på ett ihågkommet namn.

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

Läs beroendekedjan innan du lägger till något

Tjänstekontrollhanteraren rapporterar tillstånd som START_PENDING och RUNNING, och SERVICE_STATUS reference definierar exakt vad varje fält betyder. Inget av dessa tillstånd lovar att en peer, ett DNS-namn eller ett nedströmsprogram är nåbart. Den luckan är hela anledningen till att felet överlever ett korrekt konfigurerat beroende.

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

Raden DEPENDENCIES från sc.exe qc är listan du måste bevara, eftersom sc.exe config RemoteAccess depend= ersätter hela listan i stället för att lägga till i den. Att tappa en orelaterad förutsättning när du lägger till en VPN-tjänst skapar ett andra fel som visar sig vid en annan uppstart, och det är mycket svårare att diagnosticera än det ursprungliga. Kopiera den befintliga listan till din ändringslogg innan du rör den.

Beroenden ändrar också beteendet vid avstängning, eftersom att stoppa en förutsättning stoppar de tjänster som beror på den. Kontrollera vad som händer under underhåll innan du kopplar RRAS till något som ofta startar om.

Låt omstarten bero på ett villkor, inte på en timer

En fast väntan förutsätter att tunneln alltid är klar inom det fönstret, och det är just det antagandet som fallerar vid den uppstart där ett certifikat är långsamt eller en länk ligger nere. Kontrollera själva resursen, med en deadline, och låt kontrollen avgöra om en omstart alls behövs.

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'

En schemalagd uppgift vid uppstart som kör dessa kontroller och bara startar om RRAS när adaptern eller rutten fortfarande saknas är avgränsad, granskningsbar och lätt att ta bort. Alternativet, att starta om RRAS vid varje återanslutning, avbryter friska sessioner och förvandlar en instabil länk till en omstartsloop. Den loopen är värre än det ursprungliga felet, eftersom den nu drabbar användare som hade det bra.

Ge kontrollen en maximal väntetid som matchar den tid tunneln rimligen tar på din hårdvara, och låt uppgiften avslutas med en status som inte är noll när den ger upp. En tyst uppgift som bara slutar försöka går inte att skilja från en som lyckades.

Logga övergången så att nästa uppstart förklarar sig själv

Registrera tre tidsstämplar på samma rad: när beroendetjänsten nådde RUNNING, när den nödvändiga resursen dök upp och när RRAS till slut accepterade den. Den enda raden svarar på frågan som nästa ingenjör kommer att ställa, och det kostar nästan ingenting att ta fram den. Utan den börjar nästa utredning från samma gissningar som denna.

Stoppa automatiseringen efter ett bestämt antal försök och rapportera ett fel i stället för att försöka i evighet. En uppstart som slutar med ett tydligt meddelande ”resursen dök aldrig upp” är värd mer än en som fortsätter att starta om en tjänst i mörkret. När det meddelandet dyker upp är resursnamnet du skrev ned i andra avsnittet det som nästa person kommer att söka efter.