Podman pasta: доступ к loopback-прокси хоста из контейнера без root

Используйте TCP-переадресацию pasta из namespace на хост для существующего loopback-прокси и отличайте её от публикации порта контейнера.

127.0.0.1:8118 хоста и 127.0.0.1:8118 контейнера обычно являются раздельными конечными точками loopback. Передача переменной прокси в контейнер без root не объединяет эти loopback-интерфейсы.

При развёртывании Podman с pasta его TCP-переадресация из namespace на хост может открыть нужный порт хоста внутри namespace:

podman run --network=pasta:-T,8118 \
  --env http_proxy=http://127.0.0.1:8118 \
  --env https_proxy=http://127.0.0.1:8118 \
  existing-image application-command

Используйте существующий образ и команду приложения. Пример предполагает работающий HTTP-прокси на стороне хоста на порту 8118 и версию Podman/pasta, поддерживающую показанную опцию переадресации.

Заглавная -T в pasta переадресует из целевого namespace в namespace хоста. Строчная -t и --publish в Podman действуют в обратном направлении. Поэтому публикация порта контейнера 8118 сама по себе не делает прокси хоста доступным контейнеру.

Podman по умолчанию отключает автоматическую переадресацию портов из namespace на хост; явный порт выбирает нужную здесь службу. Отдельная опция pasta:--map-gw касается доступа к хосту через адрес шлюза, что является другой схемой.

При использовании Compose проверяйте фактического провайдера и созданную конфигурацию сети. Именованная bridge-сеть не становится автоматически namespace pasta только потому, что независимая команда podman run успешно использовала pasta. Удалённый движок Podman также размещает «хост» в местоположении движка.

Похожие статьи