IP多媒体子系统(IMS)中的IPSEC发行的NAT

发布于 2025-02-07 11:58:20 字数 703 浏览 1 评论 0原文

IP多媒体子系统(IMS)封装了IPSEC封装安全有效负载(ESP)有效载荷的UE和P-CSCF(GM接口)之间的SIP流量。当网络在NAT后面时,IPSEC会破裂。在将IMS部署在Kubernetes上时,NAT已被引入,因为POD具有私有CIDR,而不是p-CSCF外部暴露的服务。 。 DNAT操纵数据包标头,它用P-CSCF POD的IP替换服务IP地址,反之亦然。但是,修改标头内容违反了IPSEC的完整性保证并将其违反(运输(TCP)Pseudo标头,用于计算通过使用UE侧的P-CSCF服务IP创建的校验和,但由于natting由于kubernetes而发生,因此校验和校验会失败。将与POD IP计算的校验和相比,在内核上删除了数据包。

策略 -

  1. 隧道IPSEC模式将UDP标头(NAT -T)封装到最终主机(仅作为移动手机支持IP -SEC传输模式)
  2. 隧道(UE -Worker_Node和worker_node -p -cscf)[3GPP规格不使用 最终,我们将

IPSEC组件从P-CSCF分解为单独的微服务。创建了用于处理ESP关联的ESPServer,它使用POD的主机网络,并在内核中创建IPSEC关联和策略。其余功能由P-CSCF完成。因此,一旦加密数据包出现在工人节点上,它就会自动解密,并且按照服务发生的路由。因此,我们创建了约束。

请帮助我删除上述约束或提供策略,以便IPSEC可以在上述情况下与NAT一起使用,而我们不必将P-CSCF分为单独的微服务。

IP Multimedia Subsystem(IMS) encapsulates SIP traffic between UE and P-CSCF (Gm Interface) in IPsec Encapsulating Security Payloads (ESP) payloads. IPsec breaks when a network is behind the NAT. On deploying the IMS on Kubernetes, NAT has been introduced as pods have a private CIDR as opposed to the P-CSCF externally exposed service.( As a result, the packet from Client gets both SNAT and DNAT to Pod IP of P-CSCF). DNAT manipulates packet header, it replaces the service IP address with P-CSCF Pod's IP and vice versa. However, modifying the header content violates the IPsec’s integrity guarantee and breaks it( Transport (TCP) pseudo header is used to calculate checksum created by using P-CSCF service IP at UE side but since Natting happens due to Kubernetes, checksum is failed as it is compared with checksum calculated with Pod IP and packet is dropped at kernel).

Strategies -

  1. Tunnel IPsec mode encapsulated in UDP header (NAT-T) to the end host(Does not work as Mobile handset support IP-SEC Transport mode only)
  2. Tunnel (UE -Worker_Node and Worker_Node - P-CSCF) [3GPP Specification does not approve of it]

Finally, We break the IPsec component from P-CSCF into separate microservices. A ESPserver for handling ESP associations is created which uses host Network of Pod and creates IPsec Association and policies in the kernel. The rest of the Functionality is done by P-CSCF. So, as soon as the encrypted packet comes to worker nodes, it gets automatically decrypted and the routing as per services happens. because of this, we have created constraint.

Please help me in removing above constraint or give strategies so that IPsec can work with NAT in above scenario and we do not have to break P-CSCF into separate microservices.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。
列表为空,暂无数据
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文