No dudes en compartir nuestra web y códigos en tus redes sociales, ayúdanos a ampliar esta comunidad.
Solución:
Puede utilizar registros SRV:
_service._proto.name. TTL class SRV priority weight port target.
Servicio: el nombre simbólico del servicio deseado.
Proto: el protocolo de transporte del servicio deseado; esto suele ser TCP o UDP.
Nombre: el nombre de dominio para el cual este registro es válido, terminado en un punto.
TTL: tiempo estándar de DNS para el campo de vida.
Clase: campo de clase de DNS estándar (siempre es IN).
Prioridad: la prioridad del host de destino, un valor más bajo significa más preferido.
Peso: Un peso relativo para registros con la misma prioridad.
Puerto: el puerto TCP o UDP en el que se encuentra el servicio.
Objetivo: el nombre de host canónico de la máquina que proporciona el servicio, que termina en un punto.
Ejemplo:
_sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com.
Entonces, creo que lo que está buscando es agregar algo como esto a su archivo de hosts DNS:
_sip._tcp.arboristal.com. 86400 IN SRV 10 40 25565 mc.arboristal.com.
_sip._tcp.arboristal.com. 86400 IN SRV 10 30 25566 tekkit.arboristal.com.
_sip._tcp.arboristal.com. 86400 IN SRV 10 30 25567 pvp.arboristal.com.
En una nota al margen, le recomiendo encarecidamente que vaya con una empresa de alojamiento en lugar de alojar los servidores usted mismo. Solo busca problemas con la conexión de su hogar (DDoS y ancho de banda / velocidad de conexión), pero depende de usted.
(Ha pasado un tiempo desde que hice estas cosas. No asumas ciegamente que todos los detalles a continuación son correctos. Pero espero no serlo también vergonzosamente mal. :))
Como se indicó en la respuesta anterior, el cliente de Minecraft (a partir de 1.3.1) admite la búsqueda de registros SRV utilizando el nombre del servicio _minecraft y el nombre del protocolo _tcp, lo que significa que si su archivo de zona se ve así …
arboristal.com. 86400 IN A
_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.
… entonces los clientes de Minecraft que realizan la búsqueda de registros SRV como se indica en el registro de cambios usarán los puertos 25566 y 25567 con preferencia (40% del tiempo cada uno) sobre el puerto 25565 (20% del tiempo). Podemos suponer que los clientes de Minecraft que lo hacen no encontrar y respetar estos registros SRV utilizará el puerto 25565 como de costumbre.
Sin embargo, yo diría que en realidad sería más “limpio y profesional” hacerlo usando un balanceador de carga como Nginx. (Elijo Nginx solo porque lo he usado antes. No estoy diciendo que sea especialmente adecuado para esta tarea. Incluso podría ser un malo elección por alguna razón). Entonces no tiene que meterse con su DNS, y puede usar el mismo enfoque para equilibrar la carga alguna service, no solo aquellos como Minecraft que han hecho el arduo trabajo del lado del cliente para buscar y respetar los registros SRV. Para hacerlo a la manera de Nginx, ejecutaría Nginx en el arboristal.com máquina con algo como lo siguiente en /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;
Aquí estamos controlando el equilibrio de carga nosotros mismos en el lado del servidor (a través de Nginx), por lo que ya no tenemos que preocuparnos de que los clientes con mal comportamiento prefieran el puerto 25565 a los otros dos puertos. De hecho, ahora todos los clientes hablarán con arboristal.com:25565! Pero el oyente en ese puerto ya no es un servidor de Minecraft; es Nginx, que envía secretamente todo el tráfico a otros tres puertos de la misma máquina.
Equilibramos la carga en función de un hash de la dirección IP del cliente (ip_hash), de modo que si un cliente se desconecta y luego se vuelve a conectar más tarde, es muy probable que se vuelva a conectar al mismo servidor de Minecraft que tenía antes. (No sé cuánto le importa esto a Minecraft, o cómo los clientes habilitados para SRV están programados para lidiar con este aspecto).
Observe que solíamos ejecutar un servidor de Minecraft en el puerto 25565; Lo moví al puerto 25568 para que podamos usar el puerto 25565 para el equilibrador de carga.
Una posible desventaja del método Nginx es que convierte a Nginx en un cuello de botella en su sistema. Si Nginx falla, los tres servidores se vuelven inaccesibles. Si alguna parte de su sistema no puede mantenerse al día con el volumen de tráfico en ese único puerto, 25565, los tres servidores se vuelven inestables. Y sin mencionar que Nginx es una gran dependencia nueva en su ecosistema. Tal vez no desee introducir otra pieza de software masiva con un lenguaje de configuración complicado y una gran superficie de ataque. Puedo respetar eso.
Un posible ventaja del método Nginx es … ¡que convierte a Nginx en un cuello de botella en su sistema! Puede aplicar políticas globales a través de Nginx, como rechazar paquetes por encima de cierto tamaño o responder con un static página web a las conexiones HTTP en el puerto 80. También puede utilizar el firewall de los puertos 25566, 25567 y 25568 desde Internet, ya que ahora deben comunicarse con ellos solamente por Nginx a través de la interfaz de bucle invertido. Esto reduce un poco su superficie de ataque.
Nginx también facilita la adición de nuevos servidores de Minecraft a su backend; ahora solo puedes agregar un server línea a su configuración y service nginx reload. Usando el antiguo enfoque basado en puertos, tendría que agregar un nuevo registro SRV con su proveedor de DNS (y podría tomar hasta 86400 segundos para que los clientes noten el cambio) y luego además recuerde editar su firewall (p. ej. /etc/iptables.rules) para permitir el tráfico externo sobre ese nuevo puerto.
Nginx también le libera de tener que pensar en los TTL de DNS al realizar cambios en las operaciones. Suponga que decide dividir sus tres servidores de Minecraft en tres máquinas físicas diferentes con diferentes direcciones IP. Usando Nginx, puede hacerlo completamente a través de cambios de configuración en su server líneas, y puede mantener esas nuevas máquinas dentro de su firewall (conectadas solo a Nginx a través de una interfaz privada), y los cambios entrarán en vigencia de inmediato, por definición. Mientras que, al usar registros SRV, tendrá que reescribir su archivo de zona en algo como esto …
arboristal.com. 86400 IN CNAME mc1.arboristal.com.
mc1.arboristal.com. 86400 IN A
mc2.arboristal.com. 86400 IN A
mc3.arboristal.com. 86400 IN A
_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.
… y tendrás que dejar las tres nuevas máquinas pinchando fuera de su firewall para que puedan recibir conexiones desde Internet. Y tendrás que esperar hasta 86400 segundos para que sus clientes noten el cambio, lo que podría afectar la complejidad de su plan de implementación. Y si estaba ejecutando otros servicios (como un servidor HTTP) en arboristal.com, ahora tienes que moverlos a la mc1.arboristal.com máquina debido a cómo hice ese CNAME. Hice eso solo en beneficio de esos hipotéticos clientes de Minecraft que no respetan los registros SRV y todavía intentarán conectarse a arboristal.com:25565.
Entonces, creo que ambas formas (registros SRV y balanceo de carga de Nginx) son razonables, y su elección dependerá de sus preferencias personales. Caricaturizo las opciones como:
- Registros SRV: “Solo necesito que funcione. No quiero complejidad. Y conozco y confío en mi proveedor de DNS”.
- Nginx: “preveo
arboristal.comconquistar el mundo, o al menos mudarse a una máquina más grande algún día. No tengo miedo de aprender una nueva herramienta. ¿Qué es un archivo de zona? “
Como tuve problemas para entender esta publicación, aquí hay una explicación simple para personas como yo. Es útil si:
- NO necesita balanceo de carga.
- NO desea utilizar nginx para realizar el reenvío de puertos.
- Desea hacer el REENVÍO DE PUERTOS de acuerdo con subdominios específicos usando el registro SRV.
Entonces, esto es lo que debe hacer:
Registros SRV:
_minecraft._tcp.1.12 IN SRV 1 100 25567 1.12..
_minecraft._tcp.1.13 IN SRV 1 100 25566 1.13..
(No necesitaba un registro srv para 1.14 ya que mi servidor de Minecraft 1.14 ya estaba en el puerto 25565, que es el puerto predeterminado de Minecraft).
Y los registros A:
1.12 IN A
1.13 IN A
1.14 IN A