Le vérificateur de ports dit ouvert ? Pourquoi les joueurs Minecraft ne peuvent toujours pas se connecter

Quelqu’un lance une vérification de port, voit le mot ouvert et considère le serveur comme résolu. Ce que ce résultat signifie vraiment est étroit : depuis l’emplacement du vérificateur, à cet instant, une connexion TCP vers cette adresse et ce port a été acceptée. Il ne dit rien sur la poignée de main du protocole Minecraft, l’authentification du compte, ni sur le fait que le serveur ait admis le joueur dans un monde.

Ce sont quatre couches différentes, et une défaillance dans l’une d’elles produit la même phrase chez le joueur : ça n’a pas marché.

Une sonde ne teste que ce qu’elle peut voir

Une connexion TCP s’achève lorsque les deux côtés terminent la poignée de main en trois temps, qui se situe sous tout ce que le jeu sait. La sonde rapporte qu’un écouteur existait et a répondu depuis son emplacement réseau. Elle ne peut pas vous dire que l’écouteur est le jeu, car n’importe quel processus peut occuper un port et accepter des connexions.

L’emplacement compte autant que le résultat. Un vérificateur sur l’internet public teste un chemin depuis un réseau. Un vérificateur que l’opérateur lance depuis l’intérieur du même réseau teste un chemin entièrement différent, et un résultat positif là-bas ne dit presque rien de ce que vit un joueur distant. Deux vérificateurs différents chez deux fournisseurs différents peuvent même se contredire pour des raisons qui n’ont rien à voir avec votre serveur.

Le moment compte aussi. Le résultat d’une sonde décrit l’instant où elle a été exécutée, et une connexion domestique à adresse dynamique ou dont la règle de redirection a changé peut déplacer la vraie réponse quelques minutes plus tard. Notez l’adresse publique, le port, la famille d’adresses et l’heure avec le verdict, sinon l’observation n’est pas reproductible. Répétez la vérification depuis un réseau réellement différent plutôt que depuis un téléphone sur la même connexion.

Quatre couches entre un socket et un joueur

Imaginez la séquence qu’un client qui se connecte exécute réellement. D’abord il résout l’adresse, puis il ouvre une connexion TCP vers le port publié, puis il parle le protocole propre au jeu pour négocier et s’authentifier, et enfin le serveur décide si cette identité peut entrer dans le monde. Chaque couche a sa propre signature de défaillance, et seule la première est visible pour un vérificateur de ports.

Le port par défaut de Java Edition est 25565, mais l’opérateur peut publier un autre port externe et le rediriger vers l’intérieur, si bien que le numéro qu’un joueur tape n’est pas forcément celui que le serveur voit. Un vérificateur pointé vers le mauvais port externe signale fermé alors que le serveur est parfaitement sain, et c’est la fausse alerte la plus courante dans tout ce domaine.

Les noms ajoutent une étape de plus au-dessus du port. Si un joueur tape un nom d’hôte, la résolution doit renvoyer l’adresse publiée, et sur une machine à l’intérieur du réseau elle peut renvoyer une adresse privée à la place. Ce n’est pas une défaillance du pare-feu et aucune quantité de redirection de port ne changera cela.

Pourquoi le joueur à l’intérieur prend un autre chemin

Un joueur sur le même LAN, ou sur un VPN qui atteint ce LAN, essaie d’atteindre l’adresse publique depuis l’intérieur. La requête part vers l’adresse externe du routeur et le routeur doit la traduire vers l’intérieur, ce qui est la disposition généralement appelée hairpinning ou réflexion NAT. La traduction aller et le trajet retour doivent tous deux s’aligner pour que cela fonctionne, et beaucoup de routeurs grand public ne l’implémentent pas du tout.

C’est pourquoi l’invité de l’extérieur se connecte et la personne assise à côté du serveur ne le peut pas. Le chemin externe est réellement correct ; le détour interne est ce qui échoue, et il échoue d’une manière qui, depuis l’écran du joueur, ressemble à un problème de serveur. Le journal du serveur tranche lequel des deux s’est produit, car une connexion qui n’a jamais été traduite ne l’atteint jamais.

Il y a deux correctifs honnêtes et une mauvaise habitude. Les bonnes options sont de laisser les joueurs internes utiliser l’adresse privée ou un nom split-DNS qui se résout en interne vers l’adresse privée, ou d’activer la réflexion sur le routeur si la fonction existe et se comporte correctement. La mauvaise habitude est d’ouvrir plus de ports ou de désactiver le pare-feu de l’hôte, ce qui ne peut pas affecter une traduction que le routeur n’a jamais faite.

La documentation Netgate sur la réflexion NAT décrit plus en détail la distinction entre extérieur et intérieur et l’alternative split-DNS. Lisez-la comme une description du mécanisme plutôt que comme la promesse qu’un fournisseur VPN ou un routeur particulier prend en charge toutes les variantes de loopback.

Recueillez des preuves depuis chaque point de vue

Pour chaque test, notez qui l’a lancé, d’où, à quelle heure, contre quelle adresse et quel port, et ce que le serveur a journalisé. Un refus du jeu avec une raison claire dans la console du serveur est une constatation différente d’une connexion qui n’est jamais arrivée, et les deux mènent dans des directions opposées.

Si les joueurs distants autorisés se connectent et qu’un joueur local ne peut pas, le chemin local est la question restante et mérite sa propre enquête : quelle adresse le client a utilisée, ce que le routeur a fait de la traduction, et si le serveur a enregistré la moindre tentative de connexion. Transmettez ces trois faits à qui possède le réseau au lieu de rouvrir des ports au hasard.