Два физических сервера с разными доменами за mikrotik?

Question

[Сергей Быданов]

Добрый день
За одним белым адресом стоят два веб-сервера с разными доменами и поддержкой https на двух физических серверах. Надо чтобы в зависимости от домена запрос уходил на нужный сервер. Я знаю, что подобное можно сделать средствами nginx, но в этом случае один сервер становится ведущим, а второй ведомым. Можно ли средствами микротик сделать то же самое?

Answer 1

[Sanes]

Это задача web-сервера. В роутерах такого нет.

Comments

[Sasha Odarchuk]

ну так у него есть проброс по 80/443 порту на роутере и в зависимоти от домена в УРЛе надо "форвардить" клиента либо на сайт А либо на сайт Б.

[Sanes]

Sasha Odarchuk, он так не хочет.

Answer 2

[ky0]

Очень популярный на Тостере вопрос, проистекающий из изначально неверной архитектуры.

Вы говорите "один сервер ведущий, второй - ведомый", но правильно было бы сделать один (ну или несколько - для балансировки) сервер, проксирующий запросы и отвечающий за HTTPS-взаимодействие и выпуск сертификатов, и несколько - для отдельных доменов/сайтов. Такая схема (в особенности - в сочетании с виртуализацией) гранулирует сервисы и делает инфраструктуру более гибкой и проще администрируемой.

Comments

[Сергей Быданов]

Не спорю, что так будет лучше. Но сейчас это два небольших пет-проекта, мой и моего друга. Соответственно, каждый из нас занимается своим сервером. Никому не хочется зависеть от другого, но и ставить отдельный сервер для этого как-то слишком.

[ky0]

Сергей Быданов, именно поэтому я и говорю про виртуализацию - никаких отдельных серверов, никто от кого не зависит. Или у вас такие пет-проекты, что им обязателен отдельный железный сервер?

[Сергей Быданов]

Не обязателен, но это совершенно разные проекты. И два железных сервера в один без магии не объединишь и виртуализацию там не сделаешь. Да и в случае "развода" один сервер пополам не распилишь. Словом, для проверки жизнеспособности идеи нет смысла усложнять и делать все по "взрослому".

[Sanes]

Сергей Быданов, вы идею в кладовке собираетесь тестировать?

[Сергей Быданов]

Sanes, почему нет?

[Sanes]

Сергей Быданов, сомнительная идея.

[Сергей Быданов]

Sanes, почему? Поскольку SLA в условиях теста не нужен, то такой вариант выглядит лучше, чем арендовать у хостера vds за 300-400р и больше (умножьте еще и на два) в месяц и сталкиваться с ограничениями по памяти, дисковым пространством и созданием бекапов. Если идея окажется рабочей, то можно будет предположить ресурсоемкость. А если нет, то кроме расходов на домен она ничего и не стоила.

[Sanes]

Сергей Быданов,
да дело не в SLA, а в нормальной работе сервиса. Вы же не будете на продажу показывать грязную машину.

[Сергей Быданов]

А кто собирается продавать неубитого медведя? Проверка идеи - это проверка идеи. На коленке, в кладовке, из того что есть под рукой делается прототип, чтобы понять что это вообще возможно сделать. Нет смысла на этом этапе вкладываться в оборудование или хостинг. Потому что пока это всего лишь идея, то все может измениться не один раз, а для полноценной реализации может и вовсе не дойти. Если идея заработает, то можно попытаться ее "продать" потребителям. И если такие найдутся, то уже тогда искать хостинг, дизайнера для сайта и.т.д.
Поэтому да, единственный в офисе провайдер, микротик, два неттопа и немного периферии.

Answer 3

[Дмитрий]

Роутеры таким не занимаются. Или ставьте балансировщик или просите второй адрес у вашего провайдера.

Answer 4

[Alexey Dmitriev]

Да можно это устроить-если сможете запустить любое приложение, которое это умеет - например nginx - через любую систему виртуализации из доступных в вашем Mikrotik https://wiki.mikrotik.com/wiki/Manual:Virtualization
Например - через Metarouter установить и запустить openwrt, который имеет на борту nginx.

Без подобных вещей нельзя - как уже сказали выше Mikrotik не работает c прикладным уровнем OCI

Comments

[Сергей Быданов]

Не знаю, откуда у многих такая уверенность, что не умеет. Микротик имеет в своем составе IP → Web Proxy и для http это видимо работает, а это прикладной уровень.
Можно ли вывернуть этот прокси обратно и настроить его для https - вот что мне интересно.

[Alexey Dmitriev]

Сергей Быданов, здесь вы правы.

Answer 5

[MaxKozlov]

Теоретически можно попробовать через Layer7+DSTNAT, но я б не стал :)
проще уж слой nginx на собственном проекте для себя и друга

Answer 6

[АртемЪ]

Можно ли средствами микротик сделать то же самое?

Разумеется.
Поднимаете на микротике Nginx настраиваете его в режиме реверс прокси и все.

Answer 7

[Keffer]

А просто получить от прова (или другим путем) второй белый айпишник на микрот, не судьба? И не городить огороды.

Comments

[Сергей Быданов]

По-моему, ваш вариант ничуть не меньший "огород". Как минимум не проще в реализации и еще и предполагает дополнительные расходы.