Kubernetes部署IMS场景下NAT与IPsec兼容问题方案咨询

IP多媒体子系统（IMS）默认将UE与P-CSCF之间（Gm接口）的SIP流量封装在IPsec ESP载荷中传输，网络路径中存在NAT时原生IPsec机制会直接失效。
在Kubernetes上部署IMS时，Pod默认使用私有CIDR网段，P-CSCF对外暴露服务必然引入NAT：客户端发送的数据包会经过SNAT+DNAT转换，把目的地址从服务IP替换为P-CSCF的Pod IP，反向报文做对应反向替换。这类报文头修改会直接破坏IPsec的完整性校验逻辑：UE侧用P-CSCF的对外服务IP计算TCP伪头校验和，K8s完成NAT转换后，节点内核会用转换后的Pod IP计算校验和，二者数值不匹配，数据包会被内核直接丢弃。

• 采用带UDP封装的NAT-T隧道模式IPsec直达终端：现有移动终端普遍仅支持IPsec传输模式，不支持隧道模式，无法适配。
• 分段建立IPsec隧道（UE到Worker节点、Worker节点到P-CSCF）：该实现不符合3GPP规范要求，无法在合规场景使用。

当前临时方案是把P-CSCF内置的IPsec处理逻辑拆成独立微服务，部署一个使用主机网络的ESPserver专门处理ESP关联，直接在Worker节点内核生成IPsec安全关联和策略，其余业务逻辑仍由原P-CSCF Pod承担。加密报文到Worker节点后先被内核解密，再按K8s服务规则路由到P-CSCF。但该方案强制拆分原有P-CSCF架构，带来了额外的部署、运维、版本适配约束。

核心逻辑是避免NAT转换破坏IPsec完整性校验，全程保证IPsec加解密两端计算校验和使用的地址一致，不需要拆分P-CSCF原有组件，可根据集群实际情况选以下任意一种实现：

• 方案1：P-CSCF采用主机网络+externalIP暴露，跳过kube-proxy的NAT处理
  给P-CSCF Pod开启hostNetwork: true，直接将节点公网IP配置为P-CSCF的对外服务IP，所有IPsec SA协商、ESP加解密逻辑全部保留在P-CSCF进程内，不需要拆分独立的ESP服务。此时P-CSCF直接监听节点公网IP的对应端口，发往该IP的ESP报文不会经过kube-proxy的DNAT/SNAT转换，报文IP全程和UE侧计算校验和使用的地址一致，从根源上避免校验和不匹配问题。部署时只需要在节点防火墙放开IPsec ESP（IP协议号50）、IKE（UDP 500/4500）对应端口即可，不会和其他服务产生端口冲突。
• 方案2：基于eBPF数据面对ESP流量做NAT豁免
  如果集群使用Cilium等支持eBPF的CNI插件，可配置eBPF规则直接匹配IP协议号为50的ESP流量，对这类流量跳过kube-proxy的DNAT/SNAT处理，直接路由到后端P-CSCF Pod；同时在P-CSCF侧配置回包时源IP固定为对外暴露的服务IP，保证两端校验和计算的IP地址完全一致。该方案不需要P-CSCF使用主机网络，也不需要改动P-CSCF原有代码逻辑，仅靠数据面规则即可实现流量正确转发。
• 方案3：调整服务转发策略+conntrack豁免，最小化网络改动
  对于使用NodePort/LoadBalancer暴露的P-CSCF服务，将服务的externalTrafficPolicy配置为Local，同时在节点iptables/nftables规则中添加ESP流量的conntrack豁免规则，不对ESP报文做TCP伪头校验和重计算，直接将报文转发到同节点上的P-CSCF Pod；P-CSCF协商IPsec SA时固定使用对外服务IP作为本端地址，即可保证两端校验值匹配。该方案不需要替换现有CNI插件，对集群网络的改动量最小。

注意：所有方案都需要保证P-CSCF在IKE协商阶段向UE通告的本端地址为对外暴露的公网服务IP，不能使用Pod内部IP，避免协商阶段就出现地址不匹配问题。

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