Liste de jeux LAN vide via OpenVPN ? Vérifiez le chemin de découverte

Pinguer l'adresse de tunnel d'un autre joueur et voir sa partie hébergée sont deux réussites différentes. La liste du salon dépend généralement d'un échange de découverte écrit pour un seul réseau local, alors que la session de jeu est une connexion ordinaire à une adresse et un port. Traiter une liste vide comme une panne de routage vous oriente vers un pont dont vous n'avez peut-être pas besoin : séparez donc les deux questions avant de changer quoi que ce soit.

Séparez le fait de rejoindre une session de celui de la trouver

Une connexion échouée désigne des routes, des règles de pare-feu et un service à l'écoute. Une connexion réussie avec une liste vide désigne la découverte, ou l'adresse que porte l'annonce. Ces deux résultats mènent à un travail totalement différent, et vous ne pouvez les distinguer qu'en essayant délibérément le premier.

Notez le résultat avant de toucher à la configuration VPN. C'est le test le moins coûteux de toute l'enquête et il élimine la moitié de l'espace de conception. Notez aussi l'adresse utilisée, car elle devient le point de référence de chaque test ultérieur. Sans cette ligne dans vos notes, la comparaison suivante n'est qu'une conjecture.

Testez une connexion directe avant de toucher au tunnel

Si le jeu propose une connexion directe, utilisez l'adresse de tunnel de l'hôte et le port documenté du jeu, et laissez intactes l'authentification propre au jeu et les règles de pare-feu de l'hôte. Une connexion réussie réduit le problème à la découverte. Une connexion échouée demande encore sa propre enquête, et aucun relais ne la corrigera.

Ne supposez pas que le port de découverte et le port de session soient le même numéro. Les jeux annoncent souvent sur un port UDP et acceptent les joueurs sur un autre, et un relais construit pour le mauvais produit une liste qui reste vide.

Vérifiez aussi quel adaptateur le processus d'hébergement a choisi. Un processus lié à l'adresse du LAN domestique annoncera cette adresse, et le joueur distant ne peut pas y router même si l'annonce arrive. La liste peut se remplir et la connexion échouer pour cette seule raison.

Comprenez où s'arrête la diffusion

Un tunnel TUN routé transporte des paquets IP entre pairs et ne reproduit pas la diffusion locale sur le réseau de chaque pair. L'adresse de diffusion limitée 255.255.255.255 reste à l'intérieur de l'interface qui l'émet, et une diffusion dirigée vers un sous-réseau est un cas distinct et non une licence générale permettant aux routeurs d'inonder les annonces.

C'est une propriété de la conception, pas un défaut à corriger avec une option. OpenVPN et son réglage client-to-client régit le trafic entre pairs à l'intérieur du tunnel et n'est pas un relais de découverte, même s'il est proposé à cette fin dans de nombreux fils. Un relais est un composant distinct, avec sa propre configuration et ses propres modes de défaillance. Supposer qu'une option existante couvre déjà cela est la façon la plus courante dont cette enquête s'enlise.

La découverte multicast rencontre le même problème avec une autre classe d'adresses, et elle exige un routage multicast ou un relais plutôt qu'une exception de diffusion.

Quand un relais est justifié, gardez-le étroit

Si la découverte automatique est une exigence, identifiez d'abord l'échange réel : diffusion ou multicast, adresse de destination, port UDP, l'interface qui l'envoie et l'adresse contenue dans la réponse. Un relais adapté au protocole et limité à ces cinq faits est bien plus étroit que l'extension d'un segment Ethernet entier.

Transmettre le paquet sans le modifier peut encore être insuffisant. Si la charge utile dit au destinataire de se connecter à une adresse qu'il ne peut pas atteindre, le relais livre une réponse inutile : c'est pourquoi l'interface propre au jeu ou le réglage d'adresse annoncée doit être essayé avant qu'un relais n'existe.

Limitez le relais aux interfaces et aux pairs qui en ont besoin, et définissez comment les réponses retrouvent le demandeur. Répéter des diffusions sans rapport expose d'autres services locaux et crée des boucles pénibles à déboguer ensuite.

Pont uniquement lorsque la conception exige Ethernet

Les trames Ethernet circulent dans TAP, donc un tunnel TAP peut appartenir à un domaine de diffusion délibérément ponté. Le simple fait de passer de dev tun à dev tap ne construit pas ce pont, ne rend pas la configuration du serveur compatible et n'amène pas l'application à choisir la nouvelle interface. Le guide de pontage d'OpenVPN décrit l'agencement plus large, pas un remède pour un salon vide.

Le pontage aplatit aussi le plan d'adressage, et c'est pourquoi la décision mérite une raison au-delà de l'impatience. Deux réseaux qui étaient séparés n'en font plus qu'un, et chaque service de part et d'autre commence à voir les diffusions de l'autre côté. Cette conséquence appartient au journal des changements avant que quiconque l'active. Aucune règle n'exige que les clients de jeu soient dans une plage 192.168 ; choisissez un plan sans chevauchement et vérifiez les restrictions du jeu concerné au lieu de renuméroter le tunnel parce qu'un message de forum l'a fait.

À la fin, gardez les deux résultats séparés : si l'on peut rejoindre l'hôte, et si la réponse de découverte annonce une destination que l'autre joueur peut réellement utiliser. Corriger le second sans confirmer le premier, c'est ainsi que les gens finissent par maintenir un pont pour un problème qui n'a jamais concerné la diffusion.