O VPN desconéctase sen parar: proba a radio antes que o servidor

Unha desconexión de VPN pode comezar moito antes de que calquera tráfico chegue ao servidor. A perda de Wi-Fi, un traspaso de Wi-Fi á rede móbil, a conxestión no punto de acceso local e un teléfono que se durme poden interromper o camiño exterior mentres o software do túnel informa dun fallo limpo. Avance desde o dispositivo cara a fóra: primeiro a ligazón, despois os acontecementos do propio cliente, logo unha comparación controlada e só entón o servidor. Esa orde evítalle cambiar nodos de saída por un problema que vive na habitación.

Mire a ligazón, non a icona de sinal

Busque transicións da ligazón en lugar de barras. Un dispositivo pode mostrar un sinal forte mentres o punto de acceso está saturado, mentres hai un traspaso de itinerancia en curso ou mentres unha política de aforro de enerxía apaga a radio coa pantalla apagada.

Rexistre o estado da interface, a pasarela actual e a hora de cada cambio. Despois comprobe se a desconexión coincide coa transición. Unha caída que ocorre cada vez que o teléfono se move entre habitacións é un problema de ligazón ata que se demostre o contrario, sexa cal sexa o servidor que mostre a aplicación.

Lea os acontecementos de reconexión do cliente

A maioría dos clientes rexistran un motivo da desconexión e unha marca temporal do seguinte intento. Un túnel que renegocia en cuestión de segundos e logo funciona é un acontecemento distinto dun que queda caído ata que o activa manualmente.

As reconexións breves repetidas apuntan ao camiño exterior, porque o cliente segue chegando ao servidor e perdendo a sesión. Un túnel que queda caído apunta á autenticación, a un cambio de punto final ou a unha política, porque o cliente non chega o suficiente lonxe como para perder algo. Lea os dous patróns por separado antes de tocar a configuración.

Compare un segundo punto final con coidado

Un segundo punto final é unha comparación útil e non é, por si só, un experimento controlado. Cambia a ruta, a infraestrutura e a miúdo o país, así que unha diferenza entre dous puntos finais non demostra que o primeiro servidor estea defectuoso.

Manteña fixos o dispositivo, a rede de acceso e a carga de traballo e anote que máis cambiou ao cambiar. Se os dous puntos finais fallan á vez no mesmo lugar, o camiño local é o factor común. Se só falla un, o servidor ou a ruta ata el pasa a ser a pista. Anote os factores de confusión para que a conclusión non se adiante ás probas.

Correlacione co servidor que administra

Se administra o punto final, faga coincidir a hora do intento cos rexistros de escoita e de asociación. Varios clientes sen relación que fallan na mesma pasarela son unha proba distinta dun só teléfono que cae sempre que se move.

Unha soa resposta dun par non establece unha saúde continua da aplicación. Tras a recuperación, probe o recurso que realmente necesita, porque unha aperta de mans correcta e un servidor accesible poden coexistir cun camiño de aplicación roto.

Escriba o informe que o acota

Separe catro afirmacións: perda da ligazón local, alcance exterior, negociación do túnel e estado propio da aplicación. Cada unha ten a súa propia proba, e un informe que as mantén separadas di á seguinte persoa onde mirar.

Anote tamén os límites da comparación. Se unha política impediu unha proba de camiño directo, dígao en lugar de presentar a comparación de puntos finais como proba. A etiqueta de país na aplicación non identifica a ruta completa, e un servidor xeograficamente próximo aínda se pode alcanzar por un camiño conxestionado.

A páxina de limitacións coñecidas do proxecto WireGuard é un recordatorio útil de que un protocolo pode ser correcto e aínda así deixar o comportamento da ligazón ao sistema operativo. Remate repetindo a mesma proba tras a seguinte desconexión, porque un só acontecemento é un dato e un patrón é un diagnóstico.