Как перенаправить DNS на разные порты

Ответ 1

Вы можете использовать записи SRV:

_service._proto.name. TTL class SRV priority weight port target.

Сервис: символическое имя нужной службы.

Прото: транспортный протокол требуемой службы; обычно это либо TCP, либо UDP.

Имя: имя домена, для которого эта запись действительна, заканчивается точкой.

TTL: стандартное время DNS для живого поля.

Класс: стандартное поле класса DNS (это всегда IN).

Приоритет: приоритет целевого хоста, более низкое значение означает более предпочтительное.

Вес: Относительный вес для записей с одинаковым приоритетом.

Порт: порт TCP или UDP, на котором должна быть найдена служба.

Цель: каноническое имя хоста машины, предоставляющей услугу, заканчивающееся точкой.

Пример:

_sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com.

Итак, я думаю, что вы ищете, чтобы добавить что-то подобное в ваш файл хостов 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.

С другой стороны, я настоятельно рекомендую вам пойти с хостинговой компанией, а не размещать серверы самостоятельно. Он просто запрашивает проблемы с домашним подключением (DDoS и Bandwidth/Connection Speed), но это зависит от вас.

Ответ 2

(Прошло некоторое время с тех пор, как я сделал это. Пожалуйста, не слепо предположите, что все приведенные ниже детали верны. Но я надеюсь, что не слишком смущаю.))

Как было сказано в предыдущем ответе, клиент Minecraft (от версии 1.3.1) поддерживает запись SRV, используя имя службы _minecraft и имя протокола _tcp, что означает, что если ваш файл зоны выглядит так...

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.

... тогда клиенты Minecraft, которые выполняют поиск записей SRV, как намечено в списке изменений, будут использовать порты 25566 и 25567 с предпочтением (40% времени каждый) через порт 25565 (20% времени). Мы можем предположить, что клиенты Minecraft, которые не находят и не уважают эти записи SRV, будут использовать порт 25565, как обычно.

Однако я бы сказал, что на самом деле было бы более "чистым и профессиональным" сделать это с помощью балансировщика нагрузки, такого как Nginx. (Я выбираю Nginx только потому, что раньше использовал его. Я не утверждаю, что он однозначно подходит для этой задачи. По какой-то причине это может быть даже плохой выбор.) Тогда вам не нужно связываться с вашим DNS и вы можете использовать тот же подход для балансировки нагрузки любой службы, а не только таких, как Minecraft, которые, как оказалось, сделали жесткую работу на стороне клиента, чтобы искать и уважать записи SRV. Чтобы сделать это способом Nginx, вы запустили Nginx на машине arboristal.com с чем-то вроде следующего в /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;
}

Здесь мы контролируем балансировку нагрузки на стороне сервера (через Nginx), поэтому нам больше не нужно беспокоиться о том, что плохо управляемые клиенты могут предпочесть порт 25565 для двух других портов. Фактически, теперь все клиенты будут разговаривать с arboristal.com:25565! Но слушатель в этом порту уже не является сервером Minecraft; это Nginx, тайно проксируя весь трафик на три других порта на одной машине.

Мы балансируем баланс на основе хэша IP-адреса клиента (ip_hash), поэтому, если клиент отключается и затем снова подключается, есть хороший шанс, что он будет подключен к тому же серверу Minecraft, на котором он был до. (Я не знаю, насколько это важно для Minecraft, или как клиенты с поддержкой SRV запрограммированы для решения этого аспекта.)

Обратите внимание, что мы использовали для запуска сервера Minecraft на порт 25565; Я переместил его на порт 25568, чтобы мы могли использовать порт 25565 для балансировки нагрузки.

Возможный недостаток метода Nginx заключается в том, что он делает Nginx узким местом в вашей системе. Если Nginx опустится, все три сервера станут недоступными. Если какая-то часть вашей системы не может идти в ногу с объемом трафика на этом единственном порту, 25565, все три сервера становятся flaky. И не говоря уже о том, что Nginx - это большая новая зависимость в вашей экосистеме. Возможно, вы не хотите вводить еще одну огромную часть программного обеспечения со сложным конфигурационным языком и огромной поверхностью атаки. Я могу это уважать.

Возможное преимущество метода Nginx заключается в том, что Nginx является узким местом в вашей системе! Вы можете применять глобальные политики через Nginx, например, отклонять пакеты выше определенного размера или отвечать статической веб-страницей на HTTP-соединения на порту 80. Вы также можете использовать брандмауэр с портами 25566, 25567 и 25568 из Интернета, так как теперь они следует говорить только Nginx по интерфейсу loopback. Это немного уменьшает вашу поверхность атаки.

Nginx также упрощает добавление новых серверов Minecraft в ваш сервер; теперь вы можете просто добавить строку server в свою конфигурацию и service nginx reload. Используя старый подход на основе портов, вам нужно будет добавить новую запись SRV с вашим провайдером DNS (и для клиентов может потребоваться до 86400 секунд, чтобы клиенты заметили это изменение), а затем также не забудьте отредактировать ваш брандмауэр (например, /etc/iptables.rules), чтобы разрешить внешний трафик через этот новый порт.

Nginx также освобождает вас от необходимости думать о DNS TTL при внесении изменений в ops. Предположим, вы решили разделить свои три сервера Minecraft на три разные физические машины с разными IP-адресами. Используя Nginx, вы можете сделать это полностью с помощью изменений конфигурации в строках server, и вы можете сохранить эти новые компьютеры в своем брандмауэре (подключен только к Nginx через частный интерфейс), и изменения вступят в силу немедленно, по определению. Принимая во внимание, что, используя записи SRV, вам придется переписать свой файл зоны на что-то вроде этого...

arboristal.com.                 86400 IN CNAME mc1.arboristal.com.
mc1.arboristal.com.             86400 IN A   <a new machine IP address>
mc2.arboristal.com.             86400 IN A   <a new machine IP address>
mc3.arboristal.com.             86400 IN A   <a new machine 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.

... и вам придется оставить все три новые машины, выстукивающие за пределами вашего брандмауэра, чтобы они могли получать подключения из Интернета. И вам придется подождать до 86400 секунд, чтобы ваши клиенты могли заметить изменения, которые могут повлиять на сложность плана развертывания. И если вы выполняли какие-либо другие службы (например, HTTP-сервер) на arboristal.com, теперь вы должны перенести их на машину mc1.arboristal.com из-за того, как я сделал это CNAME. Я сделал это только в интересах тех гипотетических клиентов Minecraft, которые не уважают записи SRV и все равно будут пытаться подключиться к arboristal.com:25565.

Итак, я думаю, что оба пути (SRV-записи и балансировка нагрузки Nginx) разумны, и ваш выбор будет зависеть от ваших личных предпочтений. Я карикатурирую варианты как:

• SRV-записи: "Мне просто нужно работать, я не хочу сложности. И я знаю и доверяю своему провайдеру DNS".
• Nginx: "Я предвижу arboristal.com захват мира или, по крайней мере, переход к более крупной машине когда-нибудь. Я не боюсь изучать новый инструмент. Какой файл зоны?"