Borrar key-method dun perfil de OpenVPN non cambia nada
A directiva desapareceu do analizador, non do protocolo. Separa a opción obsoleta do formato de intercambio de claves antes de editar un perfil.
Un perfil que funcionou durante anos de súpeto négase a arrincar, e a mensaxe nomea unha directiva que ninguén lembra ter engadido: key-method. O seguinte resultado de busca suxire engadir key-method 2 por compatibilidade, un consello doutra época. O analizador que rexeitou a liña é actual e non ten esa opción en absoluto. Quitar a liña arranxa o arrinque e non cambia nada en como os dous pares protexen a sesión.
Ese oco entre o que contén un perfil e o que o protocolo fai realmente é todo o tema, e explica outras varias edicións que a xente fai ao mesmo tempo. Tamén explica por que esas edicións adoitan chegar en bloque.
O síntoma é un erro de análise, non un fallo do aperto de mans
As opcións lense antes de enviar ningún paquete. Un perfil cunha directiva descoñecida falla nesa etapa, así que o proceso nunca chega á rede e nunca produce un erro de aperto de mans. A redacción adoita identificar a opción e o ficheiro, o que fai deste un dos fallos máis fáciles de atribuír. Non interveñen paquetes, rutas nin devasas.
openvpn --config /etc/openvpn/client/office.ovpn --verb 3 --log /tmp/parse.log
grep -n 'Options error' /tmp/parse.log
Se a mensaxe nomea a directiva, o diagnóstico rematou: o ficheiro contén algo que esta compilación non acepta. Se a mensaxe nomea un camiño de ficheiro, o problema é unha inclusión ou unha chave que falta, que é outra sección da mesma etapa de arrinque.
O que non deberías concluír é que o cliente ou o servidor necesiten un modo de protocolo máis antigo. Un fallo de análise é un problema de vocabulario entre o teu ficheiro e o binario, e o binario neste caso simplemente descartou unha palabra do seu vocabulario.
Directiva e formato de transmisión son dúas cousas distintas
A antiga opción key-method elixía como se emmarcaba o intercambio de claves TLS, e o intercambio moderno é o método de varios paquetes que esa opción solicitaba. A opción desapareceu porque xa non elixía nada; o formato que nomeaba converteuse no único. Por tanto, quitar a liña deixa a sesión co mesmo emmarcado que antes. Unha edición de texto non pode cambialo en ningunha dirección.
Por iso reintroducir un binario antigo para “restaurar” o método 2 é a reparación equivocada. Non restaura nada agás un analizador máis antigo con valores predeterminados máis antigos, e cóstache as correccións que viñeron despois. O mesmo razoamento se aplica a debilitar unha comprobación de certificado ou unha lista de cifrados coa esperanza de que a conexión volva.
Unha comprobación útil é a versión e a configuración analizada, non a presenza da palabra no ficheiro:
openvpn --version | head -n 1
grep -rn 'key-method' /etc/openvpn/ 2>/dev/null
Que quitar, e de que ficheiro
Edita o ficheiro que o proceso en execución le realmente, e só ese ficheiro. En sistemas empaquetados adoita ser o perfil do directorio do cliente ou do servidor que indica a unidade, non unha copia no teu directorio persoal que gardas como referencia. Un perfil xerado tamén se pode reconstruír a partir dun modelo, así que un cambio feito só na copia despregada volverá tras a seguinte execución de aprovisionamento.
Borra a liña obsoleta e deixa en paz o punto final, os certificados, a política de cifrado e os axustes da canle de control. Son opcións admitidas que o proceso necesita e non están implicadas no erro de análise. Se o mesmo perfil contén outras directivas que non recoñeces, comproba cada unha contra a versión que executas en lugar de borrar un grupo delas ata que o proceso arrinque.
Despois arrinca a instancia prevista e le a súa saída de arrinque. Un arrinque limpo co oínte presente é a confirmación de que esta etapa rematou; unha proba de cliente despois responde a outra pregunta.
Un perfil rexeitado e un cliente rexeitado parécense
Dous fallos producen fíos de soporte parecidos e necesitan probas distintas. Un servidor que rexeita a súa propia configuración nunca arrinca, así que ningún cliente pode conectarse a el. Un servidor que arrinca ben e rexeita un cliente está en marcha, e o seu rexistro contén o motivo: un problema de certificado, unha opción empurrada que o cliente non acepta, unha discrepancia de cifrado.
A opción eliminada non é un diagnóstico para o segundo caso, e recorrer a ela desperdicia a mesma hora dúas veces. Se o rexistro do cliente mostra o rexeitamento do servidor, le ese rexeitamento; se mostra un erro local, o ficheiro que hai que inspeccionar é o perfil do cliente. Recorrer a unha directiva que xa non existe atrasa ambas as investigacións na mesma medida.
Preguntas de compatibilidade que a liña nunca respondeu
Os perfís que circulan con esta directiva adoitan levar unha historia sobre unha plataforma concreta, e a historia sobrevive ao motivo técnico. Un cliente móbil ou de escritorio segue necesitando un perfil completo compatible: unha cadea de certificados de confianza, un cifrado de datos que ambos os extremos acepten, un modo de canle de control que ambos os extremos implementen e ningunha directiva que rexeite a compilación do cliente. Nada diso o decide a presenza ou a ausencia da antiga liña key-method.
A compresión é unha cuestión de política aparte coa mesma forma. Quitar unha liña key-method non di nada sobre se unha directiva de compresión está admitida ou é aceptable no teu despregamento, e as dúas decisións deben tomarse de forma independente. Borrar varios axustes relevantes para a seguridade á vez ata que algo conecte é a maneira en que un perfil que funciona se converte nun sen explicación.
Mantén un rexistro breve do que quitaste e por que: a opción, a versión que a rexeitou e o comando que mostrou o erro. A seguinte persoa que herde o perfil necesitará exactamente eses tres feitos, e é máis barato escribilos agora que reconstruílos despois.