O verificador de portas diz aberto? Por que os jogadores de Minecraft ainda não conseguem entrar

Alguém executa uma verificação de porta, vê a palavra aberto e considera o servidor resolvido. O que esse resultado realmente significa é estreito: a partir da localização do verificador, naquele momento, uma conexão TCP para aquele endereço e aquela porta foi aceita. Ele não diz nada sobre o handshake do protocolo Minecraft, a autenticação da conta ou se o servidor admitiu o jogador em um mundo.

São quatro camadas diferentes, e uma falha em qualquer uma delas produz a mesma frase do jogador: não funcionou.

Uma sonda só testa o que consegue ver

Uma conexão TCP se completa quando os dois lados terminam o handshake de três vias, que fica abaixo de tudo o que o jogo sabe. A sonda informa que existia um ouvinte e que ele respondeu a partir da sua localização de rede. Ela não pode dizer que o ouvinte é o jogo, porque qualquer processo pode ocupar uma porta e aceitar conexões.

A localização importa tanto quanto o resultado. Um verificador na internet pública testa um caminho a partir de uma rede. Um verificador que o operador executa de dentro da mesma rede testa um caminho completamente diferente, e um resultado positivo ali não diz quase nada sobre o que um jogador remoto experimenta. Dois verificadores diferentes em dois provedores diferentes podem até discordar por motivos que não têm nada a ver com o seu servidor.

O momento também importa. O resultado de uma sonda descreve o instante em que ela foi executada, e uma conexão doméstica com endereço dinâmico ou uma regra de encaminhamento alterada pode deslocar a resposta real alguns minutos depois. Anote o endereço público, a porta, a família de endereços e a hora junto com o veredito, ou a observação não é reproduzível. Repita a verificação a partir de uma rede genuinamente diferente, e não de um telefone na mesma conexão.

Quatro camadas entre um socket e um jogador

Imagine a sequência que um cliente que se conecta realmente executa. Primeiro ele resolve o endereço, depois abre uma conexão TCP para a porta publicada, depois fala o protocolo do próprio jogo para negociar e autenticar, e por fim o servidor decide se aquela identidade pode entrar no mundo. Cada camada tem sua própria assinatura de falha, e só a primeira é visível para um verificador de portas.

A porta padrão do Java Edition é 25565, mas o operador pode publicar uma porta externa diferente e encaminhá-la para dentro, então o número que o jogador digita não é necessariamente o número que o servidor vê. Um verificador apontado para a porta externa errada informa fechado enquanto o servidor está perfeitamente saudável, e esse é o alarme falso mais comum em toda essa área.

Nomes acrescentam mais um passo acima da porta. Se um jogador digitar um nome de host, a resolução deve retornar o endereço publicado, e em uma máquina dentro da rede ela pode retornar um privado em vez disso. Isso não é uma falha de firewall e nenhuma quantidade de encaminhamento de portas vai mudar isso.

Por que o jogador de dentro toma um caminho diferente

Um jogador na mesma LAN, ou em uma VPN que alcança essa LAN, tenta alcançar o endereço público de dentro. A requisição vai para o endereço externo do roteador e o roteador precisa traduzi-la de volta para dentro, que é o arranjo geralmente chamado de hairpinning ou reflexão de NAT. Tanto a tradução de ida quanto o caminho de volta precisam se alinhar para isso funcionar, e muitos roteadores domésticos não implementam isso de forma alguma.

É por isso que o convidado de fora entra e a pessoa sentada ao lado do servidor não consegue. O caminho externo está genuinamente certo; o desvio interno é o que falha, e falha de um modo que, na tela do jogador, parece um problema do servidor. O próprio log do servidor decide qual dos dois aconteceu, porque uma conexão que nunca foi traduzida nunca chega até ele.

Há duas correções honestas e um mau hábito. As boas opções são deixar os jogadores internos usarem o endereço privado ou um nome de split-DNS que resolva internamente para o endereço privado, ou habilitar a reflexão no roteador se o recurso existir e se comportar bem. O mau hábito é abrir mais portas ou desativar o firewall do host, o que não pode afetar uma tradução que o roteador nunca realizou.

A documentação da Netgate sobre reflexão de NAT descreve com mais detalhes a distinção entre externo e interno e a alternativa split-DNS. Leia-a como uma descrição do mecanismo e não como a promessa de que qualquer provedor de VPN ou roteador específico suporte todas as variantes de loopback.

Colete evidências de cada ponto de vista

Para cada teste, anote quem o executou, de onde, a que horas, contra qual endereço e porta, e o que o servidor registrou. Uma rejeição do jogo com um motivo claro no console do servidor é uma constatação diferente de uma conexão que nunca chegou, e as duas levam em direções opostas.

Se os jogadores remotos permitidos entram e um jogador local não consegue, o caminho local é a pergunta que resta e merece a sua própria investigação: qual endereço o cliente usou, o que o roteador fez com a tradução e se o servidor registrou qualquer tentativa de conexão. Entregue esses três fatos a quem possui a rede em vez de reabrir portas ao acaso.