Por que OpenVPN di ca en Windows: unha ruta sen comiñas, non un certificado defectuoso

OpenVPN non arrinca, e a mensaxe de fallo sinala unha liña que parece correcta: Unrecognized option or missing or extra parameter(s) in office.ovpn:42: ca. O certificado non cambiou, o ficheiro ábrese nun editor e nada da ruta parece estar mal. O analizador non obxecta o nome da opción; obxecta cantos argumentos chegaron con ela. Catro comprobacións resolven case todos os casos, e paga a pena executalas por orde de custo.

Por que o analizador culpa a opción

Cada liña de configuración divídese por espazos e por comiñas antes de que a vexa calquera opción. Por iso un valor que contén un espazo chega como varios argumentos se non vai entre comiñas, e a opción dona da liña informa do desaxuste. En Windows o directorio de instalación predeterminado faino seguro, porque C:\Program Files está no medio da ruta por construción. O certificado nunca se abre neste fallo, así que comprobar se o ficheiro existe non demostra nada útil.

O número de liña indicado adoita ser correcto, e a opción indicada é a que consumiu a liña. Cando a opción nomeada é unha que sabe que nunca escribiu, lea a liña de enriba, porque unha comiña perdida dentro dun bloque anterior despraza a análise. Así é como un bloque de certificado acaba culpado do reconto de argumentos.

ca C:\Program Files\OpenVPN\config\office-ca.crt

Pon comiñas en toda ruta que conteña un espazo

Un par de comiñas dobres arredor do valor é toda a reparación, e as barras inclinadas cara adiante acéptanse en Windows, así que o escape nunca pasa a formar parte do problema. Corrixa todas as opcións de ruta na mesma pasada, porque o analizador detense no primeiro fallo e a seguinte só agarda o próximo reinicio. O conxunto adoita incluír ca, cert, key, tls-auth e auth-user-pass.

ca "C:/Program Files/OpenVPN/config/office-ca.crt"
cert "C:/Program Files/OpenVPN/config/office.crt"
key "C:/Program Files/OpenVPN/config/office.key"

Unha busca polo nome do directorio atopa cada aparición máis rápido que ler o ficheiro. Execútea antes de calquera edición, para que a lista estea completa:

Select-String -Path .\office.ovpn -Pattern 'Program Files'

Mover o perfil a unha ruta sen espazos é unha alternativa válida, e só é válida se cada ruta se move con el. Un perfil migrado a medias reproduce o mesmo erro con outro nome de ficheiro, algo máis difícil de detectar porque a mensaxe agora sinala unha ruta que acaba de crear. Escolla un enfoque e remáteo.

Recupere a declaración de modo antes dos certificados

A segunda causa habitual produce outra mensaxe coa mesma tarde perdida. Un perfil de cliente debe declarar o seu modo preto do principio, e esa declaración pérdese facilmente cando só se pegan os bloques de certificado nun ficheiro novo. Sen ela, OpenVPN le o ficheiro cun conxunto distinto de valores predeterminados, e o dano aparece moito máis tarde como un conflito entre opcións ou un fallo de inicio de sesión. A liña que falta é barata de comprobar e cara de esquecer.

client
dev tun
proto udp
remote vpn.example.net 1194

Manteña unha directiva por liña mentres estea alí. As liñas unidas producen exactamente o erro de reconto de argumentos da primeira sección, e a liña indicada parece razoable porque a unión ocorreu onde o editor partiu o texto. Lea a liña en bruto, non a representada.

O dano de codificación parece un nome de opción

Un ficheiro gardado como UTF-16, coa marca de orde de bytes incluída, oculta a súa primeira opción ao analizador, e os bytes soltos poden pegarse ao nome da opción na mensaxe. Garde o ficheiro como UTF-8 sen marca de orde de bytes, volva abrilo e confirme que o primeiro carácter é unha letra normal. Os editores, a redirección de PowerShell e o texto pegado desde unha xanela de chat cambian a codificación sen preguntar.

Format-Hex .\office.ovpn | Select-Object -First 1

A marca de orde de bytes aparece como bytes marcadores iniciais antes de calquera texto, e borrar eses caracteres á man é unha xogada perdedora porque o editor volve escribilos ao gardar. Garde o ficheiro de novo cunha codificación explícita. Os finais de liña son máis indulxentes, pero un ficheiro sen salto de liña ao final aínda pode fundir a última directiva coa anterior tras unha edición.

Que comprobación facer primeiro, e por que

Empece pola codificación, porque custa un comando e invalida calquera outra lectura do ficheiro. Logo as comiñas, despois a declaración de modo e as demais directivas obrigatorias, e só despois os certificados, as chaves e as credenciais. Traballar nesa orde mantén cada paso reversible, porque un certificado cambiado para arranxar un problema de comiñas deixa unha instalación funcionando cun fallo novo a dúas edicións do orixinal. A orde importa máis que as comprobacións individuais.

Conserve unha copia intacta do ficheiro tal como o entregou o operador. Se unha edición posterior o rompe, unha diferenza con esa copia mostra se se moveu unha comiña, un salto de liña ou un byte de marca, o que é máis rápido que reler o erro. A referencia de opcións de cada directiva está no manual de OpenVPN da versión instalada.