La lista pública de VPN dice en línea; tu cliente dice que no

Abres el directorio, ordenas por velocidad, eliges un nodo marcado como en línea y el cliente se rinde antes de terminar de conectar. La lista no mentía, exactamente. Informaba del resultado de la sonda de otra persona, desde otra red, en un momento anterior, contra un servicio que un voluntario puede apagar en cualquier momento. Entender esa brecha convierte una búsqueda frustrante en una corta secuencia de comprobaciones que puedes ejecutar sobre cualquier candidato.

Qué midió realmente la lista

Un directorio público guarda campos como la hora de la última comprobación, una cifra observada de tiempo de ida y vuelta, un recuento de sesiones y a veces una lista de protocolos. Cada uno de ellos describe la última observación correcta desde el punto de vista del propio proyecto, no el estado del nodo cuando llega tu paquete.

La frescura importa más que la cifra. Un nodo comprobado hace cuatro minutos y un nodo comprobado hace cuatro horas pueden mostrar el mismo marcador verde, y solo uno de ellos se parece todavía al estado registrado. Busca la marca de tiempo, no el color.

La operación voluntaria añade una segunda fuente de cambio que ningún monitor puede arreglar. Puede que el operador esté reiniciando un portátil, quedándose sin ancho de banda, cambiando de proveedor o simplemente cerrando la tapa. Una entrada de la lista es un candidato, y tratarla como un acuerdo de nivel de servicio es un error de categoría.

Vigila las etapas del cliente, no el indicador giratorio

Todo cliente VPN pasa por la misma secuencia amplia: resolver el nombre, abrir una conexión de transporte, negociar la seguridad, autenticarse y después configurar el túnel y pasar datos. Un fallo en cada etapa deja pruebas distintas, y el indicador giratorio no muestra ninguna de ellas.

Empieza por la resolución de nombres. Si el nombre de host no se resuelve, no se ha probado nada sobre la disponibilidad del nodo, porque la conexión nunca salió de tu máquina. Después, el transporte: un intercambio TCP o UDP rechazado o agotado por tiempo te dice que el punto final no responde en ese puerto, que es un hallazgo real sobre el nodo. Luego la negociación y la autenticación, donde fallan un certificado equivocado, un perfil caducado o un cifrado que no encaja mientras el nodo está perfectamente sano. Solo después de configurar el túnel puede un fallo de enrutamiento o DNS explicar el último paso.

Lee el registro del cliente con la máxima verbosidad que aún quepa en pantalla y anota la última línea que tuvo éxito. Esa línea es donde empieza el diagnóstico, y suele ser más informativa que cualquier cosa que muestre el directorio.

Una variable por intento

Compara candidatos con el mismo cliente, la misma red de acceso y el mismo formato de perfil, cambiando solo el punto final. De lo contrario, un fallo podría ser tuyo y se lo atribuirías al nodo.

Dos intentos bastan para establecer un patrón, y un tercero lo confirma. Si el nodo A falla en la etapa de transporte y el nodo B falla en la autenticación, tienes dos problemas no relacionados en lugar de una lista desactualizada.

Cuando todos los nodos fallan de la misma manera

Un fallo universal en la primera etapa apunta a tu lado: un resolutor que no puede responder, un cortafuegos local que bloquea el protocolo o una red que solo permite tráfico web. El directorio no puede informar de eso, porque sus sondas no se ejecutan desde tu asiento.

Comprueba deliberadamente el caso de la red modelada. Algunas redes de acceso permiten HTTPS hacia la web y descartan otros protocolos, lo que hace que cada candidato parezca muerto mientras la lista es exacta. Comparar la carga de una página en el navegador con un intento de conexión en bruto separa esas dos situaciones en menos de un minuto.

Lee el fallo en la etapa en que ocurrió

Reproduce el intento desde un terminal para que las etapas sean visibles. Los tres comandos de abajo resuelven el nombre, prueban si el puerto responde e imprimen las líneas de negociación de un perfil de OpenVPN:

dig +short node.example.net
curl -s --max-time 5 telnet://node.example.net:443
openvpn --config node.ovpn --verb 4 2>&1 | grep -iE "TLS|AUTH|PUSH"

Si el puerto responde y la línea de negociación informa de un problema de certificado, el nodo está activo y tu perfil está obsoleto. Si el puerto no responde en absoluto, la entrada es un candidato que ha fallado, y pasar al siguiente es la respuesta correcta en lugar de depurar tu cliente. Anota la etapa en una línea corta, y el próximo intento empieza con conocimiento en lugar de esperanza.