Cómo configurar un proxy TCP para ocultar la IP real del servidor de MU

Ocultar la IP real del servidor de juego es una de las primeras defensas serias que un administrador de MU Online necesita implementar. En cuanto empieza la difusión, la dirección pública circula en foros, capturas y clientes, y junto a ella vienen los ataques de denegación de servicio. Si esa dirección apunta directamente a la máquina que corre el GameServer y la base de datos, un único ataque bien dirigido deja a todos los jugadores fuera del aire y además amenaza la integridad de los datos. La solución clásica es intercalar un proxy TCP entre internet y la máquina de juego: los jugadores conectan al proxy, el proxy reenvía el tráfico al servidor real por un camino privado, y la IP verdadera nunca aparece ante el público.

En este tutorial vas a montar esa capa desde cero, entender por qué funciona, configurar el reenvío de los puertos del ConnectServer y de los GameServers, blindar la máquina de juego con firewall y evitar las filtraciones de IP más comunes. Los valores de puertos, IP y nombres de archivos aquí son ejemplos y varían por proveedor/versión de tu emulador, pero los conceptos son reales y se aplican a cualquier Season.

Qué es un proxy TCP y por qué oculta la IP

Un proxy TCP es un servidor intermediario que acepta conexiones en un puerto, abre una segunda conexión hasta el destino real y copia los bytes de un lado al otro. Para el cliente de MU, el proxy es el servidor: todo el handshake, el login y el tráfico de juego pasan por él. La máquina que realmente procesa el mundo del juego solo recibe conexiones provenientes del proxy, por una dirección que el público desconoce.

El efecto práctico es que la IP anunciada (la que va en el client, en el sitio y en la ServerList) es la IP del proxy, una máquina desechable y barata. La IP de origen (la máquina de juego con base de datos, cuentas e ítems) queda escondida detrás del firewall. Si el proxy cae bajo ataque, cambias la máquina de proxy sin perder nada; el servidor de juego sigue intacto. Es la diferencia entre perder una pieza sacrificable y perder la corona.

Existen tres enfoques comunes para esa capa, resumidos abajo.

Este tutorial se enfoca en el primer enfoque por ser el más didáctico y reproducible, con observaciones sobre los otros.

Requisitos previos

Antes de empezar, ten a la mano:

• Una VPS separada para el proxy, en la misma región del servidor de juego, con IP pública dedicada. No necesita ser potente: CPU modesta y buena red bastan. Ejemplo común: 1 vCPU, 1-2 GB de RAM, red de 1 Gbps (varía por proveedor).
• El servidor de juego ya funcional, con ConnectServer, JoinServer y al menos un GameServer corriendo y probados en red local o por la IP directa. Si todavía estás montando esto, mira la guía de cómo crear un servidor de MU Online antes de continuar.
• Acceso administrativo a las dos máquinas (RDP/SSH según el SO).
• La lista de puertos TCP que usa tu emulador. Ejemplos frecuentes: ConnectServer en 44405, GameServer en 55901/55902, JoinServer en puerto interno. Confírmalos en los archivos de configuración de tu emulador, pues varían por versión.
• Conocimiento básico de firewall (Windows Firewall o iptables/nftables) y de edición de los archivos de configuración de MU (ServerList, GameServerInfo).

Deja anotada la IP privada que unirá el proxy y la máquina de juego. Lo ideal es una red privada entre las dos VPS (muchos proveedores ofrecen VLAN interna). Si no hay red privada, usa la IP pública de la máquina de juego, pero restríngela por firewall para aceptar solo la IP del proxy.

Paso 1 — Provisionar y preparar la VPS de proxy

Crea la VPS de proxy y, en cuanto arranque, haz lo básico de higiene:

1. Actualiza el sistema operativo (paquetes de seguridad al día).
2. Crea un usuario administrativo y deshabilita el login directo de root por contraseña, prefiriendo clave.
3. Instala el software de proxy. En Linux, HAProxy es la opción más robusta para TCP; las alternativas son nginx con módulo stream o socat para reenvío simple.
4. Anota la IP pública (será la IP anunciada) y la IP privada de la red interna con la máquina de juego.

Ejemplo de instalación de HAProxy en una distribución basada en Debian:

sudo apt update
sudo apt install -y haproxy
haproxy -v   # confirma la versión instalada

El número exacto de versión y los nombres de paquete varían por distribución, así que trátalo como ejemplo.

Paso 2 — Mapear los puertos de MU en el proxy

Ahora declaras, en el proxy, cada puerto que el público necesita alcanzar y hacia dónde debe reenviarse. Cada servicio de MU se convierte en un bloque de "escucha en el puerto público, envía a la IP privada del servidor de juego".

Un ejemplo de configuración HAProxy (/etc/haproxy/haproxy.cfg) para ConnectServer y dos GameServers:

global
    log /dev/log local0
    maxconn 20000

defaults
    mode tcp
    timeout connect 5s
    timeout client  1m
    timeout server  1m
    log global
    option tcplog

# ConnectServer
frontend cs_front
    bind *:44405
    default_backend cs_back
backend cs_back
    server cs1 10.0.0.20:44405 check

# GameServer 1
frontend gs1_front
    bind *:55901
    default_backend gs1_back
backend gs1_back
    server gs1 10.0.0.20:55901 check

# GameServer 2
frontend gs2_front
    bind *:55902
    default_backend gs2_back
backend gs2_back
    server gs2 10.0.0.20:55902 check

Aquí, 10.0.0.20 es la IP privada de ejemplo de la máquina de juego. Los puertos 44405, 55901 y 55902 son ejemplos; usa los reales de tu emulador. El mode tcp es esencial — MU no habla HTTP, así que el proxy tiene que operar en la capa 4, solo reenviando bytes.

Después de guardar, valida y recarga:

haproxy -c -f /etc/haproxy/haproxy.cfg   # verifica la sintaxis
sudo systemctl restart haproxy

Si usas socat para una prueba rápida de un único puerto, el equivalente es:

socat TCP-LISTEN:44405,fork,reuseaddr TCP:10.0.0.20:44405

socat es excelente para validar el concepto, pero no lo recomiendo en producción por no tener health check, límites de conexión ni reinicio gestionado.

Paso 3 — Blindar la máquina de juego con firewall

Esta etapa es la que realmente protege la IP real. De nada sirve el proxy si la máquina de juego sigue aceptando conexiones de cualquier lugar por la IP pública. El firewall de la máquina de juego debe aceptar los puertos de MU solo provenientes de la IP del proxy.

En Linux con nftables/iptables, el principio es: negar todo en los puertos del juego y liberar la excepción para el proxy.

# Ejemplo iptables — libera puertos de MU solo desde la IP del proxy (10.0.0.10)
iptables -A INPUT -p tcp -s 10.0.0.10 --dport 44405 -j ACCEPT
iptables -A INPUT -p tcp -s 10.0.0.10 --dport 55901 -j ACCEPT
iptables -A INPUT -p tcp -s 10.0.0.10 --dport 55902 -j ACCEPT
iptables -A INPUT -p tcp --dport 44405 -j DROP
iptables -A INPUT -p tcp --dport 55901 -j DROP
iptables -A INPUT -p tcp --dport 55902 -j DROP

En Windows Server (común en emuladores basados en ejecutables de MU), usa el Windows Firewall con Seguridad Avanzada:

1. Crea una regla de entrada para cada puerto de MU.
2. En "Ámbito", restringe la dirección IP remota a la IP del proxy.
3. Bloquea cualquier otra origen para esos puertos.
4. Mantén el RDP restringido a tu IP de administración, nunca abierto al mundo.

La regla de oro: si un jugador logra conectar apuntando el client a la IP real de la máquina de juego, tu blindaje falló. Prueba esto desde fuera.

Paso 4 — Ajustar la ServerList y la IP anunciada

El client de MU conecta primero al ConnectServer, que devuelve una lista de servidores con direcciones. Si esa lista contiene la IP real de la máquina de juego, todo el esfuerzo se va por la borda: el propio servidor entrega el secreto. Por lo tanto, todo lo que se anuncia al cliente debe apuntar a la IP del proxy.

Los puntos que suelen filtrar la IP real:

• El archivo de configuración del ConnectServer (ServerList) que lista los GameServers.
• El main.dll/config del client con la IP del ConnectServer embebida.
• El sitio y el launcher, que a veces tienen la IP hardcodeada.
• Logs o páginas de estado expuestas públicamente.

Ajusta cada referencia a la IP pública del proxy. En el client, la IP configurada debe ser la del proxy; en la ServerList del ConnectServer, la dirección de cada GameServer también debe ser la IP del proxy (con el puerto correspondiente que el proxy escucha). Los nombres de archivo varían por emulador y Season, así que localiza el equivalente en tu versión.

Paso 5 — Probar desde fuera de la red

Probar desde dentro de tu propia red engaña. Haz la prueba como lo haría un jugador, desde una conexión externa:

1. Apunta un client limpio a la IP del proxy y confirma login, selección de personaje y entrada al mundo.
2. Verifica la latencia: algunos milisegundos de más son normales; decenas de más indican un proxy demasiado lejano.
3. Intenta conectar a propósito a la IP real de la máquina de juego — debe fallar. Si conecta, el firewall está flojo.
4. Corre un escáner de puertos simple contra la IP real para confirmar que los puertos de MU aparecen cerrados desde fuera.

Una tabla rápida de verificación de resultado esperado:

Paso 6 — Endurecer el proxy contra abuso

El proxy es ahora la cara pública, así que él mismo necesita cuidado. Buenas prácticas:

• Límite de conexiones por IP: HAProxy permite stick-table para contar y frenar IP que abren demasiadas conexiones, mitigando floods simples de la capa de conexión.
• maxconn ajustado: evita que el proxy agote la memoria bajo pico.
• Timeouts cortos para conexiones ociosas, liberando recursos.
• Logs habilitados para que identifiques patrones de ataque e IP abusivas.
• Fail2ban o equivalente para banear IP con comportamiento anómalo repetido.

Ejemplo de stick-table para limitar conexiones simultáneas por IP en HAProxy:

backend gs1_back
    stick-table type ip size 100k expire 30s store conn_cur
    tcp-request connection track-sc0 src
    tcp-request connection reject if { sc0_conn_cur gt 30 }
    server gs1 10.0.0.20:55901 check

El límite de 30 conexiones por IP es un ejemplo; ajústalo conforme al comportamiento legítimo de tus jugadores, que varía por versión de client.

Paso 7 — Redundancia y cambio rápido de proxy

El valor real de esta arquitectura aparece cuando el proxy es atacado. Como es desechable, prepárate para cambiarlo rápido:

• Mantén la configuración del proxy versionada (un archivo que reaplicas en minutos en una VPS nueva).
• Ten una segunda IP o una segunda VPS de proxy lista para entrar.
• Usa DNS con TTL bajo apuntando al proxy, si el client resuelve por hostname, para redirigir jugadores sin actualizar el client.
• Considera dos proxies simultáneos en ConnectServers distintos para no tener un punto único de fallo.

El cambio ideal es: el proxy A cae bajo ataque, levantas el proxy B con el mismo archivo de config, apuntas el DNS/ConnectServer a B y los jugadores vuelven, todo sin nunca exponer la máquina de juego.

Errores comunes y soluciones

Lista de verificación de lanzamiento

• VPS de proxy provisionada en la misma región de la máquina de juego
• Red privada (o firewall restringido) entre el proxy y el servidor de juego
• HAProxy instalado y config validada con haproxy -c
• Todos los puertos de MU (ConnectServer, JoinServer, cada GameServer) mapeados
• El firewall de la máquina de juego acepta los puertos de MU solo desde la IP del proxy
• ServerList e IP anunciada apuntan al proxy, nunca a la IP real
• Client, sitio y launcher sin la IP real embebida
• Prueba externa: el login por el proxy funciona
• Prueba externa: la conexión directa a la IP real falla
• Escaneo externo confirma que los puertos de MU están cerrados en la IP real
• Stick-table y maxconn configurados contra flood
• Config del proxy versionada para cambio rápido
• Segundo proxy/IP de reserva preparado

Conclusión

Un proxy TCP bien configurado es la frontera entre un servidor que sobrevive a la primera ola de ataques y uno que cierra las puertas el primer fin de semana concurrido. La lógica es simple: expón una máquina sacrificable, oculta la máquina valiosa y cierra el firewall de forma que la IP real jamás aparezca ante el público. Hecho esto, ganas tiempo, resiliencia y la tranquilidad de cambiar el proxy sin tocar el corazón del servidor. Trata los puertos, IP y versiones de esta guía como ejemplos y adáptalos a tu Season, pero mantén los principios: separación de máquinas, blindaje por firewall y cero filtración de IP en la ServerList.

Preguntas frecuentes