O servizo OpenVPN falla nun perfil que abre a GUI: cinco comprobacións

Dous lanzadores abren o mesmo perfil nunha máquina, e só a GUI se conecta. O ficheiro está intacto e o instalador probablemente está ben; o que difire é o contexto que cada lanzador lle dá a openvpn.exe. O directorio de traballo, a identidade da conta e os atributos do ficheiro viaxan todos con ese contexto. Compróbeos nesa orde e detéñase no primeiro que explique o erro.

Confirme que lanzador falla

Empece demostrando a división. Se a GUI se conecta e o servizo non, coa mesma ruta de perfil, o ficheiro é lexible por alguén e a pregunta pasa a ser quen o le e desde onde. Se fallan os dous, o perfil está roto e nada diso se aplica. Anote o nome do servizo e o perfil exacto que se lle indicou cargar.

Un servizo apuntado ao seu propio directorio de inicio automático pode que non cargue o ficheiro que ten aberto nun editor. Compare a ruta da configuración do servizo coa ruta da GUI, carácter por carácter, porque un nome de cartafol final ou unha letra de unidade distinta abonda para levalo á rama equivocada.

Onde se resolven as rutas relativas

Un perfil que fai referencia a ca.crt ou a un script auxiliar só polo nome pide unha busca relativa a onde estea o proceso. A GUI comeza no cartafol de configuración, así que eses nomes se resolven. Un servizo iniciado polo xestor de servizos non ten ese punto de partida, e a busca falla antes de que se lea ningún certificado. Por iso o mesmo perfil funciona nun lanzador e non no outro.

Déalle á envoltura un directorio onde comezar, ou faga absoluta cada referencia. Reproducir o contexto da GUI nunha liña de ordes vese así:

openvpn --cd "C:\VPN\profiles\office" --config "C:\VPN\profiles\office\office.ovpn"

Subir a verbosidade dese comando mostra a ruta exacta que se intentou. Fagao antes de cambiar permisos, porque un ficheiro que falta e unha lectura denegada necesitan correccións distintas. O rexistro predeterminado non os distingue. Un indicador extra aforra unha hora de conxecturas.

Cando a identidade do servizo non pode ler

Un servizo execútase como identidade do sistema, non como vostede. Unha ACL que lle dá control total ao seu usuario e a ninguén máis falla alí mentres funciona perfectamente na súa sesión. Un perfil gardado nunha unidade mapeada ou nun recurso compartido autenticado falla polo mesmo motivo. Confirme os permisos do ficheiro antes de mirar calquera outra cousa.

A comprobación é unha lectura dos permisos efectivos máis unha lectura intentada como a identidade do servizo. Execute a primeira parte desde unha consola elevada:

icacls "C:\VPN\profiles\office\office.ovpn"

Despois intente a mesma lectura como a identidade do servizo, por exemplo con psexec -s -i de Sysinternals, e observe se o ficheiro se abre. Se non se abre, ningunha corrección de ruta axudará. Corrixa a ACL ou mova o perfil a unha localización que a identidade do servizo poida ler.

A cifraxe a nivel de ficheiro é o segundo caso, máis raro. Un perfil marcado co atributo Encrypting File System descífrase de forma transparente para o usuario que o cifrou e segue sendo ilexible para unha conta de servizo. Por iso o mesmo ficheiro se abre no seu editor e non baixo o servizo.

O atributo é visible desde unha consola elevada, e comprobalo non abre o perfil. Execute os dous comandos e lea a saída:

cipher /s:"C:\VPN\profiles\office"
attrib "C:\VPN\profiles\office\office.ovpn"

Borrar o atributo fai o ficheiro lexible, e tamén elimina a protección que levaba. Se o perfil ten que seguir protexido, poña o material secreto onde a identidade do servizo teña unha concesión explícita en lugar de confiar na cifraxe por usuario. Esa disposición sobrevive a un cambio de contrasinal, e fai que o acceso sexa revisable por alguén distinto da persoa que cifrou o ficheiro.

Decidir quen é dono do túnel

A GUI pode pedir un contrasinal e pode ler un certificado do seu almacén de usuario. O servizo non pode facer ningunha das dúas cousas, así que un perfil que depende dun segredo interactivo nunca arrincará sen supervisión, por moito que se corrixan as rutas. Ese límite é unha decisión de deseño, non un defecto que haxa que sortear. Escolla un único propietario antes de cambiar calquera outra cousa.

Se o túnel ten que estar levantado antes do inicio de sesión, déalle ao servizo unha fonte de credenciais sen supervisión e a súa propia copia do perfil. Se só necesita existir mentres vostede está no escritorio, mantéñao na GUI e quite a copia do servizo. Ambos á vez é a configuración que produce conflitos de adaptador e rutas duplicadas.

Ese conflito adoita diagnosticarse como un erro de configuración en lugar de dous propietarios loitando por un adaptador. O rexistro de eventos mostrará un proceso que non consegue abrir o dispositivo TAP, o que parece un problema de permisos e non o é. Conte primeiro os propietarios.

Que lanza realmente a envoltura do servizo

O punto de entrada do servizo é unha pequena envoltura que le os seus propios parámetros gardados e despois inicia openvpn.exe. Cando a liña de ordes do rexistro de eventos non coincide coa súa expectativa, eses valores son o que hai que inspeccionar. Reinstalar devólveos aos valores predeterminados e destrúe a evidencia. Léaos primeiro.

Os valores viven no rexistro baixo a clave propia do servizo, e sc qc mostra a ruta do binario que lanzará o xestor de servizos. Compare esa ruta coa configuración gardada da envoltura antes de editar calquera das dúas.

Substituír a envoltura por un script que vostede controle é máis invasivo, pero prega a liña de ordes efectiva nun só ficheiro lexible. Termine cun reinicio, e despois lea o rexistro por perfil ata que apareza a primeira liña de inicio correcta. Un estado de servizo en execución só significa que a envoltura non saíu, o que tamén é certo cando o seu fillo morreu de inmediato.