Маршрутизация доменов третьего уровня во внутренние IP адреса

Question

[heruvim]

Как можно реализовать нечто подобное:



желательно с помощью стандартных системных утилит и устойчиво к большим нагрузкам

Answer 1

[Veshij]

То что вам нужно — это не маршрутизация, а проксирование.
Все А-записи указывают на 172.23.45.34, а далее веб-сервер на этой машине в зависимости от заголовка Host проксирует запрос на один из бекендов. Настраивается штатными средствами в любом современном веб-сервере.

Comments

[Naps]

А если не веб приложение?

[Veshij]

Если это просто произвольное приложение (например — БД), то на стороне сервера в не можете узнать на какое из DNS-имен пришел запрос, так как все преобразование имен в адреса будет происходить на клиенте.
Как вариант — выкупить у хостера несколько ip-адресов и проксировать на уровне tcp/ip запросы от внешних клиентов на бекенды.

[heruvim]

хороший коммент про произвольное приложение. про проксирование на уровне tcp/ip очень интересно, опишите пожалуйста детальнее принципы работы и софт который нужен

[Veshij]

Дальше все уже платформо- и админо-зависимо.
Это можно сделать как на уровне сетевого экрана (iptables/pf), так и на уровне какого-либо проксирующего приложения, к примеру — haproxy.
iptables -t nat -A PREROUTING -p tcp -m tcp --d 1.2.3.4 --dport 1234 -j DNAT --to-destination 10.0.0.1:1234
iptables -t nat -A PREROUTING -p tcp -m tcp --d 1.2.3.5 --dport 1234 -j DNAT --to-destination 10.0.0.2:1234

Написал по памяти, может не заработать.

[Veshij]

--d = -d

[heruvim]

приведенный пример — никак не связан с доменами

[Veshij]

ну конечно же 1.2.3.4 и 1.2.3.5 это ваши внешние адреса, на которые ссылается app1.domain.com и app2.domain.com. А 10.0.0.1 и 10.0.0.2 — это адреса бекендов, на которые должны быть переадресованы ответы, приходящие на 1.2.3.4 и 1.2.3.5 соответственно.

Answer 2

[lesha_penguin]

Если для Веб-приложений, то один из лучших вариантов — можно использовать nginx на шлюзе со следующей конфигурацией:
server{
listen 80;
server_name app1.domain.com;
location / {
proxy_pass 10.0.0.1:80;
proxy_set_header Host $http_host;
}
}
server{
listen 80;
server_name app2.domain.com;
location / {
proxy_pass 10.0.0.2:80;
proxy_set_header Host $http_host;
}
}
server{
listen 80;
server_name app3.domain.com;
location / {
proxy_pass 10.0.0.3:80;
proxy_set_header Host $http_host;
}
}


Плюсы:
+ Если Вы ВДРУГ захотите перенести приложение например app1 например на хостинг, то проблем не будет, это можно будет сделать прозрачно.
+ Вы полностью отвязанны от физического размещения
+ Если вдруг одно из приложений будет слишком нагруженным, вы сможете его запускать на нескольких машинах и использовать балансировку, Кеширование, да и прочие вкусности nginxа.

Минусы:
— Все вышесказанное только для http

Answer 3

[lesha_penguin]

Дополнение: Кстати, вышеуказанный метод с nginx-ом вовсе не конфликтует с указанным выше DNATом через iptables. Легко настроить dnat чтобы он пробрасывал 80 порт внутрь локальной сети на вход nginx-у.

Answer 4

[nur]

Создаете поддомен, в его A запись указываете свои внутренний ип (хоть локалхост) и все. Через любую панель управления хостингом возможно

Comments

[nur]

Понял что Вам не это требовалось.

[heruvim]

бред, вчитайтесь вопрос еще раз.

Answer 5

[Владимир Чернышев]

Принцип работы простой — берёте у хостера ещё 3 внешних IP для хоста domain.com, прописываете их в A записях поддоменов и с них трафик (весь, или определенного протокола/портов) пускаете на внутренние хосты. Но, по-моему, смысл это имеет только если вам нужно чтобы доступа к внутренним хостам извне гарантированно не было кроме явно разрешенного и готовы ради этого пренебречь надёжностью: ляжет domain.com — лягут и поддомены. Проще, по-моему, не заморачиваться с единой точкой входа и каждому дать внешний адрес, если у вас нет балансировки и прочего.

Comments

[heruvim]

если у меня будет 1000 приложений (поддоменов) — мне нужно 1000 IP, смысл как раз в том чтобы имея один IP маршрутизировать тучу поддоменов на внутренние IP.

[Veshij]

если у вас 1000 приложений, то эта задача просто должна быть решена иначе. Все очень сильно зависит от того, что дожно отвечать на app$.domain.com, от этого будет зависеть реализация.
На самом деле имея описание можно было бы подсказать более детально.

[Владимир Чернышев]

Правильно сказал Veshij — реализация зависит от приложения. Если это, например, веб-сервис, то маршрутизация по заголовку Host HTTP 1.1. Если, скажем, СУБД, то разнесением БД разных приложений на разные хосты средствами СУБД. Если своё какое-то приложение, то можно решить задачу введением заголовка запроса, аналогичного Host в HTTP и, опять-таки, через размещение на «главном» сервере «прокси», берущего на себя анализ запроса и перенаправляющего его по адресу. Если протокол приложения аналогичен HTTP (то есть запрос-ответ без постоянных соединений), то можно решить задачу анализом входящих пакетов на уровне iptables, если же «диалоговый» и без маркера хоста в каждом запросе (как у MySQL, например), то без специализированного прокси, который будет знать о протоколе приложения, не обойтись в общем случае, насколько я знаю. TCP/IP+DNS не позволяют решить эту задачу по своей природе, в обмене данными между клиентом и сервером DNS-имён в общём случае нет, только если клиент знает, что ему нужно его передать, а сервер знает как его обработать, то есть речь о протоколе уровнем выше, чем TCP/IP.

Может в вашем случае лучше использовать балансировку запросов/нагрузки? То есть внутренние хосты идентичны и обслуживают все 3 (или 1000) поддоменов, а внешний перенаправляет по очереди или по текущей загрузке. Но опять-таки это подойдёт только для протоколов, у которых каждый запрос не зависит от предыдущего (нет «сессий», грубо говоря) или как-то решать вопрос о репликации и/или расшаривании состояния «сессии» между внутренними хостами — например хранить данные о сессии на 4-м хосте, где крутится memcache.

Answer 6

[xaker1]

Для вашей задачи если приемлемо разные порты использовать — то лучше именно по портам проксировать. Хотя все зависит от того, какого рода приложение. Для http — по заголовкам, ftp — никак (с одним ip).
Если протокол вашего приложения передает домен, то по нему.

Answer 7

[mark_ablov]

как бы обращение идёт по ip к вашему серверу, и если протокол не предусматривает передачу имени хоста, то никак нельзя определить куда хочет податься клиент. HTTP передаёт DNS-имя в своём заголовке.
Если всё же нужна маршрутизация своего протокола, то думаю лучше либо его обернуть в HTTP, либо написать модуль для прокси, hoproxy, например.