Un reset de TCP no demuestra que tu VPN esté bloqueada

«Conexión restablecida, reiniciando» aparece en el registro del cliente, y la conclusión llega antes que la evidencia. Alguien decide que la red bloquea la VPN, o que el certificado está mal, o que un país concreto interfiere. Un reset es un paquete TCP que termina una conexión, y la línea del registro anota que tu cliente recibió uno. No nombra el dispositivo que lo envió ni el motivo.

Un reset es un paquete, no un veredicto

TCP define el procesamiento del reset: un segmento con la bandera RST termina la conexión de inmediato. El receptor no negocia, no reintenta ni pregunta por qué. Informa del reset y sigue adelante.

Eso es todo lo que sabe el cliente. El RST pudo venir del servidor, de un proxy, de un cortafuegos o de un balanceador de carga que perdió su estado.

La atribución es un ejercicio aparte. Una dirección de origen aparente en una captura no prueba el origen físico y no dice nada sobre la decisión de política que hay detrás. Los dispositivos intermedios pueden falsificar direcciones, y los dispositivos con estado pueden reiniciar por tiempo de espera en lugar de por intención. Tratar el reset como un veredicto se salta la parte en la que lo averiguas.

Confirma qué conexión se reinició

Primero comprueba que el perfil activo use realmente TCP. Un reset en un túnel UDP no tiene sentido, y un registro de un proxy HTTP puede referirse a una pata TCP distinta de la propia VPN.

Anota el destino, el puerto, la hora del intento y la etapa a la que había llegado el cliente.

La etapa es el campo más útil. Un reset durante el apretón de manos TLS apunta a un conjunto de sospechosos; un reset después de la autenticación apunta a otro. Sin la etapa, todas las teorías encajan.

Compara ambos extremos de la ruta

Si administras el servidor, compara sus eventos para el mismo intento. ¿Aceptó la conexión? ¿La cerró a propósito? ¿Una respuesta salió de un límite y nunca llegó al siguiente?

Captura en el cliente y en el servidor si puedes. Un reset que aparece en el cliente pero no en el servidor no se originó en el servidor.

Vigila los segmentos RST en ambas direcciones:

sudo tcpdump -ni any 'tcp[tcpflags] & tcp-rst != 0' -c 20
ss -tnp | grep 198.51.100.20

Acota con una comparación controlada

Una segunda red aprobada puede decirte si el fallo sigue al cliente o a la ruta. Si el mismo perfil funciona en otro sitio, la configuración del cliente probablemente esté bien y la variable sea la ruta.

Eso todavía no identifica un dispositivo intermedio concreto. Reduce el alcance a una ruta, que es un resultado útil y honesto.

Mantén la distinción entre «esta ruta falla» y «este actor con nombre lo causó». La primera es comprobable; la segunda normalmente no desde un solo cliente.

Comprueba la solución sin cambiar la configuración de confianza

No desactives la verificación TLS, no regeneres credenciales ni anuncies una política de bloqueo a partir de una línea de reset. Cada uno de esos cambios altera el sistema que pruebas y hace que la siguiente comparación no signifique nada.

Corrige el componente identificado a través de su propietario y luego repite el mismo perfil y la misma observación:

openvpn --config client.ovpn --verb 4
sudo tcpdump -ni any 'host 198.51.100.20 and tcp' -c 40

El resultado útil es un fallo mejor localizado, no una historia más segura. Si el reset desaparece tras corregir el proxy, tienes una causa. Si se traslada a otra etapa, has aprendido algo sobre la ruta. En cualquier caso, la evidencia debería sobrevivir a la lectura de una segunda persona. Escribe lo que observaste, no lo que concluiste.