A VPN rompe despois dunha actualización do cliente? Compare a negociación

As actualizacións substitúen o compoñente que analiza o seu perfil e negocia o túnel. O primeiro fallo tras unha actualización é evidencia sobre un cambio concreto, non un veredicto sobre a versión. Gardar ese erro coa súa versión e a súa marca de tempo é o paso máis valioso que pode dar antes de reinstalar calquera cousa.

Dous mecanismos explican a maioría destas roturas. Separares é a tarefa.

Que cambiou a negociación baixo os seus pés

OpenVPN negocia o cifrado da canle de datos en lugar de tomalo dunha única directiva, e as opcións que controlan esa negociación cambiaron de significado entre versións. Un perfil escrito para un cliente máis antigo pode conectarse e despois non acordar unha canle de datos, o que se manifesta como unha desconexión en vez dun erro de configuración claro. As versións máis novas tamén endurecen ou retiran comportamentos herdados e traen un modo de compatibilidade para pares que aínda non se moveron. Por iso unha actualización pode romper un perfil que funcionaba sen tocar un só byte do ficheiro.

O efecto sobre o cliente é asimétrico. A canle de control lévantase, a autenticación ten éxito e o túnel morre despois, que é a sinatura dun desaxuste de negociación e non dun perfil rexeitado.

Lea a versión instalada antes de teorizar sobre o servidor. Esa cadea é un feito local que pode comprobar sen pedirlle acceso a ninguén.

O perfil pode analizarse e significar outra cousa

Unha directiva que sobrevive á análise non é necesariamente unha directiva que segue facendo o que o seu autor pretendía. As opcións poden aceptarse por compatibilidade e ignorarse, renomearse ou aplicarse nun caso máis estreito que antes. Como nada dá erro, o perfil parece correcto mentres o comportamento por debaixo cambiou. Ese silencio é o que fai caras estas regresións.

Pregunte que liñas son realmente responsables do resultado negociado e despois contrásteas coa documentación da versión que executa agora. Esa comparación é curta, e nela está a diferenza entre unha corrección e unha reversión.

openvpn --version | head -n 2
openvpn --show-ciphers | head -n 10
grep -nE '^(cipher|data-ciphers|ncp-|tls-)' office.ovpn

A plataforma moveuse ao mesmo tempo

As versións do cliente raramente chegan soas. Unha actualización do sistema operativo, un aviso de permiso que agora esixe unha concesión explícita ou unha política xestionada aplicada ao dispositivo poden chegar a mesma semana e producir un fallo do que se culpa o cliente. As plataformas móbiles engaden unha capa propia, porque a aplicación pide un túnel ao sistema e o sistema decide que pode encamiñar ese túnel.

Rexiste eses cambios por separado na liña de tempo. Cando a autenticación ten éxito pero fallan as rutas ou a resolución de nomes, a etapa interesante é a posterior ao aperto de mans, e debilitar a validación do certificado non a tocará.

Volva probar o evento que iniciou o informe

Reproduza a secuencia orixinal e non unha versión simplificada: a conexión inicial, a aplicación que fallou e unha reconexión normal tras un cambio de rede. Un túnel que se levanta en condicións de proba e aínda así cae na ruta de reconexión non está arranxado, e a diferenza adoita sinalar onde vive o defecto real. Un informe que omite o paso de reconexión pecha un fallo que segue aberto.

Obteña o perfil compatible do operador ou a corrección do provedor pola canle verificada en lugar de reverter todo. Unha degradación ampla tamén restaura as correccións de seguridade que traía a actualización, e ese intercambio raramente vale unha conexión que funcione.