Comments 23
network_mode: host
Есть ли хоть одна причина делать такое в docker-compose?
volumes:
- $PWD/cert/:/root/cert/
Если уж монтируете эту папку, то лучше, наверное, в readonly?
Я использовал базовый docker compose файл разработчика панели, в том виде в котором пользователь увидит его на github.
Больше скажу, я не использую докер в своих инсталляциях, я использую пользователей с ограниченным набором прав под каждый сервис, это сложнее и дольше в настройке, AdGuardHome например не желает обновляться встроенными механизмами.
Ну у разработчика два варианта запуска докера - просто через командную строку и через compose. В первом случае сеть явно не задаётся (и хорошо), однако, порты всё равно вешаются на все интерфейсы.
В вашем случае, вероятнее всего, нужно убрать `network_mode: host` и порт указать как 127.0.0.1:54321:54321
, поскольку вы его проксируете.
я использую пользователей с ограниченным набором прав под каждый сервис
Ммм.. Вообще-то докер примерно это же и делает, только ещё cgroups использует, чтобы ещё больше всех порезать.
Ммм.. Вообще-то докер примерно это же и делает, только ещё cgroups использует, чтобы ещё больше всех порезать.
Докер запущенный демоном от рута не является безопасным и побег из контейнера ни кто не отменял, тогда нужно использовать rootless инсталляцию, и уже тогда резать сеть, права на volume.
Acme так же выносить в отдельного пользователя, как в офф инструкции, добавлять его в группы haproxy, docker, ocserv для обновления сертификатов, раздавать права на директории где лежат сертификаты для того что бы acme мог обновить сертификаты, и права на перезапуск ocserv.
В вашем случае, вероятнее всего, нужно убрать `network_mode: host` и порт указать как
127.0.0.1:54321:54321
, поскольку вы его проксируете.
Порт в панели после меняется. 54321 только при первом запуске.
В целом это тоже самое если выбрать инсталляцию amnezia на сервер, вы даете приложению root доступ к серверу и пользуетесь готовым продуктом.
Докер запущенный демоном от рута не является безопасным и побег из контейнера ни кто не отменял
Подождите, это же две разные вещи. "Докер, запущенный демоном от рута" - это просто приложение на Go, которое только запускает процессы. Сами процессы - это нативные Linux-процессы, которым просто ставятся права штатными средствами. После запуска контейнера, теоретически, сам докер ему уже не нужен. В общем-то, вы можете запустить "контейнер" и без докера - на хабре были статьи на эту тему.
Побег из контейнера - это уже эксплуатация уязвимостей Linux. Нужно запускать приложения внутри под непривилегированным юзером, мапить его снаружи на что-то без прав и тп.
Вообще говоря, моё основное замечание было на запуск приложений на интерфейс 0:0:0:0 - поскольку вы их проксируете локально, то лучше порты мапить на 127.0.0.1, чтобы не было доступа снаружи (даже если файрволл вроде как это блокирует).
Простите, если я недопонимаю конечную цель, но не проще ли поднять PFSense как виртуальную машину, в которой уже есть Acme и HAProxy, как плагины с удобным UI для менеджмента?
А не могли бы вы в начале статьи указать точную версию дистрибутива операционки которую используете?
echo '' > /etc/haproxy/haproxy.cfg
Можно echo > /path/to/file
# Заблочим Африку, Азию, Южную Америку, Океанию, Европу и Северную Америку не блочим для запросов ACME
Опечатка, наверно?
Опечатка, наверно?
Нет, на f http блочим все кроме этих континентов. В f tcp уже да, отсекаем и америку оставив европу, на f https вообще можно отработать по белому списку
В целом так можно защититься от ботов с этих IP в этом смысл был и защитить сервис определённой локацией или подсетью
Возможно где-то это и имеет смысл. Выглядит все это странно.
Удалось запустить vless-ws за haproxy с терминацией, если не использовать vless-tcp-tls и ocserv можно обойтись одним доменом, скорость чуть ниже чем у wstunnel порядка 170мбит на загрузку. Позже дополню конфигурацию.
А если нужно запустить не просто vless, а REALITY ?
Reality не работает за прокси сервером, по крайней мере мне не удалось развернуть. Чем не устраивает вариант vless tcp tls с vision или vless ws tls? У меня есть мысли как завести reality на поддомене, но пока не проверю конфигурацию сообщить не чего.
Хочу ещё немного добавить вариант, для получения сертификата при помощи режима standalone, вместо ACCOUNT_THUMBPRINT
Делаем, например:
# LE Backend
backend letsencrypt-backend
mode http
server letsencrypt 127.0.0.1:8888
и используем
use_backend letsencrypt-backend if { path_beg -i /.well-known/acme-challenge/ }
acl letsencrypt-acl path_beg /.well-known/acme-challenge/
use_backend letsencrypt-backend if letsencrypt-acl
И выпускаем сертификат:
sslname=$(echo example.com); \
/root/.acme.sh/acme.sh \
--standalone --httpport 8888 \
--issue -d $sslname --force
--test
/root/.acme.sh/acme.sh --install-cert \
-d $sslname \
-d www.$sslname \
--keylength 2048 \
--key-file "/opt/haproxy/ssl/$sslname.key" \
--fullchain-file "/opt/haproxy/ssl/$sslname" \
--reloadcmd "chmod 666 /opt/haproxy/ssl/*; docker kill -s HUP haproxy;"
/root/.acme.sh/acme.sh --install-cert \
-d "$sslname" \
-d www.$sslname \
--keylength 2048 \
--reloadcmd "cat \$CERT_KEY_PATH \$CERT_FULLCHAIN_PATH > /opt/haproxy/ssl/$sslname; docker kill -s HUP haproxy;"
Вместо
docker kill -s HUP haproxy
так же можно использовать
systemctl restart haproxy
или
systemctl reload haproxy
Маршрутизируем трафик с помощью HAProxy, совмещаем сервисы на 443 порту