![](/static/66c60d9f/assets/icons/icon-96x96.png)
![](https://lemmy.world/pictrs/image/8286e071-7449-4413-a084-1eb5242e2cf4.png)
Maybe take a look into Cloudflare Tunnels, which sounds like will do what you want (maybe not VPN though).
The short version is you run a daemon on your local network that Cloudflare talks to. So, outside requests only see Cloudflare, and communication from your network only goes to Cloudflare. Your IP is not exposed to consumers. This is free! Though you are not supposed to send video/pictures though the tunnel and have them cache it without using one of their (paid) services, but it’s simple to disable caching for a host. I do use their DNS, though I cannot recall if that’s a requirement for Tunnels, though.
Keep in mind you should still set up some sort of firewall, as people can and do just scan the entire IPv4 address range looking for open ports.
This is a consequence of user namespaces, which tripped me up until I read this article from Red Hat about running rootless containers as a non-root user. At that point I got that (the default options) map UID 0 in the container to my UID (i.e. 1000), but the other mappings were confusing.
The short version of the useful part (for me) of that article was
podman unshare
(man podman-unshare
), which launches a shell in a user namespace, like when you start a container. You can run the following command to see how the UIDs are mapped inside of the namespace:$ podman unshare cat /proc/self/uid_map 0 1000 1 1 100000 65536
This is read (for this purpose, see
man user_namespaces
for a more detailed explanation of this) as “inside this namespace, the UIDs in column 1 map to the UID in column 2 on the caller process, for (column 3) IDs”. There is alsogid_map
which works the same way, but for groups.The snippet above is from my machine, so in a podman container, UID 0 maps to UID 1000 on the “host”, which is me, and this is “good” for only 1 user. Then, starting with UID 1, the container maps to UID 100000 in the container, and is good for 65536 UIDs. This is why when you set the
PUID
andGUID
environment variables, on your filesystem you see the files are owned by100999:100999
- you can use the mapping to figure the math out:100000+1000-1=100999
.Since
podman unshare
puts you in a shell that has the same (? terminology might not be totally right here) user namesapce as your containers, you can use it for lots of stuff – like in your comment you mentioned usingchown
to change the permissions to100999:100999
. Instead, you could have usedpodman unshare chown 1000:1000
which have correctly set the permissions for your volume mount, and on your filesystem outside the container, the permissions would be100999:100999
.