A configuración VPN pública deixou de funcionar? Le a etapa de fallo

O perfil funcionaba o martes, e o venres o cliente xira durante trinta segundos e réndese. Nada cambiou na túa máquina. Esa é exactamente a cuestión: unha configuración descargada describe un host nun momento dado, e o operador do outro extremo non ten obriga de manter veraz esa descrición. A tentación é comezar a editar axustes de seguridade ata que o túnel volva. Ese instinto é a razón pola que a xente acaba executando un perfil coa verificación de certificados desactivada, o cal é peor que non ter ningún túnel.

O ficheiro describe un momento, non un contrato

Un ficheiro de configuración é un conxunto de asercións: este nome de host escoita neste porto con este protocolo, presenta un certificado que coincide con este nome e acepta estas credenciais. Cando calquera delas deixa de ser certa, o ficheiro está obsoleto e a solución pertence ao lado do operador da fronteira, non aos teus axustes.

As listas de nodos públicas fan explícito isto pola súa propia natureza. Os nodos adminístraos voluntarios, aparecen e desaparecen, os enderezos recíclanse e os portos bloquéaos a rede na que estean. A lista é unha instantánea que se rexenera, e a copia no teu disco é unha fotografía dunha instantánea máis antiga.

Os servizos comerciais cambian máis lentamente, pero non nunca. As autoridades de certificación rotan, un escoitador pasa dun enderezo compartido a un dedicado, un protocolo antigo retírase e chega unha nova lista de cifrados. Cada un deses cambios é invisible ata que o teu cliente tenta conectar e recibe unha resposta distinta da que o ficheiro espera.

Le a etapa de fallo antes de tocar un axuste

A mensaxe de erro di que aserción fallou, e cada aserción ten unha reparación completamente distinta. Editar cifrados cando o nome de host xa non resolve desperdicia unha tarde e non ensina nada a ninguén.

dig +short vpn.example.net
curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect}\n' --max-time 8 https://vpn.example.net:443/
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

A liña central separa unha ruta bloqueada dun salto de man roto, e a terceira mostra o emisor e as datas de validez do certificado que se presenta realmente. Se ese emisor non é o que fixou o perfil, o certificado cambiou, e ningunha opción do cliente fará que a fixación antiga volva ser correcta.

Os cambios de certificado e identidade son os silenciosos

A maioría dos fallos anúncianse. Os cambios de identidade non, porque un cliente que fixa un nome de certificado rexeitará un certificado novo perfectamente bo cunha mensaxe que moita xente le como un erro do programa. O túnel está ben. A fixación está obsoleta.

Busca as opcións de identidade antes de concluír nada:

grep -nE '^(remote|proto|auth|verify-x509-name|tls-crypt|key-direction|ca) ' profile.ovpn
openssl x509 -in profile-ca.crt -noout -subject -dates

Se o perfil leva unha CA incorporada e o operador cambiou a unha autoridade nova, o ficheiro antigo non pode validar o servidor novo. Substituír o bloque de CA polo publicado polo operador é unha reparación lexítima. Borrar a directiva de verificación non o é, e son as mesmas pulsacións cun resultado moi distinto.

Unha actualización do cliente pode producir o mesmo síntoma sen ningún cambio do operador. Opcións que se toleraban en silencio agora rexéitanse, ou retírase un protocolo obsoleto. É un límite de compatibilidade do teu software, e paga a pena probar un segundo perfil co mesmo cliente antes de culpar o servidor.

Só o operador pode publicar un substituto válido

Cando un nodo desaparece, o substituto ten que vir da mesma fonte que publicou o orixinal. Un perfil que chega por mensaxe directa porque «usa o mesmo nome de servidor» é unha configuración non verificada dunha parte descoñecida, e importalo dálle a esa parte o control do teu encamiñamento.

A comprobación é barata. Obtén o ficheiro actual desde a localización publicada, compara o extremo e o protocolo coa lista, e confirma a pegada do material de CA en lugar de fiarte do nome do ficheiro:

curl -sS -o current.ovpn https://example.org/nodes/current.ovpn
sha256sum current.ovpn profile.ovpn
grep -nE '^(remote|proto) ' current.ovpn

Se os dous hashes difiren só en espazos, tes un cambio de formato. Se difiren nos extremos, o operador moveu algo e o ficheiro publicado é a autoridade. Se o ficheiro publicado é máis antigo que o que tes, probablemente estás a mirar unha caché, e a resposta obsoleta enviarate na dirección equivocada.

Retira a entrada antiga e rexistra que ocorreu

Unha vez verificado un substituto funcional, borra o perfil antigo en lugar de gardalo como respaldo. Unha entrada obsoleta que conecta a medias é unha trampa: escollerase durante unha caída, fallará lentamente, e quen depure pasará os primeiros dez minutos co ficheiro equivocado.

Leva un rexistro breve fóra da configuración: a data, o extremo antigo, a etapa de fallo e que o substituíu. Os nodos públicos cambian, e seis semanas despois a mesma pregunta chega con outra persoa. Unha liña nun ficheiro de notas respóndea en segundos.

Se desde unha rede todos os nodos fallan da mesma forma e desde outra non falla ningún, deixa de editar perfís e mira a ruta local. Un portal cativo, un rango de portos filtrado ou un proxy interceptor producirán erros idénticos en provedores non relacionados, e ese patrón é o único sinal de que o problema nunca foi o ficheiro.