OpenVPN en Windows: iniciar o túnel automaticamente e conservar as rutas

Aquí enrédanse dous requisitos: o túnel debe levantarse antes de que ninguén inicie sesión, e o tráfico dun segundo sitio debe seguilo. Son problemas separados con mecanismos separados. O arranque do servizo decide o primeiro, e a vida da ruta decide o segundo. Resolver un deixa o outro exactamente onde estaba.

Primeiro paso: poña o perfil onde o busca o servizo

O servizo de Windows le os perfís dun directorio fixo, e a GUI le do mesmo lugar, así que un perfil que funciona ao importalo pode seguir sendo invisible no arranque. Poña os ficheiros .ovpn no directorio config da instalación, que normalmente está baixo Program Files. Un perfil deixado no cartafol Downloads dun usuario non entra en absoluto no ámbito do servizo.

As indicacións antigas apuntan a un cartafol config-auto, que algunhas compilacións da era 2.5 respectaban e as versións posteriores non. Por iso unha actualización pode converter un arranque automático que funciona en silencio, sen nada no rexistro sobre credenciais. Confirme que directorio le realmente a compilación instalada antes de mover ningún ficheiro.

Con varios perfís nunha máquina, dea a cada un un adaptador con nome mediante dev-node. Se non, compiten pola mesma interface e o segundo falla dun xeito que parece un problema de credenciais.

Segundo paso: inicie o servizo, non a icona da bandexa

Pór o servizo OpenVPN en Automatic fai que se inicie no arranque sen ningún inicio de sesión. Ese é o mecanismo, e a icona da bandexa non forma parte del. Cando o servizo é dono da conexión, a GUI pode non mostrar icona nin estado, o cal é o esperado e non unha avaría.

A consecuencia é que desconectar significa deter o servizo, non facer clic en Disconnect. Dígallo a quen dea soporte á máquina, ou a primeira chamada de soporte será por unha icona que falta.

Comprobe que a conta do servizo pode ler o perfil e o material de clave. Un problema de permisos no arranque parece no rexistro exactamente un fallo de autenticación.

Terceiro paso: ate a ruta ao túnel

Unha entrada persistente é a ferramenta equivocada aquí. Engadir unha ruta con -P fai que sobreviva aos reinicios e, peor aínda, fai que sobreviva ao peche do túnel. Coa VPN abaixo, o prefixo segue apuntando a unha pasarela que xa non está, así que o host non pode alcanzar ese destino ata que alguén borre a entrada.

Tres alternativas compórtanse correctamente. Empurre a ruta desde o servidor, que a engade ao conectar e a quita ao desconectar. Engádaa nun script route-up que lea route_vpn_gateway, para que o seguinte salto veña do túnel negociado. Ou use Add-VpnConnectionRoute cun perfil VPN nativo de Windows, que ata o prefixo a esa conexión.

Cando o servidor ofrece máis do que este sitio necesita, route-nopull rexeita as rutas empurradas e deixa a táboa totalmente local. Iso encaixa cun perfil compartido cuxos usuarios non deben recibir unha ruta predeterminada corporativa.

Cuarto paso: sobreviva a un arranque en frío

Iniciar o servizo antes de que exista a pila de rede produce un intento fallido e ningún reintento. Pór en Automatic (Delayed Start), ou engadir unha dependencia do servizo de rede, elimina esa carreira. Despois repita a proba de arranque e comprobe que xa non fai falta un segundo intento.

Os cambios de ruta e de adaptador necesitan dereitos de administrador. Un atallo de inicio por usuario non os ten, así que un script que funciona desde unha consola elevada pode non facer nada en silencio ao iniciar sesión. Programe no como tarefa cos privilexios máis altos, ou deixe que o servizo asuma o cambio. Despois próbeo como o usuario que realmente iniciará sesión.

Probe a secuencia que realmente despregue, non a que pode desencadear a man. Un arranque en frío é a única proba que exercita a orde.

Quinto paso: verifique sen a GUI

Tras un reinicio e un inicio de sesión, comprobe tres cousas sen abrir a GUI. O adaptador debe ter un enderezo,a táboa de rutas debe mostrar o prefixo do sitio coa pasarela do túnel como seguinte salto, e un ping a un enderezo do lado remoto debe responder. Cada comprobación corresponde a un mecanismo distinto dos pasos anteriores.

Cando o adaptador nunca aparece, o sospeitoso é o controlador e non o perfil. Eses dous fallos non se parecen en nada no rexistro, e só un deles responde a reinstalar o software.