Temps d'espera de la connexió VPN: DNS, transport, negociació o inici de sessió

“La connexió ha expirat” és l'error menys específic que pot imprimir un client VPN. Vol dir que una operació ha perdut el seu termini, i cada etapa, des de la resolució de noms fins a la resposta d'inici de sessió, té un termini. Els clients que només mostren el missatge final fan que les etapes semblin idèntiques, així que la gent allarga el temps d'espera, canvia el port i reinstal·la el perfil, en aquest ordre, sense aprendre res. Comparar les etapes és més ràpid: cadascuna falla en un lloc diferent, i cada fallada deixa un tipus diferent de prova.

Quatre etapes, quatre fallades diferents

La seqüència és fixa encara que el client l'amagui: el nom s'ha de resoldre, s'ha d'establir un transport cap a l'adreça resultant, el protocol ha de negociar els seus paràmetres i claus, i el compte s'ha d'autenticar. La guia de resolució de problemes de connectivitat d'OpenVPN segueix el mateix ordre per al seu propi client, i els altres la segueixen de prop. Un temps d'espera a la segona etapa i un a la quarta no tenen res en comú excepte la paraula de la pantalla.

Llegeix el registre buscant l'última línia que indica progrés, no l'última línia abans de l'error. La majoria de clients imprimeixen una adreça resolta, un sòcol establert, un handshake iniciat o una sol·licitud d'autenticació, i l'etapa que segueix aquesta línia és la que ha expirat.

La resolució de noms falla abans de qualsevol contacte

Si el punt final no es resol mai, el client no té a què connectar-se i no s'ha fet cap treball de transport. Aquesta fallada sol ser instantània en lloc d'un temps d'espera complet, que és la manera més barata de distingir-la de la resta. Prova el nom amb el resoldre del sistema i amb un segon resoldre, i compara les dues respostes abans de concloure que el servidor està caigut.

Una adreça antiga copiada d'un missatge de fòrum és una causa habitual d'un temps d'espera que sembla un problema del servidor, perquè ara l'adreça pertany a una altra cosa o a res. Fes servir el perfil actual de l'operador en lloc de substituir una adreça que abans funcionava. Una resposta de ping absent no és prova en cap sentit: molts punts finals descarten ICMP mentre serveixen perfectament bé.

La configuració del transport espera un paquet que no arribarà

Quan el DNS està bé i el client encara crema tot el temps d'espera, la capa de transport és el sospitós. A TCP pots provar el port directament; Test-NetConnection a Windows o nc -vz a Linux et diu si alguna cosa accepta la connexió, i això és més útil que un ping. A UDP no ho pots provar de la mateixa manera, perquè no hi ha cap handshake per completar en aquesta capa, i aquesta asimetria provoca moltes conclusions errònies.

El que prova una prova TCP és limitat: un servei que accepta el port 443 no és necessàriament l'oient VPN, i un punt final només UDP no té cap port TCP per acceptar res. Reescriure un perfil d'UDP a TCP no crea un oient a l'altre costat; només canvia què espera el teu client. Si la xarxa filtra el protocol, el canvi produeix un temps d'espera diferent a la mateixa etapa.

Els portals captius mereixen la seva pròpia comprovació en aquesta etapa. Fins que el portal autoritzi el dispositiu, el trànsit sortint va al portal i l'intent de túnel simplement es penja. Completa primer el portal al navegador, torna-ho a provar després, i no canviïs el perfil mentre el portal encara estigui pendent.

La negociació i l'inici de sessió volen dir que el servidor ha respost

Un cop el túnel arriba al servidor, el client inicia un handshake i l'error canvia de caràcter. Una aturada aquí és de compatibilitat, no d'abast: versions de protocol desajustades, un xifratge o una configuració de canal de dades que l'altre costat no acceptarà, o un perfil que espera una funció que el servidor no ofereix. OpenVPN ha mogut els seus valors per defecte de negociació entre versions majors prou sovint que un perfil escrit per a una generació pot arribar al servidor i encara no aixecar-se.

L'autenticació és l'última etapa i la més fàcil de llegir malament. Un rebuig explícit és una resposta, cosa que vol dir que el camí funciona i el problema és la identitat, el certificat o l'estat del compte. Un flux d'inici de sessió únic basat en navegador és un tercer cas: el client espera una acció que no has fet, o un navegador que no pot llançar, i no arribarà res fins que acabis aquest pas.

Compara les proves abans de canviar el reintent

Mantén el dispositiu i el perfil fixos i canvia una cosa alhora, començant per la xarxa. Si el mateix perfil es connecta amb un punt d'accés del telèfon i expira amb el Wi-Fi de l'hotel, la variable és el camí, no el servidor. Si falla a tot arreu, la variable és el perfil o el punt final. Si només falla a una hora del dia, captura la marca de temps i compara-la amb esdeveniments del costat del servidor abans de suposar res sobre la càrrega.

Per a un servei que administres, la comparació decisiva és si l'intent arriba o no. Una connexió que arriba a l'oient i després s'atura pertany a l'etapa de negociació; una que mai no apareix a la vista de l'oient és un problema de transport o de resolució, i cap ajust de reintents no ho mourà. Els registres del servidor també separen un inici de sessió rebutjat d'una caiguda silenciosa, que és la diferència entre una correcció d'identitat i una de tallafoc.

Anota la versió del client, el nom del perfil, l'hora de l'intent amb la seva zona horària i el primer error útil en lloc de l'última línia de desconnexió. Trec les claus i el material amb credencials abans de compartir l'extracte. Després fes una correcció significativa i reintenta, perquè un termini més llarg només ajuda l'operació lenta documentada i no fa res per a una adreça equivocada o un port bloquejat.