El comprovador de ports diu obert? Per què els jugadors de Minecraft encara no poden entrar

Algú executa una comprovació de port, veu la paraula obert i dona el servidor per resolt. El que aquest resultat significa realment és estret: des de la ubicació del comprovador, en aquell moment, s’ha acceptat una connexió TCP a aquella adreça i aquell port. No diu res sobre l’encaixada de mans del protocol de Minecraft, l’autenticació del compte ni si el servidor va admetre el jugador en un món.

Són quatre capes diferents, i un error en qualsevol d’elles produeix la mateixa frase del jugador: no ha funcionat.

Una sonda només prova el que pot veure

Una connexió TCP es completa quan els dos costats acaben l’encaixada de mans de tres vies, que queda per sota de tot el que el joc sap. La sonda informa que hi havia un receptor i que va respondre des de la seva ubicació de xarxa. No us pot dir que el receptor sigui el joc, perquè qualsevol procés pot ocupar un port i acceptar connexions.

La ubicació importa tant com el resultat. Un comprovador a internet públic prova un camí des d’una xarxa. Un comprovador que l’operador executa des de dins de la mateixa xarxa prova un camí completament diferent, i un resultat positiu allà gairebé no diu res sobre el que experimenta un jugador remot. Dos comprovadors diferents en dos proveïdors diferents fins i tot poden discrepar per motius que no tenen res a veure amb el vostre servidor.

El moment també importa. El resultat d’una sonda descriu el moment en què es va executar, i una connexió domèstica amb adreça dinàmica o una regla de reenviament canviada poden moure la resposta real uns minuts més tard. Anoteu l’adreça pública, el port, la família d’adreces i l’hora juntament amb el veredicte, o l’observació no és reproduïble. Repetiu la comprovació des d’una xarxa genuïnament diferent i no des d’un telèfon a la mateixa connexió.

Quatre capes entre un sòcol i un jugador

Imagina la seqüència que un client que s’uneix realment executa. Primer resol l’adreça, després obre una connexió TCP al port publicat, després parla el protocol propi del joc per negociar i autenticar, i finalment el servidor decideix si aquella identitat pot entrar al món. Cada capa té la seva pròpia signatura d’error, i només la primera és visible per a un comprovador de ports.

El port per defecte de Java Edition és 25565, però l’operador pot publicar un port extern diferent i reenviar-lo cap a dins, així que el número que escriu un jugador no és necessàriament el número que veu el servidor. Un comprovador adreçat al port extern equivocat informa tancat mentre el servidor és perfectament sa, i aquesta és la falsa alarma més habitual en tot aquest àmbit.

Els noms afegeixen un pas més per sobre del port. Si un jugador escriu un nom d’amfitrió, la resolució ha de retornar l’adreça publicada, i en una màquina dins de la xarxa pot retornar-ne una de privada en lloc seu. Això no és un error del tallafoc i cap quantitat de reenviament de ports ho canviarà.

Per què el jugador de dins pren un camí diferent

Un jugador a la mateixa LAN, o en una VPN que arriba a aquesta LAN, intenta arribar a l’adreça pública des de dins. La petició va a l’adreça externa del router i el router l’ha de traduir de tornada cap a dins, que és la disposició que normalment s’anomena hairpinning o reflexió de NAT. Tant la traducció d’anada com el camí de tornada han d’encaixar perquè funcioni, i molts routers de consum no ho implementen gens.

És per això que l’hoste de fora s’uneix i la persona asseguda al costat del servidor no pot. El camí extern està genuïnament bé; el desviament intern és el que falla, i falla d’una manera que des de la pantalla del jugador sembla un problema del servidor. El registre del propi servidor resol quin dels dos ha passat, perquè una connexió que mai no s’ha traduït mai no hi arriba.

Hi ha dues solucions honestes i un mal costum. Les bones opcions són deixar que els jugadors interns utilitzin l’adreça privada o un nom de split-DNS que resolgui internament a l’adreça privada, o habilitar la reflexió al router si la funció existeix i es comporta bé. El mal costum és obrir més ports o desactivar el tallafoc de l’amfitrió, cosa que no pot afectar una traducció que el router mai no ha fet.

La documentació de Netgate sobre la reflexió de NAT descriu amb més detall la distinció entre extern i intern i l’alternativa split-DNS. Llegeix-la com una descripció del mecanisme i no com una promesa que qualsevol proveïdor de VPN o router concret admeti totes les variants de loopback.

Recull proves des de cada punt de vista

Per a cada prova, anota qui l’ha executada, des d’on, a quina hora, contra quina adreça i port, i què ha registrat el servidor. Un rebuig del joc amb un motiu clar a la consola del servidor és una troballa diferent d’una connexió que mai no va arribar, i les dues porten en direccions oposades.

Si els jugadors remots permesos s’uneixen i un jugador local no pot, el camí local és la pregunta que queda i mereix la seva pròpia investigació: quina adreça ha utilitzat el client, què ha fet el router amb la traducció i si el servidor ha registrat cap intent de connexió. Passa aquests tres fets a qui posseeixi la xarxa en lloc de reobrir ports a l’atzar.