Hi all,
We have a bunch of rootless containers running as a non-privileged
user on a Ubuntu 22.04 server under Podman 4.5.0.
One of them is running Browserless Chrome to render PDFs of the output
of a Django-served URL of another container.
The Django container is set up so that its CSS/JS/etc. static files
are stored on the host machine and served by the host's Nginx. To
correctly display the styles, Chrome therefore needs to access the
endpoint via the public URL of the site.
This is not working, because any connection attempts to the public IP
from within any of the running containers fail with a Connection
Refused error:
- - - -
$ curl -vvv
https://our.nice.site
* Trying <redacted IPv6>:443...
* connect to <redacted IPv6> port 443 failed: Connection refused
* Trying <redacted IPv4>:443...
* connect to <redacted IPv4> port 443 failed: Connection refused
* Failed to connect to our.nice.site port 443: Connection refused
* Closing connection 0
curl: (7) Failed to connect to our.nice.site port 443: Connection refused
- - - -
The host itself is, of course, able to access itself with the public
URL/IP just fine; this only occurs inside the containers. The
containers are also able to access any other public URL, just not the
one pointing to the host's own public IP.
We're using pasta networking. All containers are set up with quadlet.
Here's the Chrome container's quadlet generator:
- - - -
[Unit]
Description=Browserless Chrome
Wants=network-online.target
After=network-online.target
[Container]
Image=browserless/chrome:1.59.0-chrome-stable
ContainerName=browserless-chrome
Network=pasta:-t,auto,-T,auto
LogDriver=journald
[Install]
WantedBy=default.target
- - - -
All the other containers also use "Network=pasta:-t,auto,-T,auto". I
tried to add --map-gw to the command line, since it seemed possibly
relevant, but without success.
"Network=pasta:--map-gw,-t,auto,-T,auto" failed on container startup
with this error:
Error: failed to start pasta:
Port forwarding mode 'none' conflicts with previous mode
"Network=pasta:-t,auto,-T,auto,--map-gw" started the container fine,
but did not fix the Connection Refused error.
Finally, the contents of containers.conf:
- - - -
[containers]
log_driver="journald"
tz="local"
[network]
network_backend="netavark"
[engine]
runtime="crun"
- - - -
Is this a bug, a misconfiguration on my part, or an intentional
security feature of Podman networking and/or Podman with pasta,
specifically? Is there any way for the containers to access the
hosts's public IP? If not, we'll need to arrange some kind of awkward
static file serving container for use by the Chrome container, but
we'd really like to avoid that.
- JL
_______________________________________________
Podman mailing list -- podman(a)lists.podman.io
To unsubscribe send an email to podman-leave(a)lists.podman.io
Hi,
You are on the right track. By default pasta copies the host ip in the
container so both have the same ip address, therefore you cannot connect
to that ip because it is local to the container namespace.
With `--map-gw` pasta remaps the gateway ip to the host ip. So with
that option you have to connect to the gateway ip instead which pasta
then remaps to the actual host ns.
---
Paul