Liaison de serveurs IRC : topologies et haute disponibilite

Mon premier reseau IRC multi-serveurs date de 2004. Deux serveurs — un en France, un en Italie — links par une connexion ADSL. Le link tombait trois fois par jour. Les utilisateurs se plaignaient des netsplits constants. J'ai appris plus sur la tolerance aux pannes et la topologie reseau en administrant ces deux serveurs que dans n'importe quel cours d'informatique.

Pourquoi linker des serveurs

Un seul serveur IRC est un point de defaillance unique. S'il tombe, tout le monde est deconnecte. Un reseau de serveurs links offre :

• Redundance : Si un serveur tombe, les utilisateurs des autres serveurs continuent a chatter. Seuls les utilisateurs du serveur tombe sont deconnectes.
• Distribution geographique : Les utilisateurs se connectent au serveur le plus proche. Moins de latence, meilleure experience.
• Capacite : Chaque serveur gere un sous-ensemble des connexions. Un serveur seul peut gerer 5 000-10 000 utilisateurs. Avec 5 serveurs, vous montez a 25 000-50 000.
• Isolation des problemes : Un DDoS qui cible un serveur n'affecte pas les autres (sauf si le serveur cible est le hub central).

Spanning tree

Le protocole IRC utilise une topologie en arbre (spanning tree) pour les liens inter-serveurs. Chaque serveur est connecte a un ou plusieurs autres serveurs, mais il ne doit exister qu'un seul chemin entre deux serveurs quelconques. Pas de boucles.

# Topologie en arbre (spanning tree) :
#
#     [Hub Central]
#      /    |    \\
#   [S1]  [S2]  [S3]
#   /\\
# [S4][S5]
#
# Regles :
# 1. Pas de boucle (pas de lien S1 <-> S3 si le hub existe)
# 2. Un seul chemin entre deux serveurs
# 3. Si un lien tombe, l'arbre se coupe en deux
#    = netsplit

# Pourquoi pas un mesh (tous connectes a tous) ?
# Le protocole IRC ne le supporte pas.
# Les messages sont broadcasts sur l'arbre.
# Un mesh creerait des messages en double
# (le meme message arrivant par deux chemins differents).
# Le spanning tree garantit qu'un message ne passe
# qu'une fois par chaque serveur.

Cette architecture en arbre est la force et la faiblesse d'IRC. Force parce qu'elle est simple et efficace pour le broadcast. Faiblesse parce qu'un lien coupe isole une branche complete — c'est le netsplit.

Topologies courantes

# 1. Hub-Leaf (la plus courante) :
#
#     [Hub]
#    / | \\
# [L1][L2][L3]
#
# Avantages : simple, un seul point de configuration
# Inconvenient : le hub est un SPOF

# 2. Dual-Hub (recommandee) :
#
#   [Hub-A] --- [Hub-B]
#   /    \\     /    \\
# [L1]  [L2] [L3]  [L4]
#
# Avantages : pas de SPOF (si un hub tombe,
#   ses leafs se reconnectent a l'autre)
# Inconvenient : plus complexe, les leafs
#   doivent avoir un autoconnect de fallback

# 3. Chaine (petits reseaux) :
#
# [S1] --- [S2] --- [S3] --- [S4]
#
# Avantages : le plus simple a configurer
# Inconvenient : un split au milieu coupe
#   le reseau en deux parties egales

# 4. Etoile avec backup :
#
#      [Hub]
#     / | \\
#   [L1][L2][L3]
#     \\     /
#    [Backup Hub]
#
# Backup Hub inactif normalement.
# Si Hub tombe, les leafs se reconnectent au backup.
# Configuration classique des reseaux de taille moyenne.

Configuration pratique

# === UnrealIRCd : Hub ===

# Sur le hub (unrealircd.conf) :
link leaf1.votredomaine.com {
  incoming {
    mask ip.du.leaf1;
  };
  outgoing {
    hostname ip.du.leaf1;
    port 6900;
    options { tls; autoconnect; };
  };
  password "mot-de-passe-partage-leaf1";
  class servers;
};

link leaf2.votredomaine.com {
  incoming {
    mask ip.du.leaf2;
  };
  outgoing {
    hostname ip.du.leaf2;
    port 6900;
    options { tls; autoconnect; };
  };
  password "mot-de-passe-partage-leaf2";
  class servers;
};

# Port d'ecoute pour les liens serveur :
listen {
  ip *;
  port 6900;
  options { tls; serversonly; };
};

# === UnrealIRCd : Leaf ===

# Sur le leaf (unrealircd.conf) :
link hub.votredomaine.com {
  incoming {
    mask ip.du.hub;
  };
  outgoing {
    hostname ip.du.hub;
    port 6900;
    options { tls; autoconnect; };
  };
  password "mot-de-passe-partage-leaf1";
  class servers;
};

# Autoconnect : le leaf essaie de se reconnecter
# automatiquement si le lien tombe.
# L'intervalle est defini dans la class 'servers' :
class servers {
  pingfreq 90;
  connfreq 30;  # Essayer toutes les 30 secondes
  maxclients 10;
  sendq 20M;
};

# === InspIRCd : Hub ===

Netsplits et resilience

Un netsplit se produit quand un lien entre deux serveurs tombe. Le reseau se divise en deux parties independantes. Les utilisateurs de chaque cote ne voient plus les utilisateurs de l'autre cote.

# Avant le split :
# [Hub] --- [Leaf]
# User1 sur Hub, User2 sur Leaf
# Les deux voient #canal avec User1 et User2

# Pendant le split :
# [Hub]     [Leaf]
# User1 voit : User2 a quitte (*.net *.split)
# User2 voit : User1 a quitte (*.net *.split)
# Les deux continuent de chatter dans #canal
# mais ne voient plus les messages de l'autre

# Apres la reconnexion :
# [Hub] --- [Leaf]
# Les serveurs synchronisent les etats :
# - Merging des listes d'utilisateurs par canal
# - Resolution des conflits de nick (timestamp)
# - Restauration des modes

# Strategies de resilience :

# 1. Autoconnect agressif
class servers {
  connfreq 15;  # Essai toutes les 15 secondes
};

# 2. Leaf multi-hub (fallback)
# Le leaf a deux liens configures :
link hub-primary.votredomaine.com {
  outgoing { options { tls; autoconnect; }; };
};
link hub-backup.votredomaine.com {
  outgoing { options { tls; }; };
  # PAS de autoconnect — utilise seulement si
  # le primaire est indisponible
};

# 3. Monitoring des liens
# Surveiller la latence entre serveurs
# Si la latence augmente, un probleme reseau approche
# Alerter avant que le link ne tombe

Securisation des liens

• TLS obligatoire : Le trafic server-to-server contient tous les messages de tous les utilisateurs, les commandes d'operateurs, les mots de passe. Sans TLS, un intermediaire peut tout lire.
• Mots de passe forts : Le mot de passe du link doit etre long et aleatoire. Si quelqu'un obtient le mot de passe et l'IP autorisee, il peut linker un faux serveur a votre reseau.
• Restriction IP : Chaque lien ne doit accepter des connexions que depuis l'IP du serveur distant. Pas de wildcard.
• Fingerprint TLS : En plus du mot de passe, verifiez le fingerprint du certificat TLS du serveur distant. Double authentification.
• Port dedie : Utilisez un port different pour les liens serveur (ex: 6900) et les connexions clients (6667/6697). Le port serveur ne doit accepter que les IPs connues.

# Verification du fingerprint TLS (UnrealIRCd) :
link leaf1.votredomaine.com {
  incoming {
    mask ip.du.leaf1;
  };
  password "mot-de-passe";
  verify-certificate yes;
  # Le certificat du leaf doit etre signe par une CA
  # de confiance, OU son fingerprint doit etre dans :
  # conf/tls/link-fingerprints.txt
};