OpenVPN no Windows: iniciar o túnel automaticamente e manter as rotas

Aqui se entrelaçam dois requisitos: o túnel deve subir antes de qualquer login, e o tráfego para um segundo site deve segui-lo. São problemas separados com mecanismos separados. O arranque do serviço decide o primeiro, e a vida da rota decide o segundo. Resolver um deixa o outro exatamente onde estava.

Primeiro passo: coloque o perfil onde o serviço o procura

O serviço do Windows lê perfis de um diretório fixo, e a GUI lê do mesmo lugar, então um perfil que funciona ao importá-lo pode continuar invisível no arranque. Coloque os arquivos .ovpn no diretório config da instalação, que normalmente fica sob Program Files. Um perfil deixado na pasta Downloads de um usuário não entra de modo algum no âmbito do serviço.

Orientações antigas apontam para uma pasta config-auto, que algumas compilações da era 2.5 respeitavam e as versões posteriores não. É por isso que uma atualização pode transformar um arranque automático que funciona em silêncio, sem nada no log sobre credenciais. Confirme qual diretório a compilação instalada lê de fato antes de mover qualquer arquivo.

Com vários perfis numa máquina, dê a cada um um adaptador com nome via dev-node. Caso contrário, competem pela mesma interface e o segundo falha de um modo que parece um problema de credenciais.

Segundo passo: inicie o serviço, não o ícone da bandeja

Pôr o serviço OpenVPN em Automatic faz com que ele inicie no arranque sem login. Esse é o mecanismo, e o ícone da bandeja não faz parte dele. Quando o serviço detém a conexão, a GUI pode não mostrar ícone nem estado, o que é esperado e não uma avaria.

A consequência é que desconectar significa parar o serviço, não clicar em Disconnect. Diga isso a quem dá suporte à máquina, ou a primeira chamada de suporte será sobre um ícone ausente.

Verifique se a conta do serviço consegue ler o perfil e o material da chave. Um problema de permissões no arranque parece no log exatamente uma falha de autenticação.

Terceiro passo: ligue a rota ao túnel

Uma entrada persistente é a ferramenta errada aqui. Adicionar uma rota com -P faz com que ela sobreviva a reinicializações e, pior, sobreviva ao fecho do túnel. Com a VPN desligada, o prefixo continua a apontar para um gateway que já não existe, pelo que o host não alcança esse destino até alguém apagar a entrada.

Três alternativas comportam-se corretamente. Empurre a rota a partir do servidor, que a adiciona ao ligar e a remove ao desligar. Adicione-a num script route-up que lê route_vpn_gateway, para que o salto seguinte venha do túnel negociado. Ou use Add-VpnConnectionRoute com um perfil VPN nativo do Windows, que liga o prefixo a essa conexão.

Quando o servidor oferece mais do que este site precisa, route-nopull recusa as rotas empurradas e deixa a tabela totalmente local. Isso serve a um perfil partilhado cujos utilizadores não devem receber uma rota predefinida corporativa.

Quarto passo: sobreviva a um arranque a frio

Iniciar o serviço antes de existir a pilha de rede produz uma tentativa falhada e nenhuma repetição. Colocá-lo em Automatic (Delayed Start), ou adicionar uma dependência do serviço de rede, elimina essa corrida. Depois repita o teste de arranque e confirme que uma segunda tentativa já não é necessária.

As alterações de rota e de adaptador exigem direitos de administrador. Um atalho de arranque por utilizador não os tem, por isso um script que funciona a partir de uma consola elevada pode não fazer nada em silêncio ao iniciar sessão. Agende-o como tarefa com os privilégios mais altos, ou deixe o serviço assumir a alteração. Depois teste-o como o utilizador que realmente iniciará sessão.

Teste a sequência que realmente implementa, não a que consegue acionar à mão. Um arranque a frio é o único teste que exercita a ordem.

Quinto passo: verifique sem a GUI

Após um reinício e um início de sessão, verifique três coisas sem abrir a GUI. O adaptador deve ter um endereço,a tabela de rotas deve mostrar o prefixo do site com o gateway do túnel como salto seguinte, e um ping para um endereço do outro lado deve responder. Cada verificação corresponde a um mecanismo diferente dos passos anteriores.

Quando o adaptador nunca aparece, o suspeito é o controlador e não o perfil. Essas duas falhas não se parecem nada no log, e só uma delas responde a uma reinstalação do software.