O comprobador de portos di aberto? Por que os xogadores de Minecraft aínda non poden entrar

Alguén executa unha comprobación de porto, ve a palabra aberto e dá o servidor por resolto. O que ese resultado significa en realidade é estreito: desde a localización do comprobador, nese momento, aceptouse unha conexión TCP a ese enderezo e ese porto. Non di nada sobre o apretón de mans do protocolo Minecraft, a autenticación da conta nin se o servidor admitiu o xogador nun mundo.

Son catro capas diferentes, e un fallo en calquera delas produce a mesma frase do xogador: non funcionou.

Unha sonda só proba o que pode ver

Unha conexión TCP complétase cando ambos os dous lados rematan o apretón de mans de tres vías, que está por baixo de todo o que o xogo sabe. A sonda informa de que existía un oínte e respondeu desde a súa localización de rede. Non pode dicirche que o oínte sexa o xogo, porque calquera proceso pode ocupar un porto e aceptar conexións.

A localización importa tanto como o resultado. Un comprobador na internet pública proba unha ruta desde unha rede. Un comprobador que o operador executa desde dentro da mesma rede proba unha ruta completamente distinta, e un resultado positivo alí non di case nada sobre o que experimenta un xogador remoto. Dous comprobadores distintos en dous provedores distintos poden mesmo non coincidir por razóns que non teñen nada que ver co teu servidor.

O momento tamén importa. O resultado dunha sonda describe o instante en que se executou, e unha conexión doméstica con enderezo dinámico ou unha regra de reenvío cambiada pode mover a resposta real uns minutos despois. Anota o enderezo público, o porto, a familia de enderezos e a hora xunto co veredicto, ou a observación non é reproducible. Repite a comprobación desde unha rede genuinamente distinta e non desde un teléfono na mesma conexión.

Catro capas entre un socket e un xogador

Imaxina a secuencia que realiza realmente un cliente que se une. Primeiro resolve o enderezo, despois abre unha conexión TCP ao porto publicado, despois fala o protocolo propio do xogo para negociar e autenticar, e por último o servidor decide se esa identidade pode entrar no mundo. Cada capa ten a súa propia sinatura de fallo, e só a primeira é visible para un comprobador de portos.

O porto predeterminado de Java Edition é 25565, pero o operador pode publicar un porto externo distinto e reenvialo cara a dentro, así que o número que escribe un xogador non é necesariamente o número que ve o servidor. Un comprobador dirixido ao porto externo equivocado informa pechado mentres o servidor está perfectamente san, e esa é a falsa alarma máis común en todo este ámbito.

Os nomes engaden un paso máis por riba do porto. Se un xogador escribe un nome de host, a resolución debe devolver o enderezo publicado, e nunha máquina dentro da rede pode devolver un privado no seu lugar. Iso non é un fallo da devasa e ningunha cantidade de reenvío de portos o cambiará.

Por que o xogador de dentro toma unha ruta distinta

Un xogador na mesma LAN, ou nunha VPN que chega a esa LAN, intenta alcanzar o enderezo público desde dentro. A petición vai ao enderezo externo do router e o router ten que traducila de volta cara a dentro, que é a disposición que adoita chamarse hairpinning ou reflexión de NAT. Tanto a tradución de ida como a ruta de volta teñen que encaixar para que funcione, e moitos routers domésticos non o implementan en absoluto.

Por iso o convidado de fóra únese e a persoa sentada ao lado do servidor non pode. A ruta externa está genuinamente ben; o desvío interno é o que falla, e falla dun xeito que desde a pantalla do xogador parece un problema do servidor. O propio rexistro do servidor resolve cal dos dous ocorreu, porque unha conexión que nunca se traduciu nunca chega a el.

Hai dous arranxos honestos e un mal costume. As boas opcións son deixar que os xogadores internos usen o enderezo privado ou un nome de split-DNS que resolva internamente ao enderezo privado, ou habilitar a reflexión no router se a función existe e se comporta ben. O mal costume é abrir máis portos ou desactivar a devasa do host, o que non pode afectar unha tradución que o router nunca realizou.

A documentación de Netgate sobre a reflexión de NAT describe con máis detalle a distinción entre externo e interno e a alternativa split-DNS. Léea como unha descrición do mecanismo e non como unha promesa de que calquera provedor de VPN ou router concreto admita todas as variantes de loopback.

Recompila probas desde cada punto de vista

Para cada proba, anota quen a executou, desde onde, a que hora, contra que enderezo e porto, e que rexistrou o servidor. Un rexeitamento do xogo cun motivo claro na consola do servidor é un achado distinto dunha conexión que nunca chegou, e os dous levan en direccións opostas.

Se os xogadores remotos permitidos se unen e un xogador local non pode, a ruta local é a pregunta que queda e merece a súa propia investigación: que enderezo usou o cliente, que fixo o router coa tradución e se o servidor rexistrou algún intento de conexión. Entrega eses tres feitos a quen posúa a rede en lugar de reabrir portos ao azar.