LINUX.ORG.RU

HTTPS внутри LXC контейнера

 , , ,


0

3

Я с некоторых пор полюбил LXC контейнеры и стараюсь отдельные задачи размещать в них. Если внутри контейнера есть веб-сервер, то я его обычно делаю на 80 порту, а на хостовой системе у меня стоит nginx, который выполняет роль прокси и в его конфиге стоит что-то вроде

proxy_pass http://10.0.3.4:80;
Дальше я с помощью certbot на хостовой системе получаю для этого конфига letsencrypt сертификат, и у меня сервис запускается по HTTPS и все нормально работает.
Но есть некоторые хитрые сервисы, которые требуют HTTPS прямо внутри контейнера. Если отказаться или сделать вышеописанным способом, это чревато неработоспособностью сервиса. Я могу конечно поставить certbot внутри контейнера, но как мне пробрасывать его на хостовую систему и через какой порт? Делать двойной SSL (и внутри и снаружи по letsencrypt) я уже пробовал. Браузер тогда ругается на бесконечные редиректы. А как по-другому пробросить 443-й порт из контейнера во внешку я не знаю. Помогите, пожалуйста.

★★★★★

Последнее исправление: Rinaldus (всего исправлений: 1)

Ответ на: комментарий от WitcherGeralt

Тебе не все ли равно? Например, peertube, который в мануале требует установленного HTTPS. Причем если я его поставлю откуда-то извне, я не уверен, что все ссылки будут корректно обрабатываться, особенно при заливке видео. Или например, YouPHPTube - по той же причине.
Мне нужно HTTPS внутри контейнера. Как мне пробросить его во внешку?

Rinaldus ★★★★★
() автор топика
Ответ на: комментарий от Rinaldus

Тебе не все ли равно?

А тебе жалко что ли? Просто интересуюсь.

Я бы попробовал внутри контейнера заюзать самоподписанный сертификат и заигнорить его проверку в nginx.

WitcherGeralt ★★
()
Ответ на: комментарий от Rinaldus

Может надо пробросить второму веб-серверу (тому который в контенере) информацию о том что конект пришёл по https? Или там сам сертификат нужен ещё зачем-то?

MrClon ★★★★★
()
Ответ на: комментарий от WitcherGeralt

Вообще-то не должно, трафик шифруется и расшифровывается первым веб-сервером (который не в контейнере)

MrClon ★★★★★
()
Ответ на: комментарий от WitcherGeralt

Я подозреваю что оно таки работает, но чтобы оно корректно работало по https ему надо объяснить что https офлоадится где-то в другом месте и запросы пришедшие к нему по http это на самом деле https запросы. Не думаю что оно пытается офлоадить ssl само, всё-таки ssl-offload на ноде это слишком упорото

MrClon ★★★★★
()

Решение:
- http://nginx.org/ru/docs/stream/ngx_stream_ssl_preread_module.html
Для существующих vhost-ов придётся делать проксирование внутри nginx на самого себя же + перевесить их на 127.0.0.1 или другой порт.
- продолжать делать letsencrypt-сертификаты в родительском nginx, а в контейнере использовать самоподписанный.

spirit ★★★★★
()

Поподробнее про cert bot, что ты там пробрасываешь? Разве он не сам запрашивает сертификат у летс энкрипт и, соответственно, сам должен открывать порт рандомный через NAT или что там в LXC? Ты же можешь пинговать из контейнера любые узлы, и они присылают ответ по icmp внутрь контейнера, значит, пакеты ходят и роутятся сами, без твоих рук. Так и твой бот должен работать. И ваще, можно бота пускать в хост системе, а сертификат, который бот получил, уже прокидыватл через фс внутрь контейнера и с этим сертификатом пускать в контейнере nginx, короче, я за https внутри контейнера, а получение сертификата https извне

menangen ★★★★★
()

как мне пробрасывать его на хостовую систему и через какой порт?

Я не понял, что мешает директорию с сертификатами (например от btrfs) примонтировать в две файловые системы - в файловую систему хоста и в файловую систему виртуалок.

Einstok_Fair ★★☆
()
Ответ на: комментарий от Einstok_Fair

Просто нет смысла. Проще юзать самоподписанный в контейнере.

WitcherGeralt ★★
()
Ответ на: комментарий от spirit

Это 2 варианта решения или последовательность действий для одного варианта?

Rinaldus ★★★★★
() автор топика

certbot — в контейнер, в nginx — что-то вроде:

stream {
	resolver 10.208.12.1;

	map $ssl_preread_server_name $name_ssl {
	    host1.com        host1com_ssl;
	    host2.com        host2com_ssl;
	}

	upstream host1com_ssl {
	    server host1.lxd:443;
	}

	upstream host2com_ssl {
	    server host2.lxd:443;
	}

	server {
	    listen      443 proxy_protocol;
	    listen      [::]:443 proxy_protocol;
	    proxy_pass  $name_ssl;
            proxy_protocol on;
            set_real_ip_from  127.0.0.0/8;
	    ssl_preread on;
	}

}

В веб-сервере внутри контейнера активировать proxy protocol (или убрать его из конфигурации внешнего веб-сервера, но тогда веб-сервер внутри контейнера будет думать, что все заходят с одного IP-адреса).

ValdikSS ★★★★★
()
Последнее исправление: ValdikSS (всего исправлений: 1)
Ответ на: комментарий от spirit

- продолжать делать letsencrypt-сертификаты в родительском nginx, а в контейнере использовать самоподписанный.

Получилось! Работает! Спасибо огромное! Я просто подсунул ему дефолтные апачевские сертификаты (в том контейнере просто Apache стоит, впрочем это неважно), и затем на хостовой системе в nginx пробросил таким образом:

proxy_pass https://10.0.3.7;
И все заработало без проблем. Расписываю это потому что вдруг кто еще будет мучиться и нагуглит эту тему.

Rinaldus ★★★★★
() автор топика
Последнее исправление: Rinaldus (всего исправлений: 2)
Ответ на: комментарий от vvn_black

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

Rinaldus ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.