LINUX.ORG.RU

Помогите настроить cloudflare-warp в podman-е

 , , ,


1

3

Почти до конца дошёл, но не работает.

Вот мой контейнер:

from fedora:latest
copy cloudflare-release-el8/cloudflare.repo /etc/yum.repos.d/cloudflare.repo
copy cloudflare-release-el8/RPM-GPG-KEY-CLOUDFLARE-3 /etc/pki/rpm-gpg/RPM-GPG-KEY-CLOUDFLARE-3
run dnf -y upgrade && \
    dnf -y install cloudflare-warp passwd && \
    dnf clean all && \
    echo root | passwd --stdin root && \
    mkdir -p /root/.local/share/warp/ && \
    echo -n yes > /root/.local/share/warp/accepted-tos.txt
expose 40000
cmd ["/usr/sbin/init"]

В нём запускается systemd и запускает этот самый warp.

Вот так я его собираю:

podman build --tag warp --file Dockerfile --no-cache

вот так я его запускаю:

podman run --name warp \
       --interactive=true --tty=true --rm=true \
       --volume ./cloudflare-warp:/var/lib/cloudflare-warp:Z \
       --publish 40000:40000 \
       warp

всё без рута, не доверяю я всяким бинарникам.

Внутри зарегистрировался (warp-cli register), настроил прокси-режим и тд. В общем коннектит и по идее выставляет socks5 proxy на 127.0.0.1:40000. Внутри контейнера всё работает:

[root@e0d55b68c136 ~]# curl ifconfig.me
95.57.223.79

[root@e0d55b68c136 ~]# curl --socks5 127.0.0.1:40000 ifconfig.me
8.21.110.51

но вот снаружи контейнера ничего не работает:

$ curl --socks5 127.0.0.1:40000 ifconfig.me
curl: (97) Unable to receive initial SOCKS5 response.

$ curl --socks5 127.0.0.1:40001 ifconfig.me
curl: (7) Failed to connect to 127.0.0.1 port 40001: Connection refused

Видно, что при этом порт 40000 всё же отличается, например, от порта 40001, что-то на нём всё же принимает соединения.

Подозреваю, что дело в том, что warp-svc слушает именно 127.0.0.1, а не 0.0.0.0, но какой-то опции для конфигурации я не увидел. А может и не в этом дело.

★★★★★

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

Вроде получилось с таким костылём (запущенным внутри контейнера):

nc -l 0.0.0.0 40001 <fifo | nc 127.0.0.1 40000 >fifo

В общем эдакая tcp-прокся поверх всего. Видимо дело действительно в бинде на 127.0.0.1. Подкручу, работать наверное будет, но буду рад совету за менее костыльный вариант.

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

Вот мой контейнер

В нём запускается systemd и запускает этот самый warp

Ну фейспалм же. Это докер, а не LXD. Запускай процесс warp-а напрямую.

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

По дефолту в rootless контейнерах сеть обслуживает slirp4netns. Поэтому в контейнере cidr, по дефолту, 10.0.2.0/24.

Если эту вашу запрещенную службу нельзя заставить слушать другие адреса, то приведенный вами вариант – не менее костыльный, чем другие. Разве только 0.0.0.0 на 10.2.0.100 заменить имеет смысл.

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

Разве только 0.0.0.0 на 10.2.0.100 заменить имеет смысл.

Зачем? Контейнер не знает и не должен знать, на каких адресах он будет запущен. Сегодня по дефолту 10.0.2.0, завтра что-то другое, послезавтра ТС его от рута запустит.

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

Контейнер не знает

Когда запущен – знает. Можно не вписывать руками, можно автоматизировать.

Сегодня по дефолту 10.0.2.0, завтра что-то другое, послезавтра ТС его от рута запустит.

Согласен, это вкусовщина. Имхо лучше, чтобы в любой непонятной ситуации (запустили от рута) все ломалось, а не работало непредсказуемым или опасным образом.

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

Можно не вписывать руками, можно автоматизировать.

Тогда непонятен смысл всего упраженения. Вместо того, чтобы привязываться к 0.0.0.0, ты предлагаешь парсить список интерфейсов и привязываться к подсети, … чтобы что?

Имхо лучше, чтобы в любой непонятной ситуации (запустили от рута)

А где здесь «непонятная ситуация»? Контейнер на то и контейнер, чтобы в любом хостовом окружении и под любым рантаймом работать предсказуемо и одинаково.

а не работало непредсказуемым или опасным образом

Тот же вопрос.

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

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

В принципе я понял, что если процесс на 127.0.0.1 маппится, то тут ничего поделать нельзя, придётся tcp proxy оставить, чтобы соединения перекидывала.

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

Там другие строчки есть, которые я сходу не знаю, как эмулировать.

По-моему ты не тот вопрос обсуждаешь. Какая разница, что запускать - systemd или warp-svc, если в результате warp-svc запустится точно так же. Вопрос в том, как вытащить прибинденное к 127.0.0.1 соединение.

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

По-моему ты не тот вопрос обсуждаешь.

Совершенно точно — я обсуждаю тот вопрос, по которому мне есть что обсуждать :)

Я попробовал его попрепарировать, действительно, биндится к 127.0.0.1 и всё тут.

А вообще, знаешь что? Можно запилить перехват через LD_PRELOAD и подменить аргумент bind-у на 0.0.0.0. Как по мне, гораздо красивее, чем костыли с netcat.

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

Я попробовал его попрепарировать, действительно, биндится к 127.0.0.1 и всё тут.

Я так понимаю что если это будет деплоиться куда-то в более серьезное окружение, там надо sidecar-контейнер делать.

Ну то есть будет один под, в нем два контейнера. Первый слушает на 127.0.0.1, второй какой-нибудь lighttpd или не важно кто, который слушает всё и делает редирект на внутренний порт.

podman тоже умеет такими группами управлять

$ podman pod --help
Manage pods

Description:
  Pods are a group of one or more containers sharing the same network, pid and ipc namespaces.

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

Я боялся, что там статический бинарник, но да, по ходу можно:

sh-5.1# nm -C -D /bin/warp-svc  | grep bind
                 U bind@@GLIBC_2.2.5
intelfx ★★★★★
()
Ответ на: комментарий от alpha

Я так понимаю что если это будет деплоиться куда-то в более серьезное окружение, там надо sidecar-контейнер делать.

https://imgs.xkcd.com/comics/software_development_2x.png

Не нужно там никаких сайдкаров и прочей стрельбы из орбитальных пушек по воробьям. Там бинарник динамический.

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

Не нужно там никаких сайдкаров и прочей стрельбы из орбитальных пушек по воробьям. Там бинарник динамический.

Обычно sidecar - это не просто тупая прокси. Например она авторизацию может тянуть, или https, или какие-то дополнительные фильтры.

Если сервис by design сидит на 127.0.0.1 - это означает что он не предназначен смотреть в «большую» сеть. Выставлять его туда может быть небезопасно.

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

ТС хочет запустить его в контейнере и пробросить порт на локалхост (никуда дальше он не пойдёт, т. к. --publish подразумевает 127.0.0.1 по дефолту). В результате он хочет (и получит) полный эквивалент бинарника, запущенного локально на хосте. Зачем искать проблемы там, где их нет?

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

Пусть тогда вообще поставит --network=host и успокоится. Про безопасность у него все равно ничего нет.

Но я не вижу никаких проблем с первоначальным решением.

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

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

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

Ну так «я обсуждаю тот вопрос, по которому мне есть что обсуждать» :)

Если задача локальная и ТС знает как именно запилить перехват через LD_PRELOAD и подменить аргумент bind-у на 0.0.0.0 то да, можно. Лично мне опцию с проксей проще было бы реализовать и поддерживать.

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

Про «не доверяю бинарникам» - я не то, чтобы не доверяю, в том плане, что боюсь каких-то направленных атак. Скорей я не доверяю в том плане, что не думаю, что они грамотно сделаны в плане интеграции в дистрибутив. Например я сходу вижу, что postinstall скрипт делает enable и start этому сервису. В Red Hat так не принято. То бишь уже видно, что опакечивали на скорую руку. Я сходу вижу, что вместо того, чтобы сразу устанавливать unit-файл куда положено, они сначала ставят его в /opt и потом в postinstall-скрипте копируют в /etc. То бишь что-то они странное делают. Я, например, не хочу доверять этому бинарнику установку правил фаервола, а он их явно захочет менять под себя.

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

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

Я им пользовался, он у меня плохо работает. Через раз не идёт трафик по этому конфигу. Не знаю, почему, просто делаю wg-quick up и не идёт. Опускаю-поднимаю, работает. При этом на венде на соседнем компьютере всё работает как часы в 100% времени.

Ну и подход с socks5 прокси мне больше нравится.

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

Ну и подход с socks5 прокси мне больше нравится.

Не поверишь, по запросу wireguard as sock5 гуглится несколько вариантов. Остальное комментировать не буду.

anonymous
()

Отпишусь, вдруг кому в голову придёт таким же заняться. Вот скрипт-инструкция, подробней расписывать не буду, думаю и так всё понятно. Прокидывается socks порт 40001, на него настраивать прокси в нужных программах.

podman run --detach --publish=127.0.0.1:40001:40001 --name cloudflare-warp ubi8-init
podman exec --interactive --tty cloudflare-warp bash
 dnf install http://pkg.cloudflareclient.com/cloudflare-release-el8.rpm
 mkdir "/etc/systemd/system/warp-svc.service.d/"
 cat > "/etc/systemd/system/warp-svc.service.d/disable-capabilities.conf" <<'eof'
[Service]
CapabilityBoundingSet=
AmbientCapabilities=
eof
 dnf install cloudflare-warp
 warp-cli set-mode proxy
 warp-cli register
 warp-cli enable-always-on
 dnf install socat
 cat > "/etc/systemd/system/socat.service" <<'eof'
[Unit]
Description=Socat TCP proxy service
After=warp-svc.service
Requires=warp-svc.service

[Service]
Type=exec
ExecStart=/usr/bin/socat TCP4-LISTEN:40001,fork TCP4:127.0.0.1:40000

[Install]
WantedBy=multi-user.target
eof
 systemctl daemon-reload
 systemctl enable socat.service

podman container stop cloudflare-warp
podman container start cloudflare-warp
Legioner ★★★★★
() автор топика
Последнее исправление: Legioner (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.