Minecraft via un VPN : quelle adresse mettre dans la liste des serveurs ?
Le point de terminaison VPN construit le tunnel ; le jeu a besoin de l’adresse privée de l’hôte et du port. Associez les rôles aux adresses, puis vérifiez l’écouteur, la route et les règles de l’hôte.
Taper le point de terminaison VPN dans la liste des serveurs de Minecraft semble logique et échoue à chaque fois, car cette adresse termine le tunnel au lieu d’héberger le jeu. Un joueur connecté au même VPN a déjà un chemin vers l’hôte du jeu, donc l’entrée doit nommer l’hôte et le port sur lequel le jeu écoute. Corrigez ces deux points et le reste du problème n’est que l’accessibilité ordinaire d’un service, une liste de contrôle bien plus courte qu’elle n’en a l’air au premier abord.
Deux adresses, deux rôles
Une adresse est une infrastructure publique : le point de terminaison de transport qui achemine les paquets chiffrés entre pairs. L’autre est une adresse privée appartenant à la machine qui exécute le serveur dédié. Elles ne sont pas interchangeables, et substituer l’une à l’autre produit une connexion refusée ou un délai d’attente dépassé qui ressemble à un problème de pare-feu.
| Role | Address | Where it belongs |
|---|---|---|
| Public transport endpoint | 203.0.113.40 | VPN client configuration, never the game |
| Game host on the VPN | 10.60.0.20 | Server address field, with the port |
| Player peer | 10.60.0.30 | Assigned by the tunnel, nothing to type |
Avec le port par défaut, le joueur tape 10.60.0.20:25565 et rien d’autre. La page de téléchargement du serveur Java de Mojang indique 25565 comme port par défaut, et il faut croire l’opérateur qui a changé le port plutôt que d’en douter à partir d’un vieux tutoriel.
Faites de cette adresse un vrai service
Une adresse joignable est nécessaire et non suffisante. Le serveur dédié doit tourner, être compatible avec la version qu’exécute le client du joueur et écouter sur une adresse à laquelle le tunnel peut livrer. Un processus lié uniquement à loopback ne devient pas joignable parce que quelqu’un a ajouté une autre adresse à la machine.
Confirmez l’écouteur avant de toucher à un pare-feu :
ss -lntp | grep 25565
nc -vz 10.60.0.20 25565
La première ligne montre ce à quoi le processus s’est réellement lié, et la seconde si un pair peut terminer une poignée de main TCP. Quand la liaison est 127.0.0.1, aucune quantité de configuration VPN ne change le résultat, et ce seul détail explique un nombre surprenant de signalements « le VPN est cassé ».
Politique des pairs, pare-feu et chemin de retour
Deux questions d’autorisation se posent au-dessus de l’écouteur. La configuration des pairs du VPN doit autoriser le trafic entre les deux pairs, et le pare-feu de l’hôte du jeu doit accepter le port du jeu depuis ce pair. Gardez les deux limités au service de jeu et aux pairs autorisés au lieu de désactiver le pare-feu de l’hôte, ce qui échange une règle de deux lignes contre un problème bien plus gros. Les règles étroites sont aussi la seule version de cela qui passe un audit de sécurité sans un paragraphe de justification.
Rappelez-vous ensuite ce que prouve un ping réussi. Atteindre la passerelle VPN, ou obtenir une réponse de l’hôte du jeu, démontre seulement que l’ICMP a traversé le chemin. Une connexion de jeu exige que le port précis soit ouvert dans les deux sens, et le chemin de retour compte autant que le chemin sortant.
Quand le serveur est derrière la passerelle
L’exemple ci-dessus a le serveur de jeu comme pair, ce qui garde le plan d’adressage trivial. Si le serveur vit plutôt sur un LAN derrière une passerelle VPN, le joueur a besoin de l’adresse privée routable du serveur, la passerelle doit avoir le transfert configuré pour ce LAN, et l’hôte du LAN a besoin d’une route de retour vers le client tunnelisé. Ratez le chemin de retour et la poignée de main meurt à mi-chemin, ce qui est la panne la plus déroutante des trois.
Ne copiez pas l’adresse de pair de l’exemple sur une autre machine pour imiter cette topologie. Les adresses d’un exemple décrivent des rôles, et réutiliser l’une d’elles sur deux rôles crée un chevauchement que le routage ne peut pas résoudre.
Découverte, comptes et ce qu’il ne faut pas changer
La découverte automatique du LAN est une commodité bâtie sur des annonces. Un VPN routé n’a pas à transporter ces diffusions, donc une entrée absente de la liste LAN ne dit rien sur le fait que l’adresse privée explicite fonctionne. Tapez l’adresse, puis jugez. Si elle se connecte, le manque de découverte est une gêne d’usage et non une panne, et il peut être documenté comme tel au lieu d’être étudié.
Gardez aussi intactes l’authentification normale du compte et la politique d’admission du jeu. Une route privée fonctionnelle accorde un chemin, pas une appartenance, et aucun remaniement des priorités d’adaptateur ne remplace l’identification de la destination que le client devrait utiliser.