内核数据路径测验

本测验检查你对链路本地拦截的内核层、iptables 冲突和 conntrack 行为的理解。

选择题

1. 为什么说 Lattice 使用链路本地地址范围“并未严格遵循链路本地语义”？
   • A) 这些地址实际上是公共 IP
   • B) 169.254.0.0/16 名义上不可路由，但 Lattice 流量必须到达 VPC 内的入口端点，因此基础设施会将流量引导到那里
   • C) 仅支持 IPv4
   • D) DNS 不会解析该地址范围

显示答案

答案：B) 169.254.0.0/16 名义上不可路由，但 Lattice 流量必须到达 VPC 内的入口端点，因此基础设施会将流量引导到那里

说明： Lattice 并未按“不可路由地址”的原始含义使用链路本地地址范围，而是将该范围重新用作“基础设施会拦截此流量”的信号。数据包确实需要到达 VPC 内的入口端点。出于同样的原因，IPv6 使用可路由的 ULA（fd00:ec2:80::/64），而不是链路本地地址（fe80::/10）；链路作用域不足以满足需求。

2. 边车代理服务网格与 Lattice 流量的冲突具体发生在内核的哪个位置？
   • A) 节点网络命名空间中的 POSTROUTING
   • B) Pod 网络命名空间的 OUTPUT 钩子：Lattice 流量也是出站流量，因此会匹配 REDIRECT 规则
   • C) NIC 驱动程序的环形缓冲区
   • D) 节点路由表

显示答案

答案：B) Pod 网络命名空间的 OUTPUT 钩子：Lattice 流量也是出站流量，因此会匹配 REDIRECT 规则

说明： 服务网格的初始化容器会在 Pod 的网络命名空间中安装 iptables 规则，将所有出站流量 REDIRECT 到 Envoy 端口。发往 Lattice 的流量也属于出站流量，因此会匹配该规则；但 Envoy 无法在其集群配置中找到 169.254.171.x，于是处理失败。此冲突发生在 Pod 内，因为 netfilter 规则按网络命名空间隔离。

3. 应如何诊断被拦截的请求？
   • A) 它会触发内核崩溃
   • B) 检查 Envoy 实际的出站策略、路由和错误；未知目标可能会被转发或拒绝
   • C) Pod 会立即进入 CrashLoopBackOff
   • D) kube-proxy 会记录警告

显示答案

答案：B) 检查 Envoy 实际的出站策略、路由和错误；未知目标可能会被转发或拒绝

说明： 在代理日志中看到请求，只能证明请求经过了代理，并不能确定唯一的故障原因。应验证实际选择的绕过/签名行为，而不是假定请求会立即失败。

4. 已注册例外 CIDR，但仍会“偶尔”失败。最可能的原因是什么？
   • A) 规则顺序错误
   • B) 缺少 IPv6 地址范围（fd00:ec2:80::/64）：在双栈环境中，客户端通过 IPv6 连接时仍会被拦截
   • C) Pod 没有重启
   • D) 缺少安全组规则

显示答案

答案：B) 缺少 IPv6 地址范围（fd00:ec2:80::/64）：在双栈环境中，客户端通过 IPv6 连接时仍会被拦截

说明： 在双栈集群中只排除 IPv4，意味着客户端收到 AAAA 记录并通过 IPv6 连接时仍会被拦截。“偶尔失败”的症状很典型，因为是否发生取决于 DNS 应答顺序和客户端的地址选择。C 也可能是真正原因，但这种情况下该 Pod 会持续失败，而不是“偶尔”失败。

5. 为什么出站代理方案必须使用基于 UID 的例外规则？
   • A) 安全策略要求代理以非特权 UID 运行
   • B) 代理发出的已签名数据包也会发往 Lattice 地址范围；如果没有 UID 例外，数据包会被重定向回代理并形成循环
   • C) SigV4 签名包含 UID 信息
   • D) conntrack 会根据 UID 区分条目

显示答案

答案：B) 代理发出的已签名数据包也会发往 Lattice 地址范围；如果没有 UID 例外，数据包会被重定向回代理并形成循环

说明： 代理发出的签名数据包也会发往 169.254.171.x。如果没有 UID 例外，它会再次匹配 REDIRECT 规则并形成循环。因此，代理会使用专用 UID（参考实现中为 101），netfilter 的 owner 匹配规则（-m owner --uid-owner）会对来自该 UID 的流量执行 RETURN。代理容器的 runAsUser 必须与 iptables 中的 UID 匹配（自定义清单时这是最容易出错的环节）。

6. 为什么出站代理方案比共享库方案给 conntrack 带来更大负载？
   • A) 代理会让连接保持打开更久
   • B) Pod 网络命名空间中的 REDIRECT 属于 DNAT，必须记录这项转换，以便将返回流量转换回去；此外，代理到 Lattice 的连接也会产生条目
   • C) 代理也会使用 UDP
   • D) 代理会增加 conntrack 超时时间

显示答案

答案：B) Pod 网络命名空间中的 REDIRECT 属于 DNAT，必须记录这项转换，以便将返回流量转换回去；此外，代理到 Lattice 的连接也会产生条目

说明： 签名代理会创建本地和上游连接段，而连接池和命名空间/NAT 选择会改变跟踪开销。应检查 Pod/节点表和 eBPF 映射，而不是假定节点表中必定出现固定的条目增量。

7. 抓包可见性能够证明什么？
   • A) conntrack 耗尽
   • B) 根据发送方/接收方、方向、接口和命名空间解读抓包，并与其他证据关联
   • C) qdisc 丢包
   • D) Lattice 身份验证失败

显示答案

答案：B) 根据发送方/接收方、方向、接口和命名空间解读抓包，并与其他证据关联

说明： 在交付前被拒绝的入站数据包不会出现在接收方。出站数据包可能会在发送方可见，之后才被外部安全组丢弃。仅凭未收到响应，并不能证明是安全组故障。

8. “只有部分节点上的 Lattice 调用失败”这一现象说明什么？
   • A) Lattice 服务配置错误
   • B) 节点状态不一致：安全组不同、内核版本混用、conntrack 设置不同、时钟同步情况，以及 Pod 是否重启
   • C) 访问控制策略配置错误
   • D) DNS 传播延迟

显示答案

答案：B) 节点状态不一致：安全组不同、内核版本混用、conntrack 设置不同、时钟同步情况，以及 Pod 是否重启

说明： 全面失败更可能指向配置或身份验证问题；按节点出现的故障则指向节点状态不一致。候选原因包括各节点组的安全组不同、kernel-default AMI 中混用了 6.1/6.18 内核、取决于节点引导时序的 conntrack 设置不同、时钟同步问题导致 x-amz-date 偏差超过 5 分钟，以及注释更改未应用到旧 Pod。“只有部分节点”这一现象本身就能缩小排查范围。