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 також розміщує «хост» у місці рушія.

Схожі статті