El VPN es desconnecta constantment: prova la ràdio abans que el servidor

Una desconnexió del VPN pot començar molt abans que cap trànsit arribi al servidor. Una pèrdua de Wi-Fi, un traspàs de Wi-Fi a la xarxa mòbil, la congestió del punt d'accés local i un telèfon que s'adorm poden interrompre el camí extern mentre el programari del túnel informa d'una fallada neta. Aneu de dins cap a fora: primer l'enllaç, després els esdeveniments del client, després una comparació controlada i només llavors el servidor. Aquest ordre us evita canviar nodes de sortida per un problema que viu a l'habitació.

Mireu l'enllaç, no la icona del senyal

Busqueu transicions de l'enllaç, no les barres del senyal. Un dispositiu pot mostrar un senyal fort mentre el punt d'accés està saturat, mentre hi ha un traspàs d'itinerància en curs o mentre una política d'estalvi d'energia atura la ràdio amb la pantalla apagada.

Registreu l'estat de la interfície, la porta d'enllaç actual i l'hora de cada canvi. Després comproveu si la desconnexió coincideix amb la transició. Una caiguda que passa cada cop que el telèfon es mou entre habitacions és un problema d'enllaç fins que es demostri el contrari, sigui quin sigui el servidor que mostra l'aplicació.

Llegiu els esdeveniments de reconnexió del client

La majoria de clients registren un motiu de la desconnexió i una marca temporal del proper intent. Un túnel que renegocia en qüestió de segons i després funciona és un esdeveniment diferent d'un que queda aturat fins que el canvieu manualment.

Les reconnexions curtes repetides apunten al camí extern, perquè el client continua arribant al servidor i perdent la sessió. Un túnel que queda aturat apunta a l'autenticació, a un canvi de punt final o a una política, perquè el client no arriba prou lluny per perdre res. Llegiu els dos patrons per separat abans de tocar la configuració.

Compareu un segon punt final amb cura

Un segon punt final és una comparació útil i no és, per si sol, un experiment controlat. Canvia la ruta, la infraestructura i sovint el país, així que una diferència entre dos punts finals no demostra que el primer servidor estigui avariat.

Manteniu el dispositiu, la xarxa d'accés i la càrrega de treball fixos i anoteu què més va canviar quan vau canviar. Si els dos punts finals fallen alhora al mateix lloc, el camí local és el factor comú. Si només en falla un, el servidor o la ruta cap a ell passa a ser la pista. Anoteu els factors de confusió perquè la conclusió no superi les proves.

Correlacioneu amb el servidor que administreu

Si administreu el punt final, feu coincidir l'hora de l'intent amb els registres d'escolta i d'associació. Diversos clients sense relació que fallen a la mateixa porta d'enllaç són una prova diferent d'un sol telèfon que cau sempre que es mou.

Una resposta d'un igual no estableix una salut contínua de l'aplicació. Després de la recuperació, proveu el recurs que realment necessiteu, perquè un intercanvi de salutació correcte i un servidor accessible poden coexistir amb un camí d'aplicació trencat.

Escriviu l'informe que ho acota

Separeu quatre afirmacions: pèrdua de l'enllaç local, abast exterior, negociació del túnel i estat propi de l'aplicació. Cadascuna té la seva prova, i un informe que les manté separades diu a la persona següent on ha de mirar.

Anoteu també els límits de la comparació. Si una política va impedir una prova de camí directe, digueu-ho en lloc de presentar la comparació de punts finals com una prova. L'etiqueta de país a l'aplicació no identifica la ruta completa, i un servidor geogràficament proper encara es pot assolir per un camí congestionat.

La pàgina de limitacions conegudes del projecte WireGuard és un recordatori útil que un protocol pot ser correcte i deixar igualment el comportament de l'enllaç al sistema operatiu. Acabeu repetint la mateixa prova després de la propera desconnexió, perquè un sol esdeveniment és una dada i un patró és un diagnòstic.