广告广告位招商联系 ads@iiunion.comA5 · 728×90(移动端 320×100) · 参考价 ¥300/月了解详情 →

Linux 网络命名空间里抓包看不到业务流量?veth、策略路由与 conntrack 的排查顺序

Started by iiunion编辑部 · 2026-11-04 01:54 UTC · 5 views · 1 replies
I Editorial
容器/多租户节点上,业务明明在跑,tcpdump 在 netns 里却是空的——或只看到半边包。根因经常不是「没流量」,而是抓错命名空间、veth 对端、策略路由绕路,或 conntrack/NAT 把路径改到你没监听的口。本帖按「先定位包在哪一侧 → 再查路由与规则 → 最后才怀疑应用」整理排查顺序。

一、先钉死观察点
1. 确认进程所在 netns:`lsns` / `/proc/<pid>/ns/net`,不要假设「宿主机 tcpdump」能看见容器内 veth 对端的全部逻辑。
2. 在容器内口、veth 宿主机端、桥/ bond、默认出口各抓一轮短窗口,用同一五元组对齐时间戳。
3. 只在一侧看见 SYN、对侧没有:优先查 netfilter FORWARD/策略路由,而不是先改应用重试间隔。

二、veth 与桥
1. veth 成对:一端进 netns,一端挂 bridge/CNI;抓错端会表现为「偶发几个广播、没有业务单播」。
2. 桥上混杂模式、VLAN 过滤、hairpin:容器互访与出网路径不同,分别验证。
3. checksum/offload:虚拟口上 tcpdump 显示错误校验和不一定是真坏包,对照对端与 `ethtool -k` 再下结论。

三、策略路由与多出口
1. `ip rule` / `ip route show table`:按 fwmark、源地址选表时,回程若不对称,conntrack 会表现为单向或 RST。
2. 策略路由与 CNI 路由表叠加后,默认路由「看起来对」,实际出接口已变;用 `ip route get <dst> from <src> iif …` 复现。
3. 黑洞路由、unreachable、mtu/clamp:抓包有请求无应答时一并核对。

四、conntrack / NAT
1. DNAT/SNAT 后五元组变化,应用日志里的对端地址与线上包不一致是常态;对照 conntrack 表项再谈「丢包」。
2. 表满、早期 drop、helper 协议:短连接风暴时先看 `nf_conntrack_count` 与 drop 计数。
3. 两端都做 NAT 或超时过短,长连接会「假死」;抓包可见保活,业务仍超时——查超时与中间设备会话。

五、常见误区
- 只在宿主机默认口抓包就断言容器无流量。
- 忽略策略路由,只看 main table。
- 一看不到包就关防火墙,不留复现记录。

欢迎补充你们在 Cilium/Calico、多网卡策略路由、以及 rootless 容器场景下的抓包对照经验。
I Editorial
机器人车队节点也常在独立 netns/VR 里跑感知与调度。抓包看不到业务流时,我们同样先确认进程 netns 与 veth 对端,再查策略路由是否把回程绕到另一张网卡。DDS 发现组播若走错接口,表现也像「有进程无流量」。建议用同一五元组在容器口和宿主机口各抓短窗口对照,再动 conntrack。纯技术对照,供边缘采集排障参考。
广告广告位招商联系 ads@iiunion.comA6 · 728×90(移动端 320×100) · 参考价 ¥200/月了解详情 →
Log in or register to reply.