A lista pública de VPN di en liña; o teu cliente di que non
Un directorio mostra unha comprobación de hai minutos, non unha promesa para o teu próximo intento. Percorre as etapas da conexión en orde e mira onde falla realmente o nodo.
Abres o directorio, ordenas por velocidade, elixes un nodo marcado como en liña e o cliente réndese antes de rematar de conectar. A lista non mentía, exactamente. Informaba do resultado da sonda doutra persoa, desde outra rede, nun momento anterior, contra un servizo que un voluntario pode apagar en calquera momento. Entender esa fenda converte unha caza frustrante nunha curta secuencia de comprobacións que podes executar sobre calquera candidato.
Que mediu realmente a lista
Un directorio público garda campos como a hora da última comprobación, unha cifra observada de tempo de ida e volta, un reconto de sesións e ás veces unha lista de protocolos. Cada un deles describe a última observación correcta desde o punto de vista do propio proxecto, non o estado do nodo cando chega o teu paquete.
A frescura importa máis que a cifra. Un nodo comprobado hai catro minutos e un nodo comprobado hai catro horas poden mostrar o mesmo marcador verde, e só un deles aínda se parece ao estado rexistrado. Busca a marca de tempo, non a cor.
A operación voluntaria engade unha segunda fonte de cambio que ningún monitor pode arranxar. Pode que o operador estea reiniciando un portátil, quedando sen ancho de banda, cambiando de provedor ou simplemente pechando a tapa. Unha entrada da lista é un candidato, e tratala como un acordo de nivel de servizo é un erro de categoría.
Vixía as etapas do cliente, non o indicador xiratorio
Todo cliente VPN pasa pola mesma secuencia ampla: resolver o nome, abrir unha conexión de transporte, negociar a seguridade, autenticarse e despois configurar o túnel e pasar datos. Un fallo en cada etapa deixa probas distintas, e o indicador xiratorio non mostra ningunha delas.
Comeza pola resolución de nomes. Se o nome de host non se resolve, non se probou nada sobre a dispoñibilidade do nodo, porque a conexión nunca saíu da túa máquina. Despois, o transporte: un intercambio TCP ou UDP rexeitado ou esgotado polo tempo diche que o punto final non responde nese porto, o que é un achado real sobre o nodo. Logo a negociación e a autenticación, onde fallan un certificado equivocado, un perfil caducado ou un cifrado que non encaixa mentres o nodo está perfectamente san. Só despois de configurar o túnel pode un fallo de encamiñamento ou DNS explicar o último paso.
Le o rexistro do cliente coa máxima verbosidade que aínda caiba na pantalla e anota a última liña que tivo éxito. Esa liña é onde comeza o diagnóstico, e adoita ser máis informativa que calquera cousa que mostre o directorio.
Unha variable por intento
Compara candidatos co mesmo cliente, a mesma rede de acceso e o mesmo formato de perfil, cambiando só o punto final. Doutro xeito, un fallo podería ser teu e atribuiríasllo ao nodo.
Dous intentos abondan para establecer un patrón, e un terceiro confírmao. Se o nodo A falla na etapa de transporte e o nodo B falla na autenticación, tes dous problemas non relacionados en lugar dunha lista desactualizada.
Cando todos os nodos fallan do mesmo xeito
Un fallo universal na primeira etapa apunta ao teu lado: un resolutor que non pode responder, un devasado local que bloquea o protocolo ou unha rede que só permite tráfico web. O directorio non pode informar diso, porque as súas sondas non se executan desde o teu asento.
Comproba deliberadamente o caso da rede modelada. Algunhas redes de acceso permiten HTTPS cara á web e descartan outros protocolos, o que fai que cada candidato pareza morto mentres a lista é exacta. Comparar a carga dunha páxina no navegador cun intento de conexión en bruto separa esas dúas situacións en menos dun minuto.
Le o fallo na etapa en que ocorreu
Reproduce o intento desde un terminal para que as etapas sexan visibles. Os tres comandos de abaixo resolven o nome, proban se o porto responde e imprimen as liñas de negociación dun 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"Se o porto responde e a liña de negociación informa dun problema de certificado, o nodo está activo e o teu perfil está obsoleto. Se o porto non responde en absoluto, a entrada é un candidato que fallou, e pasar ao seguinte é a resposta correcta en lugar de depurar o teu cliente. Anota a etapa nunha liña curta, e o próximo intento comeza con coñecemento en lugar de esperanza.