Serveur de jeu

Hellsrider666 Messages postés 1 Date d'inscription dimanche 2 juin 2024 Statut Membre Dernière intervention 2 juin 2024 - 2 juin 2024 à 18:22
avion-f16 Messages postés 19249 Date d'inscription dimanche 17 février 2008 Statut Contributeur Dernière intervention 15 juin 2024 - 15 juin 2024 à 13:28

Bonjour,

j’heberge un serveur DayZ pour moi et mes potes, mais je me demande ce qu'il faudrait faire pour en créer un deuxième sur la même machine ? Un changement de port pourrait être ma solution ? 

Merci d’avance

1 réponse

Itdaboyz Messages postés 359 Date d'inscription mercredi 22 juin 2011 Statut Membre Dernière intervention 2 juillet 2024 99
2 juin 2024 à 22:05

Bonsoir,

Changement de port c'est parfait ça fonctionnera sans problèmes mais du coup tu vas devoir renseigner le port dans le client à chaque connexion.

Si t'as un nom de domaine et que tu t'y connais un peu en réseau il existe un moyen de faire en sorte que les clients se connectent à tes différents serveurs en utilisant le même port, il faut mettre en place un reverse proxy (nginx gère très bien ce problème, HAProxy également mais ne gère pas l'UDP donc pour les jeux pas ouf) qui écoute sur le port par défaut de DayZ et qui dispatch les requêtes au bon backend suivant le nom de domaine. C'est plus complexe à mettre en place et il te faut obligatoirement un nom de domaine.

a+

avion-f16 Messages postés 19249 Date d'inscription dimanche 17 février 2008 Statut Contributeur Dernière intervention 15 juin 2024 4 502
4 juin 2024 à 22:11

Bonjour,

Le concept de "virtualhost" auquel tu fais référence est spécifique à certains protocoles applicatifs et ne fonctionne pas pour une connexion IP/TCP ou IP/UDP générique (pour simplifier, je parlerai d'IP/TCP, mais cela s'applique aussi à UDP).

Lorsqu'une application cliente se connecte à un serveur en utilisant un nom de domaine ou un sous-domaine, ce nom est traduit en une adresse IP via la résolution DNS. Il est important de noter que la résolution DNS est une étape qui s'effectue sur l'ordinateur du client (en appelant un DNS quelconque) qui n'implique encore aucune communication avec le serveur que l'on tente de joindre. Ensuite, l'application établit une connexion TCP/IP vers cette adresse IP et le port spécifié (ou par défaut si aucun port n'est explicitement indiqué).

Au niveau du flux TCP/IP, il n'y a aucune différence entre un client qui se connecte à "example.com" et un client qui utilise directement l'adresse IP du serveur. L'information "example.com" est, en quelque sorte, perdue. Les routeurs sur le chemin se contentent de diriger les paquets TCP/IP vers une IP et un port, ils n'ont pas connaissance du nom de domaine utilisé. Le serveur, de son côté, reçoit le paquet IP destiné à son adresse IP sans savoir que le client a utilisé "example.com" ou "autre-domaine.com" pour obtenir cette IP.

Une fois la connexion TCP/IP établie, certains protocoles peuvent transmettre cette information au serveur. Pour TLS, cela se fait via l'extension SNI. Pour HTTP, l'en-tête "Host" est utilisé. Pour FTP, la commande "HOST" est employée. Ce sont les trois principaux protocoles qui me viennent à l'esprit, bien qu'il en existe probablement d'autres.

Pour les jeux vidéos, les applications client/serveur ne prévoient généralement pas ce type de "virtualhost", il faut donc publier les différents serveurs sur des IP ou des ports différents.

0
Itdaboyz Messages postés 359 Date d'inscription mercredi 22 juin 2011 Statut Membre Dernière intervention 2 juillet 2024 99 > avion-f16 Messages postés 19249 Date d'inscription dimanche 17 février 2008 Statut Contributeur Dernière intervention 15 juin 2024
Modifié le 12 juin 2024 à 21:46

C'est sympa d'avoir écrit un cours IP mais je parle bien d'un reverse proxy, pas d'utiliser des virtualhost.

Ta conclusion est mauvaise parce que tu pars du principe que l'applicatif doit supporter les virtualhost pour pouvoir router suivant le fqdn alors que je parle bien de mettre en place un reverse proxy en amont qui va gérer le routage vers les bons serveurs backend, peu importe le logiciel utilisé en backend, qu'il supporte les virtualhost ou non.

Regarde donc la doc haproxy à ce sujet :

https://www.haproxy.com/blog/how-to-map-domain-names-to-backend-server-pools-with-haproxy#how-to-map-domain-names-to-backend-server-pools-with-haproxy

Par exemple si tu veux host 2 serveurs minecraft tu vas faire écouter nginx sur le port 25565 (port par défaut de minecraft, ici je dis nginx car ce proxy supporte l'udp donc meilleurs choix pour un exemple qui traite des serveurs de jeu)

Ensuite tu fais tourner 2 serveurs minecraft, sur les ports que tu veux (autre que 25565), disons 25566 et 25567

Pour finir, tu configure nginx pour proxy les requête de a.mondomaine.fr vers localhost:25566 et b.mondomaine.fr vers localhost:25567, problème résolu, les clients se connectent soit à a.mondomaine.fr soit à b.mondomaine.fr en utilisant le port par défaut (25565) et nginx va router vers le serveur configuré.

Les reverse proxy sont une technologie que j'utilise presque tous les jours dans mon travail, je sais de quoi je parle :)

0
avion-f16 Messages postés 19249 Date d'inscription dimanche 17 février 2008 Statut Contributeur Dernière intervention 15 juin 2024 4 502 > Itdaboyz Messages postés 359 Date d'inscription mercredi 22 juin 2011 Statut Membre Dernière intervention 2 juillet 2024
Modifié le 13 juin 2024 à 23:01

Bonjour,

Le lien que tu donnes concerne le mode "web" de haproxy, c'est noté dans l'introduction de l'article, et l'article explique également que l'information est obtenue au travers de l'entête "Host" de HTTP :

Le lien en question n'est pas en contradiction avec ma réponse précédente, au contraire, il confirme ce que je disais : c'est possible en HTTP(S) via l'entête "Host", voire en TLS via le SNI.

Même si HAproxy n'utilise pas le terme de "virtualhost", c'est rendu possible à cause d'une particularité du protocole applicatif HTTP (son entête "Host"), le même principe utilisé par les "virtualhost" sur Apache/Nginx.

> Les reverse proxy sont une technologie que j'utilise presque tous les jours dans mon travail, je sais de quoi je parle :)

Ce n'est pas un argument, et visiblement tu ne fais pas la différence entre un reverse proxy pour du HTTP (couche 7 du modèle OSI) et un reverse proxy pour un flux TCP/UDP générique (couche 4).

Au risque de me répéter, la méthode du reverse proxy TCP/UDP ne fonctionnera pas pour différencier qui a utilisé a.example.com ou b.example.com. La partie application (couches supérieures à TCP/UDP) doit partager l'information avec le serveur.

D'ailleurs, avant que TLS s'équipe de l'extension SNI, les serveurs HTTPS/TLS n'avaient aucun moyen de savoir quel nom de domaine était utilisé pour atteindre le serveur. Un serveur HTTPS/TLS écoutant un couple ip/port ne pouvait proposer qu'un seul certificat, donc forcément, c'était pas idéal sur une IP mutualisée. Pour retourner le bon certificat, il fallait alors jouer sur l'IP ou le port. Le port 443 étant désiré de tout le monde, il ne restait que l'IP comme option. C'est pourquoi il fallait une IP dédiée pour chaque site. Si ce que tu prétends était possible, les IP dédiées (autrefois) et l'extensions SNI (aujourd'hui) ne seraient pas utiles, pas plus que l'entête "Host" en HTTP.


Si tu restes convaincu de ce que tu avances, je t'invite tout simplement à démontrer que c'est possible. Je te propose de mettre en place un service TCP/UDP quelconque, sur la même IP et le port, et qui serait capable de réagir différemment selon qu'on y accède avec a.example.com ou b.example.com, sans pour autant que l'information soit remontée par le client vers le serveur après établissement de la connexion TCP/UDP.

0
Itdaboyz Messages postés 359 Date d'inscription mercredi 22 juin 2011 Statut Membre Dernière intervention 2 juillet 2024 99 > avion-f16 Messages postés 19249 Date d'inscription dimanche 17 février 2008 Statut Contributeur Dernière intervention 15 juin 2024
14 juin 2024 à 21:12

Ca change de sujet mais bon un exemple avec minecraft du coup qui ne supporte pas les virtualhost nativement mais qui fonctionne parfaitement bien avec un reverse proxy. Chose qui fonctionne parce qu'évidemment le handshake contient l'adresse du serveur donc jte laisse me répondre que ça fonctionne pas pour tout mais c'était pas trop le sujet il me semble.

https://streamable.com/irb6va

0
avion-f16 Messages postés 19249 Date d'inscription dimanche 17 février 2008 Statut Contributeur Dernière intervention 15 juin 2024 4 502 > Itdaboyz Messages postés 359 Date d'inscription mercredi 22 juin 2011 Statut Membre Dernière intervention 2 juillet 2024
Modifié le 15 juin 2024 à 13:41

Comme tu le dis, pour Minecraft, son protocole applicatif prévoit un handshake qui contient le nom d'hôte, ce qui permet à un reverse proxy de faire un routage vers le bon backend en fonction du nom. Voir ici et ici.

Si on met de côté les reverse proxy : tout comme un serveur HTTP utilise l'entête "Host" pour proposer des virtualhosts, un serveur Minecraft pourrait utiliser le nom apparaissant dans le handshake pour proposer des "serveurs virtuels" (virtualhosts) fonctionnant sur le même couple "port:ip".

=> Ce que je veux dire par là, c'est que la question ne concerne même pas "avec reverse proxy" ou "sans reverse proxy". Pour que ça soit possible avec un reverse proxy, il faut d'abord que ça soit possible sans reverse proxy. Tu dis "ça change de sujet" mais en l’occurrence, mentionner les reverse proxy dans cette discussion était déjà un premier hors sujet de ta part.

Je disais :

Pour les jeux vidéos, les applications client/serveur ne prévoient généralement pas ce type de "virtualhost", il faut donc publier les différents serveurs sur des IP ou des ports différents

En parlant de Minecraft (ce n'était pas le sujet initial), tu as trouvé une exception.

Mais pour en revenir au sujet initial, DayZ, on ne peut pas en dire autant. Ta solution du reverse proxy ne fonctionnera pas pour ce jeu, ni pour la majorité des jeux.

0