O RRAS inicia antes de o túnel OpenVPN estar pronto na inicialização

O servidor reinicia, o OpenVPN inicia e o RRAS sobe enquanto o adaptador ou a rota de que depende ainda não existe. Reiniciar o RRAS manualmente um minuto depois resolve, o que faz o problema parecer solucionado e esconde o real. Duas condições diferentes são confundidas aqui: o serviço pré-requisito está em execução e o recurso de rede de que o RRAS realmente precisa tornou-se utilizável. Uma dependência de serviço do Windows pode expressar a primeira condição e nunca a segunda, portanto adicionar uma sem definir o recurso dá-lhe uma inicialização mais arrumada e a mesma falha.

Como o sintoma se parece numa inicialização a frio

A pista é a diferença entre uma inicialização a frio e um reinício. Numa inicialização a frio o RRAS relata estar em execução enquanto o adaptador do túnel está ausente, a rota falta ou o endereço do par ainda não é resolvido. Um reinício manual depois tem sucesso porque nesse momento o recurso existe, e o serviço simplesmente relê um mundo que não podia ver um minuto antes. O registo do serviço mostrará um início limpo em ambos os casos, e é por isso que o visualizador de eventos sozinho raramente explica isto.

Capture os dois estados antes de mudar seja o que for: o que o RRAS relata na inicialização e o que existe no momento em que o reinício manual tem sucesso. Se essas duas observações forem idênticas, a ordem de inicialização não é a sua explicação e uma dependência não ajudará. A comparação custa dez minutos e poupa uma semana de conjecturas.

Uma dependência adicionada com base em «funciona depois de um reinício» apenas atrasa a mesma falha pelo tempo que o serviço pré-requisito leva a relatar RUNNING. Também torna a inicialização mais difícil de raciocinar, porque a restrição de ordem agora parece uma explicação. Pergunte que objeto a dependência garante e se esse objeto é o que o RRAS não conseguia ver.

Nomeie o recurso, não apenas o serviço

Anote a coisa concreta que falta. Pode ser um adaptador de túnel com um endereço, uma rota para uma sub-rede par, uma resposta DNS ou um certificado ainda em aprovisionamento. «O serviço VPN está em execução» não é uma descrição de recurso, e um ícone verde num cliente também não. Até conseguir nomear o objeto e um comando que o mostre, não definiu a condição que está a tentar aguardar.

Estabeleça também como esta instância de OpenVPN é lançada. Um túnel gerido por GUI e um túnel gerido por serviço têm ciclos de vida de inicialização diferentes, e o nome do serviço tem de vir da máquina à sua frente, não de um exemplo escrito para outro instalador. Enumere os candidatos em vez de confiar num nome memorizado.

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

Leia a cadeia de dependências antes de lhe acrescentar algo

O Gestor de Controlo de Serviços relata estados como START_PENDING e RUNNING, e a SERVICE_STATUS reference define exatamente o que significa cada campo. Nenhum desses estados promete que um par, um nome DNS ou uma aplicação a jusante estejam acessíveis. Essa lacuna é a razão completa pela qual esta falha sobrevive a uma dependência corretamente configurada.

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

A linha DEPENDENCIES de sc.exe qc é a lista que deve preservar, porque sc.exe config RemoteAccess depend= substitui toda a lista em vez de lhe acrescentar. Deixar cair um pré-requisito não relacionado ao adicionar um serviço VPN cria uma segunda falha que aparece noutra inicialização, e é muito mais difícil de diagnosticar do que a original. Copie a lista existente para o seu registo de alterações antes de lhe tocar.

As dependências também alteram o comportamento de encerramento, porque parar um pré-requisito para os serviços que dele dependem. Verifique o que acontece durante a manutenção antes de ligar o RRAS a algo que reinicia com frequência.

Condicione o reinício a uma condição, não a um temporizador

Uma espera fixa assume que o túnel estará sempre pronto dentro dessa janela, e é exatamente essa suposição que falha na inicialização em que um certificado é lento ou uma ligação está em baixo. Verifique o próprio recurso, com um prazo, e deixe a verificação decidir se é sequer necessário um reinício.

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'

Uma tarefa agendada no arranque que executa essas verificações e só reinicia o RRAS quando o adaptador ou a rota ainda faltam está limitada, é auditável e fácil de remover. A alternativa, reiniciar o RRAS a cada reconexão, interrompe sessões saudáveis e transforma uma ligação instável num ciclo de reinícios. Esse ciclo é pior do que a falha original, porque agora afeta utilizadores que estavam bem.

Dê à verificação uma espera máxima que corresponda ao tempo que o túnel razoavelmente leva no seu hardware, e faça a tarefa terminar com um estado diferente de zero quando desiste. Uma tarefa silenciosa que simplesmente deixa de tentar é indistinguível de uma que teve sucesso.

Registe a transição para que a próxima inicialização se explique sozinha

Registe três marcas temporais na mesma linha: quando o serviço de dependência atingiu RUNNING, quando o recurso necessário apareceu e quando o RRAS finalmente o aceitou. Essa única linha responde à pergunta que o próximo engenheiro fará, e produzi-la quase não custa nada. Sem ela, a próxima investigação começa com as mesmas conjecturas que esta.

Pare a automatização após um número definido de tentativas e reporte uma falha em vez de tentar para sempre. Uma inicialização que termina com uma mensagem clara «o recurso nunca apareceu» vale mais do que uma que continua a reiniciar um serviço às escuras. Quando essa mensagem aparecer, o nome do recurso que anotou na segunda secção é o que a próxima pessoa procurará.