Istio Ambient Mesh路由规则与iptables两类异常问题咨询

场景说明 #

集群包含NA、NB两个节点；sleep应用Pod部署在NA节点，httpbin应用Pod部署在NB节点；在sleep Pod内执行curl访问httpbin。

问题1：为何仅首包经istioin进入Ztunnel，后续包走veth？ #

这是Istio Ztunnel依赖**内核连接跟踪（conntrack）**实现的流量优化逻辑：

• 首包是未建立的TCP连接请求，此时内核没有该连接的跟踪记录，会严格匹配iptables策略路由规则，走istioin接口进入Ztunnel处理。你看到的路由表100规则（如10.244.1.7 via 192.168.126.2 dev istioin src 10.244.1.1）就是专门针对这类未被跟踪的首包设计的。Ztunnel在完成首包处理（比如身份验证、路由决策）后，会通过ebpf或iptables给这个连接打上专属标记，同时内核conntrack会完整记录下该连接的五元组（源IP/端口、目标IP/端口、协议）、状态和转发路径。
• 后续数据包属于已建立连接的流量，内核会优先匹配conntrack中的连接记录，直接按照之前记录的转发路径，通过Ztunnel的veth接口交付，不再重复走首包的iptables策略路由流程。这条路由表100规则只对未被conntrack跟踪的首包生效，后续包因为已经有连接记录，根本不会触发这条规则的匹配。

问题2：响应包为何能被Ztunnel正确接收？ #

你的分析忽略了已建立连接的conntrack优先级和Ztunnel的流量处理逻辑：

1. 首先，你提到的那条PREROUTING MARK规则：

   -A PREROUTING ! -d 10.244.1.3/32 -i eth0 -p tcp -j MARK --set-xmark 0x4d3/0xfff
   

   仅对未被conntrack跟踪的数据包生效。响应包属于sleep与httpbin之间已建立的连接的反向流量，内核conntrack已经记录了该连接的关联关系——这个数据包的实际接收方是Ztunnel进程，因此不会命中这条MARK规则，自然也不会触发策略路由（20003: from all fwmark 0x4d3/0xfff lookup 100）去查找表100。
2. 退一步说，即使数据包进入路由表匹配环节，Ztunnel作为Istio的流量代理，已经在本地监听了对应端口（用于处理跨节点的加密/转发流量），内核会优先匹配local类型的路由规则（包括进程监听端口对应的隐式本地路由），而不是主路由表的默认规则（default via 10.244.1.1 dev eth0）。你看到的路由表100的local default dev lo规则是兜底的本地路由，当数据包目标端口被Ztunnel监听时，内核会直接将数据包交付给Ztunnel的套接字，不会走到转发到eth0的步骤。

内容的提问来源于stack exchange，提问作者xocoder