La configuració VPN pública ha deixat de funcionar? Llegeix l'etapa de fallada

El perfil funcionava dimarts, i divendres el client gira durant trenta segons i es rendeix. No ha canviat res a la teva màquina. Aquesta és exactament la qüestió: una configuració baixada descriu un amfitrió en un moment concret, i l'operador de l'altre costat no té cap obligació de mantenir certa aquesta descripció. La temptació és començar a editar paràmetres de seguretat fins que el túnel torni. Aquest instint és la raó per la qual la gent acaba executant un perfil amb la verificació de certificats desactivada, cosa que és pitjor que no tenir cap túnel.

El fitxer descriu un moment, no un contracte

Un fitxer de configuració és un conjunt d'afirmacions: aquest nom d'amfitrió escolta en aquest port amb aquest protocol, presenta un certificat que coincideix amb aquest nom i accepta aquestes credencials. Quan qualsevol d'elles deixa de ser certa, el fitxer és obsolet i la solució pertany al costat de l'operador de la frontera, no a la teva configuració.

Les llistes de nodes públiques ho fan explícit per la seva naturalesa. Els nodes els gestionen voluntaris, apareixen i desapareixen, les adreces es reciclen i els ports els bloqueja la xarxa on siguin. La llista és una instantània que es regenera, i la còpia del teu disc és una fotografia d'una instantània més antiga.

Els serveis comercials canvien més lentament, però no mai. Les autoritats de certificació roten, un oient es trasllada d'una adreça compartida a una de dedicada, un protocol antic es retira i arriba una llista de xifratges nova. Cadascun d'aquests canvis és invisible fins que el teu client intenta connectar-se i rep una resposta diferent de la que el fitxer espera.

Llegeix l'etapa de fallada abans de tocar cap paràmetre

El missatge d'error diu quina afirmació ha fallat, i cada afirmació té una reparació completament diferent. Editar xifratges quan el nom d'amfitrió ja no es resol perd una tarda i no ensenya res a ningú.

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

La línia del mig separa un camí bloquejat d'una negociació trencada, i la tercera mostra l'emissor i les dates de validesa del certificat que es presenta realment. Si aquest emissor no és el que el perfil fixava, el certificat ha canviat, i cap opció del client farà que la fixació antiga torni a ser correcta.

Els canvis de certificat i d'identitat són els silenciosos

La majoria de fallades s'anuncien. Els canvis d'identitat no, perquè un client que fixa un nom de certificat rebutjarà un certificat nou perfectament bo amb un missatge que molta gent llegeix com un error del programari. El túnel està bé. La fixació és obsoleta.

Busca les opcions d'identitat abans de concloure res:

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

Si el perfil porta una CA incrustada i l'operador ha rotat a una autoritat nova, el fitxer antic no pot validar el servidor nou. Substituir el bloc de CA pel que l'operador ha publicat és una reparació legítima. Esborrar la directiva de verificació no ho és, i són les mateixes pulsacions amb un resultat molt diferent.

Una actualització del client pot produir el mateix símptoma sense cap canvi de l'operador. Opcions que es toleraven en silenci ara es rebutgen, o es retira un protocol obsolet. És un límit de compatibilitat del teu programari, i val la pena provar un segon perfil amb el mateix client abans de culpar el servidor.

Només l'operador pot publicar un reemplaçament vàlid

Quan un node desapareix, el reemplaçament ha de venir de la mateixa font que va publicar l'original. Un perfil que arriba en un missatge directe perquè «fa servir el mateix nom de servidor» és una configuració no verificada d'una part desconeguda, i importar-lo li dona el control del teu encaminament.

La comprovació és barata. Descarrega el fitxer actual de la ubicació publicada, compara el punt final i el protocol amb la llista, i confirma l'empremta del material de CA en lloc de confiar en el nom del fitxer:

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

Si els dos hashos només difereixen en espais, tens un canvi de format. Si difereixen en punts finals, l'operador ha mogut alguna cosa i el fitxer publicat és l'autoritat. Si el fitxer publicat és més antic que el que tens, probablement estàs mirant una memòria cau, i la resposta obsoleta et portarà en la direcció equivocada.

Retira l'entrada antiga i registra què ha passat

Un cop verificat un reemplaçament funcional, esborra el perfil antic en lloc de guardar-lo com a alternativa. Una entrada obsoleta que connecta a mitges és un parany: es triarà durant una avaria, fallarà lentament, i qui depuri hi passarà els primers deu minuts amb el fitxer equivocat.

Mantén un registre breu fora de la configuració: la data, el punt final antic, l'etapa de fallada i què el va substituir. Els nodes públics canvien, i sis setmanes després la mateixa pregunta arriba amb una altra persona. Una línia en un fitxer de notes la respon en segons.

Si des d'una xarxa tots els nodes fallen de la mateixa manera i des d'una altra no en falla cap, deixa d'editar perfils i mira el camí local. Un portal captiu, un rang de ports filtrat o un proxy interceptor produiran errors idèntics en proveïdors no relacionats, i aquest patró és l'únic senyal que el problema mai no era el fitxer.