Cómo Configurar Proxy de Conexión entre ConnectServer y GameServer

Comprendiendo la Arquitectura ConnectServer → GameServer en S6

MU Online Season 6 utiliza una arquitectura de dos etapas para gestionar las conexiones de jugadores. El ConnectServer (CS) es el punto de entrada: escucha en el puerto 44405 y responde al cliente con una lista de GameServers disponibles. Cuando el jugador selecciona un servidor en la pantalla de login, el cliente cierra la conexión con el CS y abre una nueva conexión directamente con el GameServer (GS) en el puerto que fue informado — generalmente 55901 para el primer servidor.

Esta separación existe por diseño: permite que múltiples GameServers coexistan bajo un único punto de entrada, y facilita el mantenimiento porque un GS puede reiniciarse sin afectar a los demás. El inconveniente es que esta separación crea una capa donde configuraciones de red incorrectas generan fallos silenciosos — el cliente conecta al CS, recibe la lista, intenta conectar al GS y simplemente se queda en "Conectando..." sin ningún mensaje de error útil.

La capa de proxy entra en este flujo entre el CS y el GS, o entre el cliente y el CS, dependiendo del objetivo: protección de IP, balanceo de carga o filtrado de paquetes.

Cliente MU
    │
    ▼ puerto 44405
ConnectServer
    │ responde con IP:puerto del GS
    ▼
    [Proxy Intermediario] ← punto de configuración de esta guía
    │
    ▼ puerto 55901
GameServer
    │
    ├── DataServer (puerto 55980)
    └── EventChipServer / SubServers

Configurando el ConnectServer para Enrutar por el Proxy

Antes de configurar cualquier proxy, el ConnectServer debe apuntar a la dirección correcta. Abre el archivo de configuración del CS (típicamente ConnectServer.ini o ServerInfo.xml según tu build de S6) y localiza la sección de lista de servidores:

; Ejemplo de configuración MainServerInfo (formato .ini común en S6)
[ServerInfo01]
ServerCode    = 0
ServerName    = Lorencia
ServerAddress = 192.168.1.100   ; ← IP del GameServer VISIBLE para el cliente
ServerPort    = 55901
ServerType    = 0
MaxUser       = 200
CurrentUser   = 0

Si usas un proxy inverso (ej.: HAProxy o el servicio de proxy integrado en tu build), el campo ServerAddress debe apuntar a la IP del proxy, no directamente al GS. El proxy luego reenvía internamente a 127.0.0.1:55901.

Flujo con proxy:
Cliente → CS (44405) → recibe proxy_ip:55901
Cliente → Proxy (55901) → GameServer (127.0.0.1:55901 interno)

Flujo sin proxy (directo):
Cliente → CS (44405) → recibe gs_ip:55901
Cliente → GameServer (55901) directamente

Reglas de Firewall Indispensables

El firewall es responsable de la mayoría de los fallos de conexión que parecen problemas de configuración del servidor. En Windows Server (el entorno más común para MU S6), las reglas deben permitir explícitamente los siguientes puertos de entrada:

Puertos obligatorios para MU Online S6:
→ TCP 44405   ConnectServer (entrada de clientes)
→ TCP 55901   GameServer principal (GS Code 0)
→ TCP 55902   GameServer secundario (GS Code 1, si existe)
→ TCP 55980   DataServer (comunicación interna GS ↔ DS)
→ TCP 55960   EventChipServer (opcional, eventos especiales)
→ UDP 44405   Algunos builds también usan UDP en el CS

Puertos de base de datos (nunca exponer públicamente):
→ TCP 1433    SQL Server (solo localhost o LAN interna)

Agregar reglas en el Firewall de Windows mediante PowerShell (sin necesidad de interfaz gráfica):

# Permitir ConnectServer
New-NetFirewallRule -DisplayName "MU ConnectServer" `
  -Direction Inbound -Protocol TCP -LocalPort 44405 -Action Allow

# Permitir GameServer
New-NetFirewallRule -DisplayName "MU GameServer" `
  -Direction Inbound -Protocol TCP -LocalPort 55901 -Action Allow

# Permitir DataServer solo para dirección local
New-NetFirewallRule -DisplayName "MU DataServer Interno" `
  -Direction Inbound -Protocol TCP -LocalPort 55980 `
  -RemoteAddress 127.0.0.1 -Action Allow

Configurando el Proxy TCP Inverso

Para entornos donde quieres ocultar la IP del GameServer o agregar una capa de filtrado, un proxy TCP simple resuelve el problema. HAProxy es la herramienta más utilizada en entornos Linux, pero en Windows, Nginx con el módulo stream o incluso socat pueden cumplir la función.

Ejemplo de configuración de HAProxy para proxy transparente del GameServer:

# /etc/haproxy/haproxy.cfg — sección stream para MU Online S6

frontend mu_connectserver
    bind *:44405
    mode tcp
    default_backend cs_backend

backend cs_backend
    mode tcp
    server cs_local 127.0.0.1:44415_interno check

frontend mu_gameserver
    bind *:55901
    mode tcp
    default_backend gs_backend

backend gs_backend
    mode tcp
    server gs_local 127.0.0.1:55911_interno check inter 5s rise 2 fall 3

En esta configuración, HAProxy escucha en los puertos públicos y reenvía el tráfico a los procesos que corren en puertos internos (renombrados para evitar conflictos). El GameServer y el ConnectServer se configuran para escuchar solo en 127.0.0.1 con puertos distintos (ej.: 55911 en vez de 55901), y el proxy gestiona el binding público.

Diagnóstico de Problemas Comunes de Conexión

Cuando las conexiones fallan, el diagnóstico sigue un orden específico:

Paso 1: Verificar que el proceso esté corriendo
→ netstat -an | findstr "44405"   (debe mostrar LISTENING)
→ netstat -an | findstr "55901"   (debe mostrar LISTENING)

Paso 2: Verificar alcanzabilidad externa
→ telnet TU_IP_PUBLICA 44405     (debe conectar sin error)
→ telnet TU_IP_PUBLICA 55901     (debe conectar sin error)

Paso 3: Revisar logs del ConnectServer
→ Archivo ConnectServer.log — buscar "GameServer connected"
→ Si el GS no aparece conectado al CS, el problema está entre ellos

Paso 4: Inspeccionar el ServerList que el CS está enviando
→ Wireshark en el cliente: filtrar por "tcp.port == 44405"
→ El paquete de respuesta del CS debe contener una IP pública válida

Paso 5: Verificar el DataServer
→ Si el GS conecta al CS pero los jugadores se congelan en el login,
  el DS puede estar fallando — revisar puerto 55980 y logs del DS

Gestión de Múltiples GameServers

S6 admite múltiples GameServers, cada uno con sus propios mapas. Cada GS tiene un ServerCode único y puede alojar diferentes conjuntos de mapas. Una distribución típica en un servidor S6 bien configurado se ve así:

GameServer 0 (Lorencia, Noria, Devias, Dungeon 3 pisos)
    → puerto 55901

GameServer 1 (Atlans 3 pisos, Tarkan, Icarus, Lost Tower 7 pisos)
    → puerto 55902

GameServer 2 (Aida, Karutan, Kanturu 3 pisos, Raklion, Vulcanus)
    → puerto 55903

GameServer 3 (Kalima 1-7, Land of Trials, Crywolf Fortress, Acheron)
    → puerto 55904

Cada GameServer requiere su propia entrada en ServerList.dat y su propia regla de firewall. El ConnectServer gestiona todos ellos y muestra al jugador una lista con la ocupación en tiempo real — por eso el CS necesita una conexión estable con cada GS para reportar el CurrentUser correctamente.

Cuando Crywolf Fortress está alojada en un GS dedicado, ten en cuenta que la falla en el evento Crywolf (cuando Balgass no es derrotado) es precisamente lo que activa las caídas de Loch's Feather desde Balgass — un ingrediente necesario junto con el Jewel of Creation para fabricar Wings de Nivel 3. Esto afecta directamente la economía del servidor, por lo que la estabilidad del GS que aloja Crywolf es operacionalmente significativa.

Monitoreo Continuo de la Conexión entre Procesos

Después de completar la configuración, implementa un monitoreo básico para detectar desconexiones entre el CS y los GameServers antes de que los jugadores lo noten:

# Script PowerShell simple para verificar si los procesos están escuchando
# Guardar como check-mu-ports.ps1 y programar en el Programador de tareas

$puertos = @(44405, 55901, 55902, 55980)
$timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"

foreach ($puerto in $puertos) {
    $conn = netstat -an | Select-String ":$puerto\s+.*LISTENING"
    if (-not $conn) {
        # Puerto no escuchando — registrar en el log
        Add-Content -Path "C:\MUServer\logs\monitor.log" `
            -Value "$timestamp - ALERTA: puerto $puerto NO está en LISTENING"
    }
}

Programar este script cada 2 minutos en el Programador de tareas de Windows te da un historial exacto de cuándo cayó cada proceso, lo cual es fundamental para diagnosticar caídas intermitentes que son difíciles de reproducir manualmente.

Perguntas frequentes