El servei OpenVPN falla en un perfil que la GUI obre: cinc comprovacions

Dos llançadors obren el mateix perfil en una màquina, i només la GUI es connecta. El fitxer és intacte i l’instal·lador probablement està bé; el que difereix és el context que cada llançador dona a openvpn.exe. El directori de treball, la identitat del compte i els atributs del fitxer viatgen tots amb aquest context. Comproveu-los en aquest ordre i atureu-vos al primer que expliqui l’error.

Confirmeu quin llançador falla

Comenceu demostrant la divisió. Si la GUI es connecta i el servei no amb la mateixa ruta de perfil, el fitxer és llegible per algú i la pregunta passa a ser qui el llegeix i des d’on. Si tots dos fallen, el perfil està trencat i res d’això no s’aplica. Anoteu el nom del servei i el perfil exacte que se li va indicar que carregués.

Un servei apuntat al seu propi directori d’inici automàtic potser no carrega el fitxer que teniu obert en un editor. Compareu la ruta de la configuració del servei amb la ruta de la GUI, caràcter per caràcter, perquè un nom de carpeta final o una lletra d’unitat diferent n’hi ha prou per portar-vos a la branca equivocada.

On es resolen les rutes relatives

Un perfil que fa referència a ca.crt o a un script auxiliar només pel nom demana una cerca relativa a on sigui que es trobi el procés. La GUI comença a la carpeta de configuració, així que aquests noms es resolen. Un servei iniciat pel gestor de serveis no té aquest punt de partida, i la cerca falla abans que es llegeixi cap certificat. Per això el mateix perfil funciona en un llançador i no en l’altre.

Doneu a l’embolcall un directori on començar, o feu absoluta cada referència. Reproduir el context de la GUI en una línia d’ordres es veu així:

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

Apujar la verbositat d’aquesta ordre mostra la ruta exacta que s’ha intentat. Feu-ho abans de canviar permisos, perquè un fitxer que falta i una lectura denegada necessiten correccions diferents. El registre predeterminat no els distingeix. Un indicador extra estalvia una hora d’endevinalles.

Quan la identitat del servei no pot llegir

Un servei s’executa com a identitat del sistema, no com a vós. Una ACL que dona control total al vostre usuari i a ningú més falla allà mentre funciona perfectament a la vostra sessió. Un perfil guardat en una unitat mapejada o en un recurs compartit autenticat falla pel mateix motiu. Confirmeu els permisos del fitxer abans de mirar res més.

La comprovació és una lectura dels permisos efectius més una lectura intentada com a identitat del servei. Executeu la primera part des d’un intèrpret elevat:

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

Després intenteu la mateixa lectura com a identitat del servei, per exemple amb psexec -s -i de Sysinternals, i observeu si el fitxer s’obre. Si no s’obre, cap correcció de ruta no ajudarà. Corregiu l’ACL o moveu el perfil a una ubicació que la identitat del servei pugui llegir.

El xifratge a nivell de fitxer és el segon cas, més rar. Un perfil marcat amb l’atribut Encrypting File System es desxifra de manera transparent per a l’usuari que el va xifrar i resta il·legible per a un compte de servei. Per això el mateix fitxer s’obre al vostre editor i no sota el servei.

L’atribut és visible des d’un intèrpret elevat, i comprovar-lo no obre el perfil. Executeu les dues ordres i llegiu la sortida:

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

Esborrar l’atribut fa el fitxer llegible, i també elimina la protecció que portava. Si el perfil ha de quedar protegit, poseu el material secret on la identitat del servei tingui una concessió explícita en lloc de confiar en el xifratge per usuari. Aquest arranjament sobreviu a un canvi de contrasenya, i fa que l’accés sigui revisable per algú altre que la persona que va xifrar el fitxer.

Decidir qui posseeix el túnel

La GUI pot demanar una contrasenya i pot llegir un certificat del vostre magatzem d’usuari. El servei no pot fer cap de les dues coses, així que un perfil que depèn d’un secret interactiu mai no s’iniciarà sense supervisió, per molt que es corregeixin les rutes. Aquest límit és una decisió de disseny, no un defecte a esquivar. Trieu un sol propietari abans de canviar res més.

Si el túnel ha d’estar aixecat abans de l’inici de sessió, doneu al servei una font de credencials sense supervisió i la seva pròpia còpia del perfil. Si només ha d’existir mentre sou a l’escriptori, manteniu-lo a la GUI i traieu la còpia del servei. Tots dos alhora és la configuració que produeix conflictes d’adaptador i rutes duplicades.

Aquest conflicte normalment es diagnostica com un error de configuració en lloc de dos propietaris lluitant per un adaptador. El registre d’esdeveniments mostrarà un procés que no aconsegueix obrir el dispositiu TAP, cosa que sembla un problema de permisos i no ho és. Compteu els propietaris primer.

Què llança realment l’embolcall del servei

El punt d’entrada del servei és un petit embolcall que llegeix els seus propis paràmetres desats i després inicia openvpn.exe. Quan la línia d’ordres del registre d’esdeveniments no coincideix amb la vostra expectativa, aquests valors són el que cal inspeccionar. Reinstal·lar els torna als valors predeterminats i destrueix l’evidència. Llegiu-los primer.

Els valors viuen al registre sota la clau pròpia del servei, i sc qc mostra la ruta del binari que llançarà el gestor de serveis. Compareu aquesta ruta amb la configuració desada de l’embolcall abans d’editar-ne cap.

Substituir l’embolcall per un script que controleu és més invasiu, però plega la línia d’ordres efectiva en un sol fitxer llegible. Acabeu amb un reinici, i després llegiu el registre per perfil fins que aparegui la primera línia d’inici correcta. Un estat de servei en execució només vol dir que l’embolcall no ha sortit, cosa que també és certa quan el seu fill ha mort immediatament.