Контейнер с Caddy не имеет доступа в сеть на OpenWrt

[bam80]

Привет, это не связано с mtg,
но всё же прошу помощи здесь, может быть Вы Алексей сможете подсказать, у меня я чувствую не хватает опыта в настройке контейнеров/брандмауэра @dolonet.

В инструкциях для OpenWrt предлагается отключить правила маршрутизации встроенные в podman's/netavark's, вместо этого используя собственную настройку брандмауэра в OpenWrt:

We do this to rather use openwrt's own firewall, as when using podman's/netavark's, rules are lost every time that firewall is re-loaded, including when you start your first container network, when podman0 interface comes up.

Be aware that this means you must manually configure a NAT rule on the firewall when you want to expose a port from a container, as podman will not do that for you!

https://openwrt.org/docs/guide-user/virtualization/docker_host?s%5B%5D=podman#firewallzone
https://openwrt.org/docs/guide-user/virtualization/podman#networking_setup

Это похоже работает для голого podman, который может использовать заранее созданный статически podman0 интерфейс. Если правила маршрутизации настроены для этого интерфейса верно, то в результате контейнер имеет доступ к сети.
Проблема возникает с podman-compose - как я вижу, каждый раз при запуске podman-compose up создается временная внутренняя сеть для контейнеров, и если podman0 интерфейс уже существует, то создается новый - podman1.
Для этого интерфейса мы никаких правил заранее создать не можем (или я не знаю как это сделать), в результате контейнер не имеет доступа в сеть:
https://forum.openwrt.org/t/podman-compose-dontt-have-network-access/250230

Заставить podman-compose использовать статический заранее сконфигурированный podman0 интерфейс - я тоже не знаю как.
На этом идеи у меня закончились, единственный выход видится в использовании host-сети везде, но этого хотелось бы избежать.

Буду благодарен за любую помощь, спасибо.

[bam80]

С помощью сообщества, найдено целых два решения данной проблемы - одно с изменением compose-файла, другое без.
Подробности смотрите по ссылке на форум выше.

Если кому-то есть что добавить, это приветствуется.
Спасибо за внимание.

[dolonet]

Привет @bam80, спасибо что нашёл и зафиксировал решения. Пара дополнений на пользу будущим читателям:

Почему вообще появляется podman1. podman-compose следует Compose-spec: up создаёт project-scoped сеть <project>_default, и netavark под каждую такую сеть поднимает отдельный bridge (podman1, podman2, …). OpenWrt firewall зонирован по имени интерфейса, под новый bridge правил нет — отсюда no network.

Solution 1 — чуть надёжнее форма. Лучше явно external, чтобы compose никогда не пытался создавать/перестраивать router-managed podman0:

networks:
  default:
    external: true
    name: podman

С name: podman без external compose обычно adopt'ит существующую сеть, но если в YAML появится ipam/driver и они разойдутся с тем, что завёл /etc/init.d/podman, прилетит "network already exists but with different settings". external: true снимает этот класс ошибок и явно фиксирует намерение «не трогать router-managed сеть».

Solution 2 рабочий, но индекс bridge'а не стабилен: добавишь второй compose-проект — netavark выдаст podman2, и снова править covered devices. Solution 1 — scaling-safe.

Поскольку ты деплоишь наш contrib/sni-router, добавлю в его README короткий раздел про OpenWrt+podman-compose со ссылкой сюда — PR подготовлю.

[bam80]

Solution 2 рабочий, но индекс bridge'а не стабилен: добавишь второй compose-проект — netavark выдаст podman2, и снова править covered devices.

Ну интерфейсов можно добавить впрок сколько надо,
но есть ещё 3й вариант - добавить в зону всю подсеть:

Мне это не нужно было, не пробовал.

[bam80]

Поскольку ты деплоишь наш contrib/sni-router, добавлю в его README короткий раздел про OpenWrt+podman-compose со ссылкой сюда — PR подготовлю.

Это тоже хорошо, спасибо, но я думаю это больше к OpenWrt Wiki относится - ссылки выше.
В идеале добавить туда, а здесь можно дать ссылку.

[bam80]

Solution 1 — чуть надёжнее форма. Лучше явно external,

Solution 1 — scaling-safe.

Это получается только для podman-compose, для docker-compose возможно тоже что-то подобное пришлось бы?
Тогда уж лучше 3-й вариант выше.

PS:
Или называть сети одинаково в обоих случаях.

[dolonet]

Спасибо за пуш-бек, по пунктам:

1. Подсеть в зону — да, тоже scaling-safe и compose-агностично. Чуть шире trust-зона: туда попадёт любой будущий контейнер, не только нужные. Если хочется изоляции между проектами — можно нарезать подсети.

2. Согласен, OpenWrt-specific firewall больше к их wiki относится. README в sni-router не трогаю — пусть эта discussion будет точкой входа.

3. Для docker-compose принцип тот же (Compose-spec общий): external: true + ссылка на pre-existing network работает идентично, имя сети только своё. Одинаковое имя в YAML тоже сработает, но external: true явно сообщает «не моё, не трогать» — мне нравится больше за это.

[bam80]

Спасибо ещё раз за дополнения и поддержку Алексей.

Я так понимаю универсального решения с external: true всё равно нет, ведь имя существующей сети разное для docker и podman.
Интересно, насколько вероятно встретить данную проблему где-нибудь ещё, например в облаке.

Если больше обсуждать тут нечего, дискуссию думаю можно закрывать.

[dolonet]

Про docker vs podman имя сети — формально да, разное (bridge vs podman), но это не блокирует «универсальный» подход: external: true + name через env-переменную (${NETWORK_NAME:-podman}) даёт один YAML под оба runtime'а. Чаще проще держать deployment либо docker-only, либо podman-only, чем городить overrides.

Насчёт «где ещё встретишь» — в обычном cloud (stock Docker на AWS/GCP/Azure VM) почти не встретишь: Docker там сам владеет своими iptables-chains, и никакой внешний firewall manager их на reload не сносит. Эта боль специфична для host'ов, где firewall управляется централизованно, а container runtime по policy лишён права рулить iptables. OpenWrt — самый видимый случай. Сюда же:

• dockerd --iptables=false — серверы под корпоративной firewall-policy, где iptables/nftables рулится централизованно (ansible/salt и т.п.)
• edge/embedded — роутеры с container support и собственным host firewall

Класс — «firewall manager и container runtime делят iptables-ответственность». Cloud в обычном смысле в этот класс не попадает.

Закрывать можно, спасибо что довёл нить до итога — survey будет полезен следующим столкнувшимся.

[bam80]

external: true + name через env-переменную (${NETWORK_NAME:-podman}) даёт один YAML под оба runtime'а.

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

[dolonet]

Согласен — для встройки в compose аудитория слишком узкая, не вижу смысла городить. Спасибо что довёл нить до итога, пусть остаётся точкой входа для следующих. Закрываю.