Liberar portas do MTA:SA no firewall e aparecer online

Aprenda a liberar portas do MTA:SA (22003, 22005, 22126) no firewall do servidor para que apareça na lista pública e aceite jogadores.

Você subiu o servidor de MTA:SA, o console mostra que ele iniciou sem erros, o processo está escutando nas portas certas — mas quando você abre o cliente do jogo e procura na lista pública, seu servidor simplesmente não aparece. Em 9 de cada 10 casos, o problema não está no MTA, está no firewall do sistema operacional bloqueando as portas que o master server precisa acessar para registrar o seu servidor.

Este tutorial mostra como liberar as portas corretas no firewall (UFW, firewalld e Windows Firewall) para que o servidor MTA:SA apareça na lista pública e aceite conexões. Tempo estimado: 10 a 15 minutos, contando verificação externa.

A persona aqui é o owner de servidor que já tem o MTA rodando e sabe operar a linha de comando, mas está travado nessa última etapa de exposição pública. Não vamos cobrir instalação do servidor em si — só firewall e o motivo de cada porta.

Pré-requisitos

Antes de mexer no firewall, confirme que o servidor MTA já está rodando e escutando nas portas. Caso contrário, você vai liberar tráfego para um processo que não existe.

Pré-requisitos

Acesso root ou sudo ao servidor (Linux) ou Administrador (Windows). Servidor MTA:SA instalado e rodando, com mtaserver.conf configurado. Conhecer o IP público do servidor para teste externo. Cliente MTA:SA em outra máquina para validação final.

As portas padrão do servidor MTA:SA que precisam estar acessíveis do exterior são:

Porta do jogo 22003/UDP
HTTP de recursos 22005/TCP
ASE (anúncio) 22126/UDP

A porta ASE é calculada como serverport + 123. Se você usa a porta padrão 22003, o ASE fica em 22126. Se mudar para 23000, o ASE vira 23123. Essa relação é fixa e não pode ser desacoplada.

Confirmar que o ASE está ativado no servidor

Liberar a porta ASE no firewall só funciona se o servidor MTA estiver de fato anunciando para o master server. Esse comportamento é controlado por uma flag no arquivo de configuração.

01

Abra o arquivo mtaserver.conf na pasta do servidor (geralmente em mods/deathmatch/mtaserver.conf em Linux, ou na raiz da instalação no Windows):

nano mods/deathmatch/mtaserver.conf

Procure a linha com a tag <ase> e confirme que o valor é 1:

<ase>1</ase>

Se estiver como 0, o servidor não anuncia para o master e não aparecerá publicamente mesmo com firewall aberto. Mude para 1 e salve.

02

Confirme também a porta principal e o servidor HTTP no mesmo arquivo:

<serverport>22003</serverport>
<httpport>22005</httpport>

Se você mudou esses valores, anote — você vai liberar as portas customizadas em vez das padrão.

03

Reinicie o servidor MTA para aplicar qualquer mudança no mtaserver.conf:

sudo systemctl restart mta-server

Se você não usa systemd, pare e inicie o processo manualmente conforme sua configuração.

Liberar portas no UFW (Ubuntu/Debian)

UFW é o firewall padrão em distribuições Ubuntu e Debian. A sintaxe é direta e cada regra é independente.

01

Verifique se o UFW está ativo antes de adicionar regras:

sudo ufw status verbose

Se a saída disser Status: inactive, o firewall não está bloqueando nada e o problema é outro (provavelmente firewall do provedor ou NAT). Se estiver active, prossiga.

02

Adicione regras para as três portas do MTA:

sudo ufw allow 22003/udp comment 'MTA:SA game'
sudo ufw allow 22005/tcp comment 'MTA:SA HTTP'
sudo ufw allow 22126/udp comment 'MTA:SA ASE'

Os comentários são opcionais mas ajudam você a lembrar o motivo de cada regra ao auditar depois com ufw status numbered.

03

Recarregue as regras e confirme:

sudo ufw reload
sudo ufw status numbered

A saída deve listar as três regras adicionadas como ALLOW IN. Se aparecer Anywhere (v6) separadamente, isso é normal — UFW cria entrada IPv4 e IPv6 para cada regra.

Cuidado com a ordem de regras

Se você tem uma regra de deny abrangente no UFW (raro mas acontece em hardening), ela pode estar acima das regras de allow. Use sudo ufw status numbered para inspecionar a ordem e sudo ufw insert NÚMERO allow ... para inserir na posição certa.

Liberar portas no firewalld (Rocky/AlmaLinux/CentOS)

Distribuições baseadas em Red Hat usam firewalld por padrão. O modelo é orientado a zonas — você adiciona portas a uma zona, não cria regras soltas.

01

Confirme que o firewalld está rodando:

sudo systemctl status firewalld

Se estiver inativo, o firewall não está bloqueando nada via firewalld (pode ainda haver iptables direto, mas é incomum em instalações limpas).

02

Adicione as portas à zona pública de forma permanente:

sudo firewall-cmd --permanent --zone=public --add-port=22003/udp
sudo firewall-cmd --permanent --zone=public --add-port=22005/tcp
sudo firewall-cmd --permanent --zone=public --add-port=22126/udp

A flag --permanent grava as regras em disco. Sem ela, as regras desaparecem no próximo reboot do servidor.

03

Recarregue para aplicar e confirme:

sudo firewall-cmd --reload
sudo firewall-cmd --zone=public --list-ports

A saída do --list-ports deve mostrar 22003/udp 22005/tcp 22126/udp. Se não aparecerem, você provavelmente esqueceu o --permanent ou está olhando a zona errada — confirme com firewall-cmd --get-active-zones.

Liberar portas no Windows Firewall

Se o servidor MTA roda no Windows, o firewall padrão é o Windows Defender Firewall. A interface gráfica funciona, mas o PowerShell é mais rápido e versionável.

01

Abra um PowerShell como Administrador (botão direito no ícone do PowerShell, “Executar como administrador”).

02

Crie as três regras de entrada:

New-NetFirewallRule -DisplayName "MTA:SA Game" -Direction Inbound -Protocol UDP -LocalPort 22003 -Action Allow
New-NetFirewallRule -DisplayName "MTA:SA HTTP" -Direction Inbound -Protocol TCP -LocalPort 22005 -Action Allow
New-NetFirewallRule -DisplayName "MTA:SA ASE" -Direction Inbound -Protocol UDP -LocalPort 22126 -Action Allow

Cada comando retorna um objeto descrevendo a regra criada. Sem erro vermelho, está aplicado imediatamente — Windows Firewall não precisa de reload.

03

Confirme listando as regras criadas:

Get-NetFirewallRule -DisplayName "MTA:SA*" | Format-Table DisplayName, Enabled, Direction, Action

Todas devem aparecer com Enabled: True e Action: Allow.

Verificar do exterior se as portas estão acessíveis

Liberar no firewall local não garante acesso externo — pode haver bloqueio em camadas acima (firewall do datacenter, NAT do roteador, ACL na rede). O único teste confiável é de fora do servidor.

01

De outra máquina (não do servidor MTA), instale o nmap:

sudo apt install -y nmap

Em Windows, baixe de nmap.org/download.

02

Teste UDP para a porta do jogo e ASE — substitua SEU_IP pelo IP público do servidor:

sudo nmap -sU -p 22003,22126 SEU_IP

UDP scan precisa de root (sudo) porque usa raw sockets. Resultados esperados: open ou open|filtered. Se vier filtered puro, ainda há bloqueio em algum ponto.

03

Teste TCP para o HTTP de recursos:

nmap -p 22005 SEU_IP

Resultado esperado: open. Se vier closed, o servidor MTA não está escutando nessa porta (verifique o httpport no mtaserver.conf). Se vier filtered, ainda há firewall bloqueando em algum ponto.

Resolução de problemas

Servidor aparece offline na lista mesmo com portas abertas

Aguarde 5 a 10 minutos após liberar as portas — o master server da MTA tem um intervalo de polling. Se passou esse tempo e ainda não aparece, abra o cliente MTA e use “Adicionar servidor manualmente” com SEU_IP:22003. Se conectar manualmente mas não aparecer na lista pública, o problema é especificamente no ASE (porta 22126 ou flag <ase>0</ase>).

nmap retorna “filtered” mas firewall local está liberado

Há firewall ou ACL upstream. Em servidores domésticos, configure encaminhamento de porta no roteador. Em VPS ou dedicado de provedores, verifique se o painel do provedor tem firewall de rede ativo — alguns provedores aplicam firewall em camada de rede separado do firewall do SO.

Servidor aparece mas jogadores não conseguem baixar recursos ao conectar

Esse sintoma é específico: TCP 22005 está bloqueado. Os clientes conectam (UDP 22003 funciona) mas a transferência de scripts e modelos falha. Confirme que liberou a porta TCP separadamente — ela não vem junto com a UDP em nenhum dos firewalls cobertos aqui.

Próximos passos

Com as portas liberadas e o servidor aparecendo publicamente, vale considerar:

  • Configurar regras de rate limit no firewall para mitigar floods de queries falsas no ASE
  • Documentar o IP e portas em um arquivo de runbook para troubleshooting futuro
  • Habilitar logs de conexão do MTA para correlacionar com tráfego no firewall
  • Avaliar proteção DDoS dedicada se o servidor crescer e atrair atenção indesejada

Se você está rodando o MTA:SA em produção e quer evitar dor de cabeça com firewall, NAT e proteção contra ataques volumétricos, os planos de hospedagem de jogos da Hostini já vêm com firewall pré-configurado para MTA:SA e proteção DDoS ativa por padrão.

Perguntas frequentes

Quais portas exatas do MTA:SA preciso liberar no firewall?

Por padrão você precisa de três portas: 22003/UDP (porta principal do jogo), 22005/TCP (servidor HTTP interno para download de recursos) e 22126/UDP (ASE — anúncio do servidor para a lista pública). Se você customizou essas portas no mtaserver.conf, libere os valores correspondentes.

O que é a porta ASE e por que ela é obrigatória para aparecer online?

ASE significa All-Seeing Eye — é o protocolo de consulta que o master server da MTA usa para registrar o seu servidor na lista pública e responder a queries de clientes. Sem a porta ASE acessível (22126/UDP por padrão), o servidor pode estar rodando perfeitamente mas continuará invisível na lista do jogo.

Liberei as portas no UFW mas o servidor ainda não aparece — o que pode estar errado?

Três causas comuns: (1) há um firewall upstream no provedor ou roteador também bloqueando, (2) a opção 'ase' não está ativada no mtaserver.conf, ou (3) o servidor está atrás de NAT sem encaminhamento de porta. Teste com nmap -sU -p 22126 SEU_IP de fora da rede para confirmar.

Preciso liberar porta TCP ou UDP para o MTA:SA?

Ambas. O tráfego principal do jogo (22003) e o ASE (22126) são UDP porque são protocolos de baixa latência. Já o servidor HTTP interno (22005) é TCP porque transfere arquivos de recursos para os clientes ao conectar. Liberar só uma das duas famílias deixa o servidor parcialmente funcional.

Como mudar as portas padrão do MTA:SA se elas estão ocupadas?

Edite o arquivo mtaserver.conf na pasta do servidor e ajuste os parâmetros <serverport>, <httpport> e a calcular ASE como serverport+123. Reinicie o servidor e libere as novas portas no firewall. Lembre que jogadores precisarão informar a porta customizada ao conectar se ela não for a padrão.

É seguro liberar essas portas direto pra internet?

Sim, são portas de aplicação de jogo desenhadas para tráfego público. O risco real está em portas administrativas como SSH (22) ou o painel web do servidor. Mantenha firewall restritivo em portas administrativas e libere apenas as portas estritamente necessárias para o jogo funcionar.

Tópicos:
Próximos passos VPS, dedicado ou painel gerenciado para FiveM, SAMP, MTA, Tibia e mais.Hospede seu servidor de jogos com a Hostini →
Esse tutorial foi útil?
Falar no WhatsApp