Как реализовать внешний веб-доступ по одному IP на разные серверы?
Здравствуйте.
Дано: белый IP, за роутером прячутся три сервера, к которым нужен доступ через браузер, через https. 1) Сервер А. На нём крутится веб-приложение, прикручен домен domain.example, сертификат коммерческий, работает на очень специфической специально заточенной версии nginx, настраивать практически нечего. При этом, используются нестандартные порты вместо 80 и 443, т.е. доступ вида domain.example:1234 работает, но сертификаты от LE не получить, т.к. для этого требуется открытый 80 и 443 порты, поэтому сертификат куплен 2) Сервер Б. На нём другое веб-приложение, прикручен субдомен от домена Сервера А - second.domain.example. Сертификат от Letsencrypt, т.к. Wildcard нет и не будет. Работает на Apache, опять же заточенном, т.е. править тоже нечего 3) Сервер В. Тоже веб-приложение, субдомен third.domain.example, сертификат LE, стандартный Apache.
И вот нужно доступ ко всему этому зоопарку организовать через один IP. Нужен прокси, в его качестве использовать виртуалку одного из серверов (желательно) либо ставить отдельную железку (нежелательно). При этом, сертификаты должны оставаться на самих серверах, а не находиться на прокси, и нужно умение пробрасывать нестандартные порты на стандартные (Сервер А). Вот и вопрос - какой софт использовать для проксирования? Мне известны три варианта - Apache с mod_proxy, но он требует нахождения сертификатов на самом прокси, с соответствующей настройкой виртуальных хостов. Nginx c proxy_pass? - но, честно говоря, я так и не понял - умеет ли он всё это. То, что на прокси с nginx можно настроить получение сертификатов от LE и потом их "раздавать" на нужные серверы, я знаю, но это не то что нужно. Нашёл ещё haproxy. Чуть вены вчера себе не перегрыз пока настраивал. В чём прикол - так и не понял. Вроде бы, работает как задуманно, но периодически то один то другой серверы становятся недоступны, либо отдельные страницы. И ещё, насколько я понял, это больше балансировщик чем прокси. Или нет?
на очень специфической специально заточенной версии nginx
В чём заключается эта специфичность?
используются нестандартные порты вместо 80 и 443, т.е. доступ вида domain.example:1234 работает, но сертификаты от LE не получить, т.к. для этого требуется открытый 80 и 443 порты
Используйте webroot-авторизацию, в этом случае всё равно, какие у вас там внутри порты.
сертификаты должны оставаться на самих серверах, а не находиться на прокси
Это требование исходя из чего?
По сути вопроса - да, nginx всё это умеет, proxy_pass настраивается буквально тремя строчками даже в таком экзотическом варианте, как HTTPS -> HTTPS на кастомный порт. Другое дело, что так никто не делает по понятным причинам. Как раз наоборот - делают единый (ну или отдельный для каждого приложения) https-гейт с nginx`ом, на котором, собственно, и терминируется HTTPS, устанавливается сервис для получения-обновления сертификатов от LE, а внутрь пробрасывается нешифрованный HTTP.
Сервер А. Ноль доступных настроек, переадресация на https (порты, опять же, нестандартные) включена по умолчанию. Наличие сертификатов на самом сервере обязательно, хотя бы и самоподписанных. Т.е. если ставим nginx на прокси и потом с него отправляем нешифрованный трафик по пути прокси -> Сервер А, то он всё равно будет шифрованным.
Сервер Б. Https отключить можно, но в этом случае приложение начинает ругаться матом и отказывается работать правильно. Во многом, ограничения похожи на ограничения Сервера А, т.е. такое впечатление, что возможность работы через прокси с его сертификатами не особо предусмотрена.
Сервер В. Ну тут, в принципе, всё просто, можно сделать как угодно, но если первые два проксировать, то его тоже за компанию.
Другое дело, что так никто не делает по понятным причинам.
А можно намекнуть на эти причины? Просто я не сталкивался с похожими задачами и про best practice не в курсе.
внутрь пробрасывается нешифрованный HTTP
А и Б этого не любят(
делают единый (ну или отдельный для каждого приложения) https-гейт с nginx`ом, на котором, собственно, и терминируется HTTPS, устанавливается сервис для получения-обновления сертификатов от LE, а внутрь пробрасывается нешифрованный HTTP.
Это я понимаю, но в данном случае прокси нужен, не знаю как объяснить, самый прозрачный, который просто рулит потоками трафика в зависимости от того какой домен у него запросят, и знать не знает про то какой там трафик - шифрованный или нет, и про сертификаты тоже ничего ему не должно быть известно.
Кстати! Роутер - Микротик, можно ли как-нибудь его сделать прокси для моей задачи, вопрос.
Относительно причин, почему внутри не используют HTTPS - это как минимум оверхед по ресурсам и более сложная диагностика, если, например, нужно что-нибудь выловить в дампе трафика.
В вашем случае я бы оставил внутри сертификаты как есть, nginx`у в режиме проскирования всё равно, что внутри - валидный ли сертификат, самоподписанный или просроченный. Основная цель единого гейта - удобство последующего обслуживания (все конфиги и логи в одном месте, гейт можно легко мигрировать на другую виртуалочную ноду и т.д.) и единообразие получения сертификатов.
ky0,
> Относительно причин, почему внутри не используют HTTPS
На самом деле используют.
Зависит от задач.
Вариант 1. Если у вас есть внутренняя сеть изолированная. Никто, кроме ваших серверов, имеющих непосредственное отношение к проекту, эту сеть не видит и проект не шибко большой и не шибко серьезный - то https не обязателен.
Вариант 2. Если у вас есть внутренняя сеть изолированная. Никто, кроме ваших серверов, имеющих непосредственное отношение к проекту, эту сеть не видит. При этом над проектом работают 10 разработчиков. Проект прокачивает деньги. И непонятно какой из разработчиков решит подзаработать. https нужен.
Вариант 3. Если у вас есть внутренняя сеть, в которой присутствуют машины, не имеющие отношения к проекту, то https нужен.
Вариант 4. Если у вас есть внутренняя сеть, в которой присутствуют машины, не имеющие отношения к проекту, но на это в целом наплевать, так как вы уверены, что никакие хакеры на этих машинах никогда не появятся или проекту нечего скрывать - https не нужен.
Вариант 5. Вы организовали взаимодействие между своими серверами по открытому каналу - https нужен.
это как минимум оверхед по ресурсам и более сложная диагностика, если, например, нужно что-нибудь выловить в дампе трафика.
Оверхед самый большой на "рукопожатии". при постоянном коннекте все не так страшно.
Диагностику проводим ближе к конечной точке, там где уже трафик расшифрован.
Сложный
Средний
Простой
