Como configurar um proxy TCP para esconder o IP real do servidor de MU

Esconder o IP real do servidor de jogo é uma das primeiras defesas sérias que um administrador de MU Online precisa implementar. Assim que a divulgação começa, o endereço público circula em fóruns, prints e clientes, e junto vêm os ataques de negação de serviço. Se esse endereço apontar diretamente para a máquina que roda o GameServer e o banco, um único ataque bem direcionado tira todos os jogadores do ar e ainda ameaça a integridade dos dados. A solução clássica é intercalar um proxy TCP entre a internet e a máquina de jogo: os jogadores conectam no proxy, o proxy repassa o tráfego para o servidor real por um caminho privado, e o IP verdadeiro nunca aparece para o público.

Neste tutorial você vai montar essa camada do zero, entender por que ela funciona, configurar o encaminhamento das portas do ConnectServer e dos GameServers, blindar a máquina de jogo com firewall e evitar os vazamentos de IP mais comuns. Os valores de portas, IPs e nomes de arquivos aqui são exemplos e variam por provedor/versão do seu emulador, mas os conceitos são reais e se aplicam a qualquer Season.

O que é um proxy TCP e por que ele esconde o IP

Um proxy TCP é um servidor intermediário que aceita conexões em uma porta, abre uma segunda conexão até o destino real e copia os bytes de um lado para o outro. Para o cliente do MU, o proxy é o servidor: todo o handshake, o login e o tráfego de jogo passam por ele. A máquina que realmente processa o mundo do jogo só recebe conexões vindas do proxy, por um endereço que o público desconhece.

O efeito prático é que o IP anunciado (o que vai no client, no site e na ServerList) é o IP do proxy, uma máquina descartável e barata. O IP de origem (a máquina de jogo com banco, contas e itens) fica escondido atrás de firewall. Se o proxy cair sob ataque, você troca a máquina de proxy sem perder nada; o servidor de jogo continua intocado. É a diferença entre perder uma peça sacrificável e perder a coroa.

Existem três abordagens comuns para essa camada, resumidas abaixo.

Este tutorial foca na primeira abordagem por ser a mais didática e reprodutível, com observações sobre as outras.

Pré-requisitos

Antes de começar, tenha em mãos:

• Uma VPS separada para o proxy, na mesma região do servidor de jogo, com IP público dedicado. Não precisa ser potente: CPU modesta e boa rede bastam. Exemplo comum: 1 vCPU, 1-2 GB de RAM, rede de 1 Gbps (varia por provedor).
• O servidor de jogo já funcional, com ConnectServer, JoinServer e ao menos um GameServer rodando e testados em rede local ou pelo IP direto. Se você ainda está montando isso, veja o guia de como criar servidor de MU Online antes de seguir.
• Acesso administrativo às duas máquinas (RDP/SSH conforme o SO).
• A lista de portas TCP que seu emulador usa. Exemplos frequentes: ConnectServer em 44405, GameServer em 55901/55902, JoinServer em porta interna. Confirme nos arquivos de configuração do seu emulador, pois variam por versão.
• Conhecimento básico de firewall (Windows Firewall ou iptables/nftables) e de edição dos arquivos de configuração do MU (ServerList, GameServerInfo).

Deixe anotado o IP privado que ligará proxy e máquina de jogo. O ideal é uma rede privada entre as duas VPS (muitos provedores oferecem VLAN interna). Se não houver rede privada, use o IP público da máquina de jogo, mas restrinja por firewall para aceitar apenas o IP do proxy.

Passo 1 — Provisionar e preparar a VPS de proxy

Crie a VPS de proxy e, assim que ela subir, faça o básico de higiene:

1. Atualize o sistema operacional (pacotes de segurança em dia).
2. Crie um usuário administrativo e desabilite login direto de root por senha, preferindo chave.
3. Instale o software de proxy. Em Linux, o HAProxy é a escolha mais robusta para TCP; alternativas são o nginx com módulo stream ou o socat para encaminhamento simples.
4. Anote o IP público (será o IP anunciado) e o IP privado da rede interna com a máquina de jogo.

Exemplo de instalação do HAProxy em uma distribuição baseada em Debian:

sudo apt update
sudo apt install -y haproxy
haproxy -v   # confirma a versão instalada

O número exato de versão e os nomes de pacote variam por distribuição, então trate isso como exemplo.

Passo 2 — Mapear as portas do MU no proxy

Agora você declara, no proxy, cada porta que o público precisa alcançar e para onde ela deve ser repassada. Cada serviço do MU vira um bloco de "escuta na porta pública, envia para o IP privado do servidor de jogo".

Um exemplo de configuração HAProxy (/etc/haproxy/haproxy.cfg) para ConnectServer e dois 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

Aqui, 10.0.0.20 é o IP privado de exemplo da máquina de jogo. As portas 44405, 55901 e 55902 são exemplos; use as reais do seu emulador. O mode tcp é essencial — o MU não fala HTTP, então o proxy tem que operar na camada 4, apenas repassando bytes.

Depois de salvar, valide e recarregue:

haproxy -c -f /etc/haproxy/haproxy.cfg   # checa a sintaxe
sudo systemctl restart haproxy

Se você usar socat para um teste rápido de uma única porta, o equivalente é:

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

O socat é ótimo para validar o conceito, mas não recomendo em produção por não ter health check, limites de conexão nem reinício gerenciado.

Passo 3 — Blindar a máquina de jogo com firewall

Esta etapa é a que realmente protege o IP real. De nada adianta o proxy se a máquina de jogo continuar aceitando conexões de qualquer lugar pelo IP público. O firewall da máquina de jogo deve aceitar as portas do MU somente vindas do IP do proxy.

Em Linux com nftables/iptables, o princípio é: negar tudo nas portas do jogo e liberar exceção para o proxy.

# Exemplo iptables — libera portas do MU só do IP do 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

Em Windows Server (comum em emuladores baseados em executáveis do MU), use o Windows Firewall com Segurança Avançada:

1. Crie uma regra de entrada para cada porta do MU.
2. Em "Escopo", restrinja o endereço IP remoto ao IP do proxy.
3. Bloqueie qualquer outra origem para essas portas.
4. Mantенha o RDP restrito ao seu IP de administração, nunca aberto ao mundo.

A regra de ouro: se um jogador conseguir conectar apontando o client para o IP real da máquina de jogo, sua blindagem falhou. Teste isso de fora.

Passo 4 — Ajustar a ServerList e o IP anunciado

O client do MU conecta primeiro no ConnectServer, que devolve uma lista de servidores com endereços. Se essa lista contiver o IP real da máquina de jogo, todo o esforço vai por água abaixo: o próprio servidor entrega o segredo. Portanto, tudo que é anunciado ao cliente precisa apontar para o IP do proxy.

Os pontos que costumam vazar o IP real:

• O arquivo de configuração do ConnectServer (ServerList) que lista os GameServers.
• O main.dll/config do client com o IP do ConnectServer embutido.
• O site e o launcher, que às vezes têm o IP hardcoded.
• Logs ou páginas de status expostas publicamente.

Ajuste cada referência para o IP público do proxy. No client, o IP configurado deve ser o do proxy; na ServerList do ConnectServer, o endereço de cada GameServer também deve ser o IP do proxy (com a porta correspondente que o proxy escuta). Os nomes de arquivo variam por emulador e Season, então localize o equivalente na sua versão.

Passo 5 — Testar de fora da rede

Testar de dentro da sua própria rede engana. Faça o teste como um jogador faria, de uma conexão externa:

1. Aponte um client limpo para o IP do proxy e confirme login, seleção de personagem e entrada no mundo.
2. Verifique a latência: alguns milissegundos a mais são normais; dezenas a mais indicam proxy longe demais.
3. Tente conectar propositalmente no IP real da máquina de jogo — deve falhar. Se conectar, o firewall está frouxo.
4. Rode um scanner de portas simples contra o IP real para confirmar que as portas do MU aparecem fechadas de fora.

Uma tabela rápida de verificação de resultado esperado:

Passo 6 — Endurecer o proxy contra abuso

O proxy é agora a face pública, então ele mesmo precisa de cuidado. Boas práticas:

• Limite de conexões por IP: HAProxy permite stick-table para contar e barrar IPs que abrem conexões demais, mitigando floods simples de camada de conexão.
• maxconn ajustado: evita que o proxy esgote memória sob pico.
• Timeouts curtos para conexões ociosas, liberando recursos.
• Logs habilitados para você identificar padrões de ataque e IPs abusivos.
• Fail2ban ou equivalente para banir IPs com comportamento anômalo repetido.

Exemplo de stick-table para limitar conexões simultâneas por IP no 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

O limite de 30 conexões por IP é um exemplo; ajuste conforme o comportamento legítimo dos seus jogadores, que variam por versão de client.

Passo 7 — Redundância e troca rápida de proxy

O valor real dessa arquitetura aparece quando o proxy é atacado. Como ele é descartável, prepare-se para trocá-lo rápido:

• Mantenha a configuração do proxy versionada (um arquivo que você reaplica em minutos numa VPS nova).
• Tenha um segundo IP ou uma segunda VPS de proxy pronta para entrar.
• Use DNS com TTL baixo apontando para o proxy, se o client resolver por hostname, para redirecionar jogadores sem atualizar o client.
• Considere dois proxies simultâneos em ConnectServers distintos para não ter ponto único de falha.

A troca ideal é: proxy A cai sob ataque, você sobe o proxy B com o mesmo arquivo de config, aponta o DNS/ConnectServer para B e os jogadores voltam, tudo sem nunca expor a máquina de jogo.

Erros comuns e soluções

Checklist de lançamento

• VPS de proxy provisionada na mesma região da máquina de jogo
• Rede privada (ou firewall restrito) entre proxy e servidor de jogo
• HAProxy instalado e config validada com haproxy -c
• Todas as portas do MU (ConnectServer, JoinServer, cada GameServer) mapeadas
• Firewall da máquina de jogo aceita portas do MU só do IP do proxy
• ServerList e IP anunciado apontam para o proxy, nunca para o IP real
• Client, site e launcher sem IP real embutido
• Teste externo: login pelo proxy funciona
• Teste externo: conexão direta ao IP real falha
• Scan externo confirma portas do MU fechadas no IP real
• Stick-table e maxconn configurados contra flood
• Config do proxy versionada para troca rápida
• Segundo proxy/IP de reserva preparado

Conclusão

Um proxy TCP bem configurado é a fronteira entre um servidor que sobrevive à primeira onda de ataques e um que fecha as portas no primeiro fim de semana movimentado. A lógica é simples: exponha uma máquina sacrificável, esconda a máquina valiosa e feche o firewall de forma que o IP real jamais apareça ao público. Feito isso, você ganha tempo, resiliência e a tranquilidade de trocar o proxy sem tocar no coração do servidor. Trate as portas, IPs e versões deste guia como exemplos e adapte à sua Season, mas mantenha os princípios: separação de máquinas, blindagem por firewall e zero vazamento de IP na ServerList.

Perguntas frequentes