Pourquoi votre jeu en LAN disparaît avant d’ajouter un VPN
Une liste de serveurs vide est souvent un problème d’édition ou de découverte, pas un tunnel manquant. Déterminez d’abord lequel des trois modèles multijoueur le jeu utilise.
Un groupe de personnes installe un jeu, se connecte au même réseau et voit une liste de serveurs vide. Le réflexe est d’accuser le réseau et de chercher un tunnel, mais le jeu n’a peut-être jamais envoyé de paquet qu’un tunnel pourrait transporter. Avant qu’un VPN n’entre en scène, déterminez laquelle de trois choses l’édition fait réellement quand quelqu’un clique sur multijoueur.
Ces trois choses ne sont pas interchangeables. L’une utilise du trafic local direct, l’autre demande à un service qui d’autre joue, et la troisième refuse de démarrer sans compte. Un tunnel peut aider pour la première, est sans effet sur la deuxième et ne peut pas corriger la troisième. Cet ordre compte, parce que les trois peuvent produire la même liste vide avec trois correctifs différents.
Ce que le jeu vérifie avant de lister un hôte
La plupart des menus multijoueur font plusieurs choses à la suite : confirmer le compte connecté, vérifier les droits de l’édition, interroger un backend pour les salons ou les amis, et seulement ensuite regarder le réseau local. Chaque étape peut échouer silencieusement, et l’interface affiche généralement la même liste vide dans les deux cas. C’est pourquoi « le LAN est cassé » est un diagnostic qu’on ne peut pas poser depuis l’écran seul. Une erreur de backend, un droit expiré et un sous-réseau isolé sont indistinguables depuis l’écran du salon, et un seul d’entre eux est réellement un problème de réseau.
Lisez la documentation de l’édition elle-même avant de modifier les paramètres réseau. Les remasters abandonnent régulièrement la connexion directe par IP, remplacent la découverte LAN par un salon hébergé ou exigent un compte de plateforme dont la version d’origine n’avait jamais besoin. La page d’assistance de l’actuelle Age of Empires II: Definitive Edition, par exemple, décrit un salon hébergé sur les serveurs du jeu où l’on choisit visibilité, mot de passe et région ; c’est un flux de travail de l’application à vérifier pour cette édition, pas une preuve concernant une version antérieure.
Notez le numéro de build autant que le nom de l’édition. Un correctif peut faire passer un jeu d’un modèle à un autre, et des instructions écrites pour le build de lancement peuvent décrire un menu qui n’existe plus.
Les paquets de découverte meurent au premier routeur
Le jeu direct en LAN dépend généralement du broadcast ou du multicast : l’hôte s’annonce à une adresse couvrant tout le sous-réseau, et les clients écoutent cette annonce. Ces paquets ne sont pas routables par conception, donc un routeur entre les deux machines les jette même quand le trafic unicast passerait. Deux appareils sur le même commutateur se voient ; les mêmes deux appareils sur des VLAN différents, ou sur un réseau invité avec isolation des clients, ne se voient pas. Les consoles et les téléphones suivent généralement le même schéma avec leur propre protocole de découverte, et c’est pourquoi la plateforme compte autant que le jeu.
C’est de là que viennent la plupart des signalements « même Wi-Fi, aucun serveur ». Un SSID invité avec isolation activée, un système mesh qui place la console sur un segment séparé, ou un profil de pare-feu qui traite le sous-réseau local comme public briseront chacun la découverte tout en laissant l’accès internet ordinaire fonctionner. Vérifiez le réglage d’isolation des clients et le masque de sous-réseau avant de supposer que le jeu est en cause.
Un service de salon n’est pas un chemin réseau
Quand le jeu utilise un salon hébergé, la liste des parties vient des serveurs de l’opérateur, pas de votre sous-réseau. Un VPN change le chemin que prennent vos paquets vers ces serveurs, mais il ne change pas les salons que le service vous montre, la région où la partie est hébergée, ni si votre compte a le droit de la rejoindre. Ce sont des réponses du backend, et aucun routage ne les change.
Dans ce modèle, un tunnel est au mieux une variable de latence et au pire un problème de géodétection, parce que le service voit l’adresse de sortie plutôt que votre adresse postale. La même logique s’applique aux invitations d’amis et aux systèmes d’équipe. Ce sont des fonctions au niveau du compte que la plateforme arbitre, et c’est pourquoi deux joueurs sur le même LAN peuvent ne pas se voir dans un salon alors que tous deux peuvent rejoindre la partie d’un inconnu.
Ce qu’un tunnel peut reconstruire, et ce qu’il ne peut pas
Un tunnel est utile quand les joueurs sont à des endroits différents et que le jeu prend en charge la connexion directe par adresse. Un tunnel routé transporte du trafic unicast entre les deux sites ; un tunnel ponté, ou une superposition qui présente un segment Ethernet virtuel, peut aussi transporter la découverte broadcast dont dépend le jeu direct en LAN. C’est la distinction à comprendre : le routage déplace les paquets entre sous-réseaux, le pontage fait ressembler deux sites à un seul sous-réseau.
Ce qu’un tunnel ne peut pas faire, c’est ajouter un mode multijoueur que l’application n’implémente pas. Si l’édition a supprimé la connexion directe, un segment LAN virtuel ne la rétablira pas. Si le salon exige un compte, un tunnel ne satisfera pas cette vérification. Et si les deux machines sont derrière le même NAT avec une isolation entre elles, une superposition peut contourner l’isolation, mais c’est aussi un contournement de politique, donc une conversation avec celui qui administre le réseau.
Testez le chemin que le jeu utilise réellement
Commencez avec un hôte et un client sur le même sous-réseau, isolation désactivée et sans tunnel. Si cela fonctionne, le jeu et l’édition prennent en charge ce que vous essayez de faire, et tout échec ultérieur est un problème de chemin. Si cela échoue là, le tunnel n’a jamais été la réponse.
Notez ensuite ce que le manuel dit de la méthode de connexion, du port ou du mécanisme de découverte et de toute exigence de compte. Changez une variable à la fois : d’abord le sous-réseau, puis le segment, puis le tunnel. Relevez l’adresse de l’hôte et le chemin exact dans le menu pour que la prochaine session reproduise le test au lieu de répéter la discussion.
Fixez la version, qui héberge, comment les gens rejoignent et quel compte ou abonnement la session exige, et écrivez-le avant la date. Cela met fin à plus de discussions qu’un tunnel n’en terminera jamais, et cela laisse une trace de ce qui a été testé.