Podman容器访问宿主机网络排错

摘要: 本文记录了在将服务从Docker迁移至Podman（无根模式）时，遇到的一个典型网络问题：容器无法通过宿主机IP访问宿主机服务。文章通过分析Podman的网络模型，并结合一个复杂的SSH代理场景，最终定位并解决了问题。

1. 问题陈述

#

在迁移过程中，一个依赖于"容器访问宿主机"模式的服务出现故障。该服务在Docker环境中，可以直接使用宿主机的局域网IP或公网IP进行通信，但在Podman无根容器中则连接超时。

2. 原理分析：Docker vs. Podman无根网络模型

#

初步分析表明，问题源于两者网络模型的根本差异。

• Docker (Rootful): Docker守护进程以root权限运行，会创建内核级虚拟网桥（如 docker0），并主动修改宿主机的iptables/nftables规则，以支持"发夹弯NAT"（Hairpin NAT）。这使得容器发往宿主机真实IP的流量能被正确路由回环。
• Podman (Rootless): 出于安全考虑，Podman在无根模式下使用用户空间网络堆栈（如Netavark），不具备修改系统级iptables/nftables的权限。因此，当容器尝试访问宿主机的真实IP时，产生的Hairpin NAT流量会被内核的默认策略丢弃，导致连接失败。

3. 解决方案：正确的内部通信机制

#

既然外部回环路径不通，就需要采用Podman提供的内部通信机制。

3.1. 抽象层：host.containers.internal

#

Podman提供了一个特殊的DNS名称 host.containers.internal，它在容器内部会被自动解析为宿主机在当前容器网络中的地址。这是访问宿主机的首选方式，因为它解耦了对具体IP的依赖。

在容器内测试连通性：

1
2
3
4
5

$ podman exec -it my_container /bin/sh
ping host.containers.internal
PING host.containers.internal (169.254.1.2): 56 data bytes
64 bytes from 169.254.1.2: seq=0 ttl=42 time=0.285 ms
...

测试结果表明，容器到宿主机的L3层网络是通畅的。

3.2. 防火墙策略

#

流量需要通过宿主机的防火墙。规则的核心是允许来自Podman子网的入站流量。

• 获取Podman网络子网:

1
2
3

      $ podman network inspect podman | grep subnet
      "subnet": "10.89.0.0/24",
  

• 向nftables添加规则 (以目标端口TARGET_PORT/tcp为例):

1
2
3

# 向默认的inet filter表的input链添加规则
sudo nft add rule inet filter input ip saddr 10.89.0.0/24 tcp dport TARGET_PORT accept
  

• 持久化nftables规则: nft命令添加的规则在重启后会失效。为使其永久生效，需将当前规则集保存到配置文件并启用服务。

1
2
3
4
5
6

# 将当前规则集写入配置文件
sudo nft list ruleset > /etc/nftables.conf

# 确保nftables服务开机自启以加载规则
sudo systemctl enable nftables.service
  

4. 实战复盘：通过sing-box代理SSH访问宿主机

#

理论验证后，我将其应用到一个复杂的实际场景中进行测试。

• 场景: 远程SSH客户端(WindTerm) -> 本地sing-box客户端 -> 服务器sing-box容器 -> 宿主机SSH服务(监听于TARGET_PORT)。
• 客户端配置: WindTerm的代理设置为本地sing-box（监听于LOCAL_PROXY_PORT），并启用了“远程DNS解析”。SSH主机名设置为host.containers.internal。

尽管如此，连接依然失败。这表明问题不在于基础网络，而在于代理链的逻辑。

4.1. 服务器端验证

#

为排除服务器端问题，我直接在sing-box容器内发起了SSH连接。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# 在sing-box容器内安装并执行ssh
$ podman exec -it sing-box /bin/sh
/ # apk add openssh-client
/ # ssh [email protected] -p TARGET_PORT
The authenticity of host ... can't be established.
...
Are you sure you want to continue connecting (yes/no)? yes
# 成功收到密码提示
[email protected]'s password:
  

结论: 服务器端配置完全正确。 ssh连接成功证明从容器到宿主机的网络路径、防火墙、SSH服务本身均无问题。

4.2. 客户端日志分析与最终定位

#

既然服务器端无误，问题必然出在客户端的代理链上。我检查本地sing-box客户端的日志，发现了以下关键条目：

1
2
3

error [timestamp] connection: open outbound connection: NXDOMAIN
info  [timestamp] outbound/direct[]: outbound connection to host.containers.internal:TARGET_PORT
 

日志清晰地指出了问题：

• 客户端收到了发往host.containers.internal的请求。
• 但其路由规则错误地将此请求匹配到了direct（直连）出站。
• 客户端尝试在本地解析host.containers.internal，导致NXDOMAIN（域名不存在）错误。

4.3. 解决方案

#

修正**客户端sing-box**的路由配置，添加一条高优先级的规则，将host.containers.internal的流量强制导向服务器代理出站（此处tag为proxy-out）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

      {
  "routing": {
    "rules": [
      {
        "domain": ["host.containers.internal"],
        "outbound": "proxy-out"
      },
      // ... 其他规则
    ]
  }
}

应用此规则后，重启客户端，SSH连接成功。

5. 总结

#

• Podman无根网络的隔离性是其安全性的基础，但也带来了与Docker不同的网络行为，特别是对于Hairpin NAT场景。
• host.containers.internal**是Podman容器访问宿主机的标准抽象层，应优先使用。
• 必须为Podman子网配置相应的防火墙入站规则。
• 在复杂的代理或网络链中，端到端的日志分析和在关键节点进行原生协议测试，是最高效、最可靠的故障排查方法。