Monitoring des serveurs et réseau maillé

Un serveur peut vous laisser tomber au pire moment possible : un service plante, l'hébergeur redémarre la machine — ou, pire encore, le serveur se retrouve bloqué dans le pays d'un utilisateur et devient inaccessible alors qu'il est techniquement en marche. Vos utilisateurs ne devraient jamais rien remarquer de tout cela. Cette leçon explique comment CreateYourVPN surveille vos serveurs et ce qui se passe quand l'un d'eux a un problème.

Deux niveaux de vérification

Le système observe chaque serveur sous deux angles.

1. Le serveur se vérifie lui-même

Toutes les quelques minutes, chaque serveur envoie un rapport : l'écouteur de trafic sur le port 443 est-il vivant, et le service VPN est-il en cours d'exécution ? Les métriques de la leçon 3 arrivent avec le même rapport. Si le rapport dit « je ne vais pas bien », le serveur reçoit le statut « Serveur indisponible ». Si les rapports cessent complètement d'arriver, le statut devient « Aucune donnée du serveur » — la machine est peut-être éteinte ou a perdu son réseau.

2. Les serveurs se « frappent » mutuellement

Les auto-vérifications ne peuvent pas détecter le cas le plus insidieux : un serveur se croit en bonne santé, mais est inaccessible de l'extérieur — par exemple, son IP a été bloquée. C'est pourquoi tous vos serveurs sont réunis dans un réseau maillé de vérifications mutuelles : chaque serveur essaie régulièrement de joindre chacun de ses voisins — de la même façon que le ferait l'application d'un utilisateur.

À partir de là, un « vote » prend le relais :

• Un seul échec de contact ne signifie rien — le réseau a peut-être simplement eu un accroc. Seules les séries de défaillances persistantes comptent.
• Un serveur n'est marqué « Inaccessible depuis vos serveurs » que lorsque plusieurs serveurs indépendants échouent systématiquement à le joindre — l'avis d'un seul serveur ne constitue pas un verdict.
• Il existe aussi une protection contre le « témoin non fiable » : si un serveur affirme soudainement ne pas voir la moitié de ses voisins, le problème vient probablement de lui-même — et ses votes sont écartés.

C'est précisément ce mécanisme qui détecte les blocages : si un serveur se fait bloquer dans un pays où vivent vos autres serveurs, les voisins de ce pays cesseront rapidement de le joindre, un quorum se forme, et le système marque le serveur comme inaccessible. Pendant ce temps, les serveurs dans des pays sans blocage continueront de le voir — et la divergence d'opinions rend le tableau évident.

Quand le test de connexion entre deux serveurs échoue

Le vote détecte un blocage lorsque vous avez plusieurs serveurs dans le pays qui a fermé l'accès. Le plus souvent, vous n'en avez qu'un seul là-bas : il cesse de voir votre serveur étranger, tandis que les serveurs étrangers se voient parfaitement entre eux. Pour une telle image, aucun quorum ne se formera jamais.

Nous le remarquons quand même, mais nous disons honnêtement ce que nous ignorons. De « A ne voit pas B », impossible de déduire quelle adresse est bloquée : c'est une seule et même affirmation sur le chemin entre les deux, et de l'extérieur les deux cas se ressemblent exactement. Donc :

• Par défaut, nous n'accusons personne. Nous marquons « Indisponible » les points d'entrée du côté que le test n'atteint pas, et des deux côtés s'il échoue dans les deux sens. La raison nomme les deux serveurs (visible en ouvrant un point d'entrée dans la fiche du serveur). C'est à vous de décider lequel remplacer : le plus souvent celui que vos clients n'atteignent pas.
• Aucun des deux n'est masqué. Masquer la paire retirerait de l'abonnement un serveur parfaitement sain en même temps que l'autre. Les clients continuent de recevoir les points d'entrée des deux serveurs, et l'équilibrage préférera simplement les serveurs sains si la route en contient.

Le serveur de contrôle

Pour obtenir une réponse précise plutôt que « l'un des deux », marquez le serveur dont vous jugez la vérification fiable : fiche du serveur → « Utiliser ce serveur pour vérifier les blocages des autres ».

La règle est alors simple : si le serveur de contrôle cesse de voir un serveur ordinaire, nous considérons l'adresse de ce dernier comme bloquée, vous écrivons en conseillant d'en changer l'IP et cessons de fournir ses points d'entrée aux clients tant que la route dispose d'alternatives. L'inverse, un serveur ordinaire qui ne voit pas le serveur de contrôle, ne signifie rien.

Ce qui arrive à un serveur problématique

Les statuts alimentent directement l'équilibrage : les serveurs avec les statuts « Serveur indisponible » et « Inaccessible depuis vos serveurs » sont retirés de la rotation — aucune nouvelle connexion ne leur est envoyée, et dans les abonnements des utilisateurs, leur place est prise par des serveurs sains des mêmes routes. Seule exception : une paire rompue sans serveur de contrôle, où les points d'entrée sont marqués mais aucun n'est retiré.

En même temps, le système est prudent — il est bâti sur le principe « ne pas nuire » :

• Une route n'est jamais laissée vide. Si tous les serveurs d'une route se révèlent « mauvais », le système servira aux utilisateurs la meilleure option disponible plutôt qu'une liste vide — sinon les applications décideraient que les serveurs ont disparu et les effaceraient.
• Le silence n'est pas un verdict. Le statut « Aucune donnée du serveur » ne retire pas à lui seul un serveur de la rotation : sans données fraîches, le système ne fait pas de mouvement brusque.

Tout se répare tout seul

Aucun des statuts ne « colle » pour toujours — l'état est redérivé à partir de données fraîches :

• le serveur renvoie à nouveau un rapport sain → « Serveur indisponible » est levé ;
• les voisins recommencent à le joindre → la série de défaillances se réinitialise, et la marque « Inaccessible depuis vos serveurs » disparaît ;
• les rapports reprennent → « Aucune donnée du serveur » disparaît.

Réparez le serveur (ou attendez qu'il soit débloqué) — et il se remet en service tout seul. Pas de « rallumage » manuel.

Où voir cela dans le panneau

Ouvrez la fiche de n'importe quel utilisateur → sa liste de serveurs : à côté de chaque serveur se trouve un point de statut, et quand quelque chose ne va pas — une légende avec la raison : « Serveur indisponible », « Inaccessible depuis vos serveurs » (avec le nombre de vos serveurs qui ne le voient pas), ou « Aucune donnée du serveur ». Des signes indirects apparaissent aussi sur les cartes serveur : un badge « obsolète » sur les métriques et « Aucune donnée — l'agent ne répond pas ».

Points clés à retenir

• Deux niveaux de contrôle : un serveur se vérifie lui-même, et ses voisins du réseau maillé le vérifient de l'extérieur.
• Les blocages sont détectés par un « vote » de plusieurs serveurs — pas de panique pour un incident isolé.
• Les serveurs problématiques sortent de la rotation ; les utilisateurs basculent silencieusement vers des serveurs sains.
• Tout se répare tout seul : dès qu'un serveur revient à la vie, il réintègre automatiquement le service.
• Si le test de connexion entre une paire de serveurs échoue et qu'aucun serveur de contrôle n'est désigné, nous marquons les points d'entrée du côté injoignable (ou des deux, si le test échoue dans les deux sens) et n'en masquons aucun : la décision vous revient.

Prochaine étape

L'infrastructure sait se réparer elle-même, mais il y a une chose qui mérite d'être protégée séparément — votre base d'utilisateurs.