Serveur de jeu

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 :)

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.

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

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.