Monitorización de servidores y la red mesh

Un servidor puede fallarte en el peor momento posible: un servicio se cae, el proveedor reinicia la máquina — o, peor aún, el servidor queda bloqueado en el país de un usuario y deja de ser accesible aunque técnicamente siga funcionando. Tus usuarios nunca deberían notar nada de esto. Esta lección explica cómo CreateYourVPN vigila tus servidores y qué ocurre cuando uno de ellos tiene problemas.

Dos capas de comprobaciones

El sistema mira cada servidor desde dos ángulos.

1. El servidor se comprueba a sí mismo

Cada pocos minutos, cada servidor informa: ¿está vivo el receptor de tráfico en el puerto 443, y está funcionando el servicio VPN? Las métricas de la lección 3 llegan con el mismo informe. Si el informe dice "no estoy bien", el servidor recibe el estado "Servidor no disponible". Si los informes dejan de llegar por completo, el estado pasa a ser "Sin datos del servidor" — es posible que la máquina esté apagada o haya perdido la red.

2. Los servidores se "llaman" entre sí

Las autocomprobaciones no pueden detectar el caso más traicionero: un servidor cree que está sano, pero desde fuera no se le puede alcanzar — por ejemplo, su IP ha sido bloqueada. Por eso todos tus servidores están unidos en una red mesh de comprobaciones mutuas: cada servidor intenta regularmente alcanzar a cada vecino — de la misma forma en que lo haría la app de un usuario.

A partir de ahí, entra en juego una "votación":

• Un solo intento fallido no significa nada — puede que la red simplemente haya parpadeado. Solo cuentan las rachas sostenidas de fallos.
• Un servidor se marca como "Inaccesible desde tus servidores" solo cuando varios servidores independientes fallan de forma consistente al intentar alcanzarlo — la opinión de un solo servidor no es un veredicto.
• También hay protección contra el "testigo poco fiable": si algún servidor de repente afirma que no puede ver a la mitad de sus vecinos, el problema probablemente sea suyo propio — y sus votos se descartan.

Este es exactamente el esquema que detecta los bloqueos: si un servidor queda bloqueado en un país donde viven otros de tus servidores, los vecinos de ese país pronto dejarán de alcanzarlo, se formará un quórum, y el sistema marcará el servidor como inaccesible. Mientras tanto, los servidores de países sin el bloqueo seguirán viéndolo — y la diferencia de opiniones hace que el panorama sea evidente.

Cuando la comprobación de conexión entre dos servidores no pasa

La votación detecta un bloqueo cuando tienes varios servidores dentro del país que cerró el acceso. Pero lo habitual es tener allí exactamente uno: deja de ver tu servidor extranjero, mientras que los extranjeros se ven entre sí sin problemas. Para esa imagen nunca se formará un quórum.

Aun así lo detectamos, pero decimos con honestidad lo que no sabemos. De «A no ve a B» no se puede deducir qué dirección está bloqueada: es una y la misma afirmación sobre el camino entre ambos, y desde fuera los dos casos se ven igual. Por eso:

• Por defecto no acusamos a nadie. Marcamos como «No disponible» los puntos de entrada del lado al que la comprobación no llega, y de ambos lados si no pasa en las dos direcciones. La causa nombra a los dos servidores (se ve al abrir cualquier punto de entrada en la ficha del servidor). Decidir cuál sustituir te toca a ti: normalmente es aquel al que tus clientes no llegan.
• No se oculta ninguno de los dos. Ocultar el par sacaría de la suscripción también un servidor sano. Los clientes siguen recibiendo los puntos de entrada de ambos servidores, y el balanceo simplemente preferirá los sanos si la ruta tiene alguno.

El servidor verificador

Para obtener una respuesta concreta en lugar de «uno de los dos», marca el servidor en cuya comprobación confías: ficha del servidor → «Usar este servidor para comprobar bloqueos en los demás».

La regla es entonces simple: si el verificador deja de ver un servidor normal, damos por bloqueada la dirección del servidor normal, te escribimos aconsejándote cambiar su IP y dejamos de entregar sus puntos de entrada a los clientes mientras la ruta tenga alternativas. Lo contrario, que un servidor normal no vea al verificador, no significa nada.

Qué le ocurre a un servidor problemático

Los estados alimentan directamente el balanceo: los servidores con los estados "Servidor no disponible" e "Inaccesible desde tus servidores" quedan excluidos de la rotación — no se les envían conexiones nuevas, y en las suscripciones de los usuarios su lugar lo ocupan servidores sanos de las mismas rutas. La excepción es un par roto sin verificador: ahí se marcan los puntos de entrada, pero no se retira ninguno.

Al mismo tiempo, el sistema es cauteloso — está construido sobre el principio de "no hacer daño":

• Una ruta nunca se queda vacía. Si todos los servidores de una ruta resultan estar "mal", el sistema servirá a los usuarios la mejor opción disponible en lugar de una lista vacía — de lo contrario las apps decidirían que los servidores han desaparecido y los borrarían.
• El silencio no es un veredicto. El estado "Sin datos del servidor" no saca por sí solo a un servidor de la rotación: sin datos frescos, el sistema no hace movimientos bruscos.

Todo se cura solo

Ninguno de los estados "se pega" para siempre — el estado se vuelve a derivar a partir de datos frescos:

• el servidor vuelve a enviar un informe saludable → se levanta el estado "Servidor no disponible";
• los vecinos vuelven a alcanzarlo → la racha de fallos se reinicia, y desaparece la marca "Inaccesible desde tus servidores";
• se reanudan los informes → desaparece "Sin datos del servidor".

Arregla el servidor (o espera a que se desbloquee) — y vuelve a ponerse en servicio por sí solo. No hace falta ningún "volver a activar" manual.

Dónde ver esto en el panel

Abre la tarjeta de cualquier usuario → su lista de servidores: junto a cada servidor hay un punto de estado, y cuando algo va mal, un texto con el motivo: "Servidor no disponible", "Inaccesible desde tus servidores" (incluyendo cuántos de tus servidores no pueden verlo), o "Sin datos del servidor". También hay señales indirectas en las tarjetas de servidor: una etiqueta "desactualizado" en las métricas y "Sin datos — el agente no responde".

Puntos clave

• Dos capas de control: un servidor se comprueba a sí mismo, y sus vecinos de la red mesh lo comprueban desde fuera.
• Los bloqueos se detectan mediante una "votación" de varios servidores — sin pánico por incidencias puntuales.
• Los servidores problemáticos salen de la rotación; los usuarios se trasladan silenciosamente a los sanos.
• Todo se autorrepara: en cuanto un servidor vuelve a la vida, se reincorpora automáticamente.
• Si la comprobación de conexión entre un par de servidores no pasa y no hay verificador, marcamos los puntos de entrada del lado inalcanzable (o de ambos, si falla en las dos direcciones) y no ocultamos ninguno: la decisión es tuya.

A continuación

La infraestructura sabe arreglarse sola, pero hay algo que merece protegerse por separado — tu base de usuarios.