Comment rediriger des DNS vers différents ports

(ça fait longtemps que je n'ai pas fait ce truc. Merci de ne pas aveuglément supposons que les détails ci-dessous sont correctes. Mais j'espère que je ne suis pas trop trop de mal. :))

comme la réponse précédente l'indiquait, le client Minecraft ( à partir du 1.3.1) prend en charge enregistrement SRV recherche en utilisant le nom du service _minecraft et le nom de protocole _tcp, ce qui signifie que si votre fichier de zone ressemble ce...

arboristal.com.                 86400 IN A   <your IP address>
_minecraft._tcp.arboristal.com. 86400 IN SRV 10 20 25565 arboristal.com.
_minecraft._tcp.arboristal.com. 86400 IN SRV 10 40 25566 arboristal.com.
_minecraft._tcp.arboristal.com. 86400 IN SRV 10 40 25567 arboristal.com.

...ensuite, les clients Minecraft qui effectuent la recherche d'enregistrements SRV comme indiqué dans le journal des modifications utiliseront les ports 25566 et 25567 Avec préférence (40% du temps chacun) sur le port 25565 (20% du temps). Nous pouvons supposer que les clients de Minecraft qui font trouver et respecter ces notices SRV utiliseront le port 25565 comme d'habitude.

cependant, je dirais qu'il serait en fait plus "propre et professionnel" de le faire en utilisant une charge balancer comme Nginx. (Je choisis Nginx juste parce que je l'ai utilisé avant. Je ne dis pas qu'il est particulièrement bien adapté à cette tâche. Cela pourrait même être un mauvais choix pour une raison quelconque. Ensuite, vous n'avez pas à jouer avec votre DNS, et vous pouvez utiliser la même approche pour équilibrer la charge service, pas seulement ceux comme Minecraft qui se trouvent avoir fait le dur travail côté client pour chercher et respecter les dossiers SRV. Pour le faire à la manière de Nginx, vous lancez Nginx sur le arboristal.com machine avec quelque chose comme ce qui suit dans /etc/nginx/sites-enabled/arboristal.com:

upstream minecraft_servers {
    ip_hash;
    server 127.0.0.1:25566 weight=1;
    server 127.0.0.1:25567 weight=1;
    server 127.0.0.1:25568 weight=1;
}
server {
    listen 25565;
    proxy_pass minecraft_servers;
}

ici, nous contrôlons l'équilibrage de la charge nous-mêmes du côté du serveur (via Nginx), donc nous n'avons plus à nous inquiéter que des clients mal comportés puissent préférer le port 25565 aux deux autres ports. En fait, maintenant les clients vont parler à arboristal.com:25565! Mais l'écouteur sur ce port n'est plus un serveur Minecraft; c'est Nginx, secrètement proxying tout le trafic sur trois autres ports sur le même machine.

Nous équilibrage de charge basé sur un hash de l'adresse IP du client (ip_hash), de sorte que si un client se déconnecte et se reconnecte plus tard, il y a de bonnes chances qu'il soit reconnecté au même serveur Minecraft qu'avant. (Je ne sais pas combien cela compte pour Minecraft, ou comment les clients compatibles SRV sont programmés pour traiter cet aspect.)

notez que nous avions l'habitude d'exécuter un serveur Minecraft sur le port 25565; Je l'ai déplacé sur le port 25568 pour que nous puissions utiliser port 25565 pour le Load-balancer.

Un inconvénient de la Nginx méthode est qu'elle fait de Nginx un goulot d'étranglement dans votre système. Si Nginx tombe, alors les trois serveurs deviennent inaccessibles. Si une partie de votre système ne peut pas suivre le volume de trafic sur ce port unique, 25565, les trois serveurs deviennent flous. Et pour ne pas mentionner, Nginx est une nouvelle grande dépendance dans votre écosystème. Peut-être que vous ne voulez pas présenter encore un autre énorme morceau de logiciel avec un langage de configuration compliqué et surface d'attaque énorme. Je peux respecter ça.

possible avantage de la méthode Nginx est... qu'il fait Nginx un goulot d'étranglement dans votre système! Vous pouvez appliquer des politiques globales via Nginx, comme rejeter des paquets d'une certaine taille, ou répondre avec une page Web statique à des connexions HTTP sur le port 80. Vous pouvez aussi désactiver les ports 25566, 25567 et 25568 à partir D'Internet, puisque maintenant ils devraient être consultés par Nginx sur l'interface de loopback. Cela réduit quelque peu votre Surface d'attaque.

Nginx rend également plus facile d'ajouter de nouveaux serveurs Minecraft à votre backend; maintenant, vous pouvez simplement ajouter un server ligne de votre config et service nginx reload. En utilisant l'ancienne approche basée sur les ports, vous devrez ajouter un nouvel enregistrement SRV avec votre fournisseur DNS (et cela pourrait prendre jusqu'à 86400 secondes pour les clients de remarquer le changement), puis n'oubliez pas d'éditer votre pare-feu (par exemple,/etc/iptables.rules) permettre le trafic externe sur ce nouveau port.

Nginx vous évite également d'avoir à penser aux TTL DNS lors de modifications ops. Supposons que vous décidiez de diviser vos trois serveurs Minecraft sur trois machines physiques différentes avec des adresses IP différentes. En utilisant Nginx, vous pouvez faire cela complètement via les changements de configuration de votre server et vous pouvez garder ces nouvelles machines à l'intérieur de votre pare-feu (connecté uniquement à Nginx via une interface privée), et les changements prendront effet immédiatement, par définition. Alors que, en utilisant les enregistrements SRV, vous devrez réécrire votre fichier de zone à quelque chose comme ça...

arboristal.com.                 86400 IN CNAME mc1.arboristal.com.
mc1.arboristal.com.             86400 IN A   <a new machine's IP address>
mc2.arboristal.com.             86400 IN A   <a new machine's IP address>
mc3.arboristal.com.             86400 IN A   <a new machine's IP address>
_minecraft._tcp.arboristal.com. 86400 IN SRV 10 20 25565 mc1.arboristal.com.
_minecraft._tcp.arboristal.com. 86400 IN SRV 10 40 25565 mc2.arboristal.com.
_minecraft._tcp.arboristal.com. 86400 IN SRV 10 40 25565 mc3.arboristal.com.

...et vous devrez laisser les trois nouvelles machines poking dehors votre pare-feu pour qu'ils puissent recevoir des connexions à partir d'Internet. Et vous aurez à attendre jusqu'à 86400 secondes pour que vos clients remarqué le changement, ce qui pourrait affecter la complexité de votre plan de déploiement. Et si vous avez été exécuter tout autre service (tel QU'un serveur HTTP) sur arboristal.com, maintenant vous devez les déplacer vers le mc1.arboristal.com machine en raison de la façon dont j'ai fait ce CNAME. J'ai fait cela seulement pour le bénéfice de ces clients Minecraft hypothétiques qui ne respectent pas les enregistrements SRV et vont toujours essayer de se connecter à arboristal.com:25565.

donc, je pense que les deux façons (SRV records et Nginx load-balancing) sont raisonnables, et votre choix dépendra de vos préférences personnelles. Je caricature les options comme:

• enregistrements SRV: "j'ai juste besoin de travailler. Je ne veux pas de complexité. Et je connais et je fais confiance à mon fournisseur de DNS."
• Nginx: "je prévois arboristal.com prendre le contrôle du monde, ou au moins passer à une plus grande machine un jour. Je n'ai pas peur d'apprendre un nouvel outil. C'est quoi un fichier de zone?"