RRAS start voordat de OpenVPN-tunnel bij het opstarten gereed is
Een afhankelijkheid ordent de startvolgorde van de service; ze maakt de tunnel niet bruikbaar. Benoem de resource die RRAS nodig heeft en maak de herstart daarvan afhankelijk in plaats van van een wachttijd.
De server start opnieuw, OpenVPN start, en RRAS komt omhoog terwijl de adapter of route waarvan het afhangt nog ontbreekt. RRAS een minuut later handmatig herstarten lost het op, waardoor het probleem opgelost lijkt en het echte probleem verborgen blijft. Hier worden twee verschillende voorwaarden door elkaar gehaald: de voorwaardelijke service draait, en de netwerkresource die RRAS echt nodig heeft is bruikbaar geworden. Een Windows-serviceafhankelijkheid kan de eerste voorwaarde uitdrukken en nooit de tweede, dus er een toevoegen zonder de resource te definiëren levert een netter uitziende start en dezelfde fout op.
Hoe het symptoom er bij een koude start uitziet
Het teken is het verschil tussen een koude start en een herstart. Bij een koude start meldt RRAS dat het draait terwijl de tunneladapter ontbreekt, de route weg is, of het peeradres nog niet wordt opgelost. Een handmatige herstart lukt dan omdat de resource op dat moment bestaat, en de service leest simpelweg een wereld opnieuw die hij een minuut eerder niet kon zien. Het servicelog toont in beide gevallen een schone start, en daarom verklaart de gebeurtenisviewer dit zelden alleen.
Leg beide toestanden vast voordat u iets wijzigt: wat RRAS bij het opstarten meldt, en wat bestaat op het moment dat de handmatige herstart lukt. Als die twee observaties identiek zijn, is de startvolgorde niet uw verklaring en helpt een afhankelijkheid niet. De vergelijking kost tien minuten en bespaart een week giswerk.
Een afhankelijkheid die wordt toegevoegd op grond van „het werkt na een herstart“ stelt dezelfde fout alleen uit met de tijd die de voorwaardelijke service nodig heeft om RUNNING te melden. Ze maakt het opstarten ook lastiger te beredeneren, omdat de volgordebeperking nu op een verklaring lijkt. Vraag welk object de afhankelijkheid garandeert en of dat object het object is dat RRAS niet kon zien.
Benoem de resource, niet alleen de service
Schrijf het concrete ding op dat ontbreekt. Het kan een tunneladapter met een adres zijn, een route naar een peersubnet, een DNS-antwoord of een certificaat dat nog wordt ingericht. „De VPN-service draait“ is geen resourcebeschrijving, en een groen pictogram in een client ook niet. Tot u het object en een opdracht die het toont kunt benoemen, hebt u de voorwaarde niet gedefinieerd waarop u probeert te wachten.
Stel ook vast hoe deze OpenVPN-instantie wordt gestart. Een door GUI beheerde tunnel en een door de service beheerde tunnel hebben verschillende startlevenscycli, en de servicenaam moet van de machine voor u komen, niet uit een voorbeeld dat voor een andere installatieprogramma is geschreven. Noem de kandidaten op in plaats van een onthouden naam te vertrouwen.
Get-Service | Where-Object Name -match 'vpn|openvpn' | Select-Object Name, Status, StartType
Lees de afhankelijkheidsketen voordat u er iets aan toevoegt
De Service Control Manager meldt toestanden zoals START_PENDING en RUNNING, en de SERVICE_STATUS reference definieert precies wat elk veld betekent. Geen van die toestanden belooft dat een peer, een DNS-naam of een downstream-applicatie bereikbaar is. Die kloof is de hele reden dat deze fout een correct geconfigureerde afhankelijkheid overleeft.
Get-Service -Name RemoteAccess | Select-Object Status, StartType sc.exe qc RemoteAccess Get-Service -Name RemoteAccess | Select-Object -ExpandProperty DependentServices
De regel DEPENDENCIES uit sc.exe qc is de lijst die u moet bewaren, omdat sc.exe config RemoteAccess depend= de hele lijst vervangt in plaats van eraan toe te voegen. Een niet-verwante voorwaarde laten vallen terwijl u een VPN-service toevoegt, maakt een tweede fout die bij een andere start optreedt, en die is veel moeilijker te diagnosticeren dan de oorspronkelijke. Kopieer de bestaande lijst naar uw wijzigingsregistratie voordat u hem aanraakt.
Afhankelijkheden veranderen ook het afsluitgedrag, omdat het stoppen van een voorwaarde de services stopt die ervan afhangen. Controleer wat er tijdens onderhoud gebeurt voordat u RRAS koppelt aan iets dat vaak opnieuw start.
Maak de herstart afhankelijk van een voorwaarde, niet van een timer
Een vaste wachttijd gaat ervan uit dat de tunnel altijd binnen dat venster gereed is, en dat is precies de aanname die faalt bij de start waarbij een certificaat traag is of een verbinding wegvalt. Controleer de resource zelf, met een deadline, en laat de controle beslissen of een herstart überhaupt nodig is.
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'
Een geplande taak bij het opstarten die die controles uitvoert en RRAS alleen herstart wanneer de adapter of route nog ontbreekt, is begrensd, controleerbaar en eenvoudig te verwijderen. Het alternatief, RRAS bij elke herverbinding herstarten, onderbreekt gezonde sessies en verandert een instabiele verbinding in een herstartlus. Die lus is erger dan de oorspronkelijke fout, omdat hij nu gebruikers treft die het goed hadden.
Geef de controle een maximale wachttijd die past bij hoe lang de tunnel redelijkerwijs op uw hardware nodig heeft, en laat de taak eindigen met een status die niet nul is wanneer hij opgeeft. Een stille taak die gewoon stopt met proberen is niet te onderscheiden van een die slaagde.
Log de overgang zodat de volgende start zichzelf verklaart
Registreer drie tijdstempels op dezelfde regel: wanneer de afhankelijkheidsservice RUNNING bereikte, wanneer de vereiste resource verscheen, en wanneer RRAS die eindelijk accepteerde. Die ene regel beantwoordt de vraag die de volgende engineer zal stellen, en het kost bijna niets om hem te maken. Zonder die regel begint het volgende onderzoek bij hetzelfde giswerk als dit.
Stop de automatisering na een vastgesteld aantal pogingen en meld een fout in plaats van voor altijd opnieuw te proberen. Een start die eindigt met een duidelijke melding „de resource is nooit verschenen“ is meer waard dan een die in het donker een service blijft herstarten. Wanneer die melding verschijnt, is de resourcenaam die u in de tweede sectie hebt opgeschreven wat de volgende persoon zal zoeken.