使用 portmap 转发 Rootless Podman 的低位端口
内容提要
作者因Docker Desktop订阅条款复杂，改用Rootless Podman，但发布低位端口（如80）时因权限失败。为此开发了portmap工具，通过转发高位端口至标准端口解决，支持TCP/UDP，可用systemd管理。文章详述了配置、权限处理、性能测试及适用场景，强调工具简单、不替代复杂网关，适合个人开发环境。
延伸解读
权限边界：理解 Rootless Podman 的低位端口限制
Rootless Podman 不依赖高权限守护进程，因此宿主机对低位端口的权限限制会直接暴露。容器内的进程即使拥有 CAP_NET_BIND_SERVICE，也无法解决宿主机端口发布失败的问题，因为该 capability 只影响容器内进程，而非宿主机上的 pasta。修改 ip_unprivileged_port_start 可以放宽权限，但会扩大所有普通用户的监听范围，在多人共用或生产环境需谨慎。
安全实践：明确监听地址与权限收敛
使用 portmap 时，应明确指定监听地址，避免将高位端口暴露给外部网络。例如，Podman 发布端口时使用 127.0.0.1:8080:80，portmap 监听 127.0.0.1:80，可防止外部绕过 portmap 直接访问 8080。长期运行建议通过 systemd 的 AmbientCapabilities 仅授予 CAP_NET_BIND_SERVICE，避免二进制持有完整 root 权限，同时注意防火墙和云安全组仍需单独配置。
适用场景与替代方案
portmap 适合端口数量少、流量可控的个人开发环境或 HomeLab，用于为 Rootless 容器提供固定标准端口入口。若服务本身可用高位端口，则无需额外转发；需要 TLS、域名路由或负载均衡时，应使用 Caddy、Nginx 等成熟网关；高流量公网入口或大量端口转发，nftables 或专用代理更合适。此外，portmap 不保留原始客户端 IP，依赖源地址审计的服务需注意。
Q&A
为什么在 Rootless Podman 中发布 80 端口会失败？
Rootless Podman 使用 pasta 发布端口时，由于宿主机对低位端口（如 80）有权限限制，普通用户没有 CAP_NET_BIND_SERVICE 能力，导致监听失败。
portmap 工具的主要功能是什么？
portmap 是一个简单的 TCP/UDP 端口转发程序，用于将高位端口转发到标准端口（如 80、443），解决 Rootless Podman 无法直接发布低位端口的问题。它不依赖 socat，支持 systemd 管理。
如何使用 portmap 将宿主机的 80 端口转发到容器的 8080 端口？
先使用 Rootless Podman 将容器端口发布到高位端口（如 8080），然后运行 portmap 命令：sudo portmap -listen-host 127.0.0.1 -listen-port 80 -target 127.0.0.1:8080。
portmap 与 socat 相比有什么优势？
portmap 以单个二进制分发，不依赖系统是否安装 socat，提供一致的 TCP/UDP 配置方式，并支持查看连接数量、上下行字节和连接持续时间。
如何通过 systemd 管理 portmap 并限制其权限？
创建一个 systemd 模板服务（如 portmap@.service），在服务配置中使用 DynamicUser=yes 和 AmbientCapabilities=CAP_NET_BIND_SERVICE，这样服务以临时用户运行，仅授予绑定低位端口所需的能力，无需 root 权限。
portmap 在 UDP 模式下如何处理会话？
portmap 以客户端地址为键，为每个客户端维护一条到目标地址的 UDP 会话，目标返回数据后通过会话表将响应发回原客户端。长时间没有数据的会话会被回收，默认空闲超时为 60 秒。
portmap 的适用场景有哪些？不适合哪些场景？
适用场景包括：Rootless Podman 需要发布标准端口（如 80、443、22、53）、服务入口不方便修改、HomeLab 和内部工具等端口不多、流量可控的场景。不适合需要处理 TLS、域名路由或负载均衡的场景，也不适合高流量公网入口或依赖真实源 IP 的服务。
portmap 的性能测试结果如何？
文章中的压测在 Mac 上完成（darwin/arm64，10 核 M5），三组测试（TCP 吞吐、UDP 吞吐、TCP 连接）均无错误，活跃连接计数归零。但测试仅验证进程内转发链路，不代表 Podman 网络或公网环境表现。
