Enlace de servidores IRC y topologia de red

Mi primera red IRC multi-servidor la monte en 2003. Dos servidores, uno en Francia y otro en Alemania, conectados por un link que se caia cada vez que la latencia superaba los 300 milisegundos. Que era a menudo. Pase tres meses estabilizando ese link antes de entender que el problema no era la configuracion — era la topologia. Dos servidores sin redundancia es un punto unico de fallo disfrazado de red distribuida.

Por que enlazar servidores

Un solo servidor IRC funciona bien para redes pequenas. Cuando necesitas mas capacidad, mas redundancia geografica, o simplemente mas puntos de entrada para tus usuarios, necesitas multiples servidores enlazados. Los usuarios se conectan al servidor mas cercano geograficamente, pero ven a todos los usuarios de la red como si estuvieran en el mismo servidor.

Las razones practicas son tres. Rendimiento: un IRCd bien configurado maneja miles de usuarios, pero distribuir la carga reduce la latencia para cada grupo. Redundancia: si un servidor cae, los demas siguen funcionando (con un netsplit temporal). Proximidad: un usuario en Japon con 200ms de latencia a un servidor en Europa tendra mejor experiencia si hay un servidor en Asia.

La razon menos obvia es politica. En redes grandes, diferentes servidores suelen ser administrados por diferentes personas u organizaciones. Cada patrocinador aporta un servidor y conectividad. La red es una federacion, no una organizacion centralizada. Esto es historicamente como funcionaron las grandes redes IRC: EFnet, Undernet, DALnet — todas eran federaciones de administradores independientes.

El modelo spanning tree

IRC usa un modelo de spanning tree para la topologia de red. Esto significa que los servidores forman un arbol sin ciclos. Cada servidor esta conectado a uno o mas servidores, pero no puede haber dos caminos diferentes entre cualquier par de servidores.

# Spanning tree valido:
#
#        hub-1
#       / | \\
#   leaf-1 leaf-2 hub-2
#                  / \\
#             leaf-3  leaf-4

# NO valido (ciclo):
#
#     hub-1 --- hub-2
#      |    \\   |
#   leaf-1  leaf-2
#
# Si hub-1 y hub-2 estan conectados Y leaf-2 esta
# conectado a ambos, hay un ciclo. El protocolo IRC
# no soporta esto.

La restriccion de no-ciclos simplifica enormemente el routing de mensajes. Un mensaje solo puede ir por un camino entre origen y destino. No hay que calcular rutas, no hay loops de routing, no hay paquetes duplicados. Pero el coste es la fragilidad: si se rompe un enlace en el arbol, la red se divide en dos partes que no se ven entre si.

Este tradeoff (simplicidad vs. resiliencia) fue razonable en 1988 cuando las redes eran pequenas. Para redes grandes, es una limitacion severa. Algunos IRCds experimentales han implementado routing mesh, pero ninguno ha conseguido adopcion amplia. El spanning tree sigue siendo el modelo universal.

Topologias en la practica

Dentro del modelo spanning tree, hay diferentes formas de organizar los servidores:

• Estrella (star): Un hub central conectado a todos los demas. Simple, facil de gestionar. Si el hub cae, toda la red se fragmenta en servidores aislados. Solo aceptable para redes de 2-5 servidores.
• Hub-leaf: Multiples hubs conectados entre si, con leafs colgando de cada hub. Los leafs no se conectan entre si. Los hubs forman el backbone. Si un hub cae, solo se pierden sus leafs. Esta es la topologia estandar para redes medianas y grandes.
• Dual-hub: Variante de hub-leaf donde cada leaf tiene links definidos hacia dos hubs, pero solo uno activo a la vez. Si el hub primario cae, el leaf reconecta automaticamente al secundario. Mejor tolerancia a fallos sin violar el spanning tree.

# Topologia hub-leaf con redundancia:
#
#      hub-EU -------- hub-US
#      / |               | \\
# leaf-FR leaf-DE    leaf-NY leaf-LA
#
# Cada leaf tiene autoconnect a su hub primario
# y un link de backup al otro hub.
# Si hub-EU cae:
#   leaf-FR y leaf-DE reconectan a hub-US
#   La red sigue unida, con mas latencia para los europeos

# Topologia dual-hub con 3 hubs:
#
#   hub-1 --- hub-2 --- hub-3
#    |         |         |
#  leafs     leafs     leafs
#
# Si hub-2 cae, la red se divide en dos.
# Solucion: hub-1 y hub-3 tienen un link directo
# pero solo se activa si hub-2 desaparece.
# Esto es "quasi-mesh" — links de backup que mantienen
# la propiedad de spanning tree.

Configuracion de links

# === UnrealIRCd (unrealircd.conf) ===

# En hub-eu:
link leaf-fr.tudominio.com {
  incoming {
    mask *;           /* Aceptar conexion desde cualquier IP */
  };
  outgoing {
    hostname leaf-fr.tudominio.com;
    port 7000;
    options { tls; autoconnect; };
  };
  password "password-compartido-fuerte";
  hub *;              /* Este servidor es hub */
  class servers;
};

link leaf-de.tudominio.com {
  incoming { mask *; };
  outgoing {
    hostname leaf-de.tudominio.com;
    port 7000;
    options { tls; autoconnect; };
  };
  password "otro-password-fuerte";
  hub *;
  class servers;
};

link hub-us.tudominio.com {
  incoming { mask *; };
  outgoing {
    hostname hub-us.tudominio.com;
    port 7000;
    options { tls; autoconnect; };
  };
  password "password-hub-to-hub";
  hub *;
  class servers;
};

# === InspIRCd (inspircd.conf) ===

Los campos criticos: el password debe ser identico en ambos lados (sendpass de A = recvpass de B y viceversa). El nombre del servidor debe coincidir exactamente con lo que el servidor remoto anuncia como su nombre. El puerto debe ser el que el servidor remoto escucha para links de servidor (no el de clientes).

Autoconnect y failover

Autoconnect es la funcionalidad que hace que los links se restauren automaticamente despues de una caida. Sin autoconnect, cada vez que un enlace se rompe, un operador humano tiene que intervenir para reconectarlo.

# UnrealIRCd: autoconnect en el bloque link
link leaf-fr.tudominio.com {
  outgoing {
    options { tls; autoconnect; };
  };
  /* UnrealIRCd intenta reconectar periodicamente */
  /* El intervalo se configura en el class: */
  class servers;
};

class servers {
  pingfreq 90;          /* Ping cada 90 segundos */
  connfreq 60;          /* Intentar reconectar cada 60 segundos */
  maxclients 10;        /* Max servidores en esta clase */
  sendq 20M;            /* Send queue maxima */
};

# InspIRCd: autoconnect es un tag separado


# Failover: link de backup que solo se activa si el primario falla
# InspIRCd soporta autoconnect con failover nativo:

# Intenta primero hub-eu. Si falla, intenta hub-us.
# 120 segundos entre intentos.

El failover de InspIRCd con multiples servidores en el autoconnect es la forma mas simple de implementar redundancia de links. Si el hub primario no responde, el leaf intenta con el secundario. Cuando el primario vuelve, puedes forzar la reconexion manualmente o dejar que el siguiente ciclo de autoconnect lo detecte.

Seguridad de los links

El trafico server-to-server incluye todo: mensajes de usuarios, contrasenas hasheadas, comandos de oper, operaciones de servicios. Si un link no esta cifrado, cualquiera con acceso al trafico de red puede interceptar todo.

• TLS obligatorio: Todo link server-to-server debe usar TLS. Sin excepciones. Si un servidor no soporta TLS, no deberia estar en tu red.
• Certificados verificados: No uses certificados autofirmados para links. Usa Let's Encrypt o una CA interna. Configura la verificacion de certificado en ambos lados.
• Passwords fuertes: Usa passwords de al menos 32 caracteres aleatorios. Cambia los passwords periodicamente.
• IP restrictions: En el bloque link, restringe la mascara de IP al rango exacto del servidor remoto. No uses * como mascara.
• Fingerprint TLS: Ademas del password, verifica el fingerprint del certificado TLS del servidor remoto. Esto protege contra MITM incluso si el password es comprometido.

# UnrealIRCd: verificacion de fingerprint
link hub-us.tudominio.com {
  incoming {
    mask 5.6.7.8;  /* Solo esta IP */
  };
  tls-options {
    certificate "cert.pem";
    key "key.pem";
    options { verify-certificate; };
    /* Fingerprint del certificado del servidor remoto: */
    fingerprint "SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";
  };
};

# InspIRCd: fingerprint en el tag link


# Obtener el fingerprint de un certificado:
openssl x509 -in cert.pem -noout -fingerprint -sha256

Problemas comunes

• Netsplit continuo (flapping): Un link que se cae y reconecta repetidamente. Cada ciclo genera un netsplit y un netjoin, fragmentando canales y confundiendo a usuarios. Causa habitual: latencia inestable, MTU incorrecto, o un firewall que mata conexiones idle. Solucion: aumentar el ping timeout, verificar la ruta de red con mtr/traceroute, y ajustar el TCP keepalive.
• Colision de SID: Cada servidor tiene un Server ID (SID) unico de 3 caracteres. Si dos servidores tienen el mismo SID, el link falla. Solucion: verificar que cada SID es unico antes de enlazar.
• Desfase horario: Algunos IRCds (especialmente con TS6 protocol) son sensibles a diferencias de reloj entre servidores. Si los relojes estan desincronizados, los timestamps de mensajes y modos pueden generar conflictos. Solucion: NTP en todos los servidores.
• Send queue overflow: Si un link es lento y hay mucho trafico, la cola de envio se llena y el servidor desconecta el link. Solucion: aumentar el sendq o mejorar la conectividad.
• DNS incorrecto: El nombre del servidor en la configuracion debe resolver a la IP correcta. Si el DNS falla o resuelve a otra IP, el link no se establece. Solucion: usar IPs directas en los links ademas de nombres, o asegurar que el DNS es fiable.

# Diagnosticar un link problematico:

# Ver estado de los links (como oper):
/MAP
/LINKS
/STATS c   # Ver configuracion de links
/STATS l   # Ver trafico de links (bytes enviados/recibidos)

# Forzar reconexion de un link:
/CONNECT leaf-fr.tudominio.com

# Desconectar un servidor problematico:
/SQUIT leaf-fr.tudominio.com :Mantenimiento

# Verificar latencia entre servidores:
# (Desde el servidor, no desde un cliente)
ping -c 10 ip.del.otro.servidor
mtr ip.del.otro.servidor