snat 端口耗尽问题

image.png

关于snat的机制：

以Azure snat LB 举例，tcp场景
1、 一个app 将tcp包发给一个内部实例的ip A，该示例是内网的LB的前置实例。
2、 该包会从A ip 所在实例路由到snat LB 地址。LB 会将应用包的原地址和源端口会被映射为一个公网ip和一个端口，并发往公网。

image.png

3、 公网接收到该tcp包，会基于LB的公网地址作为回包的目的地址。
4、当LB收到公网的回包后，会基于conntrack中的map记录，将目标IP和端口转化为内网的LB的其中一个实例（感觉这里应该是当初发出包发到的那个实例ip），因为conntrack有这条记录。

由于snat的发生过程，在内部ip端口到公网ip端口时，会占用公网ip和公网端口，如果只有一个公网ip，那么只要内部实例足够多，那么就会端口面临用尽的风险。

按照如下的端口用尽场景的分析，其实还是挺常见的一个现象:

image.png

解决方式： 可以配置多个公网ip，提升下公网ip*端口容量

iptables SNAT --to-source 172.0.0.10-172.0.0.20

参考： https://github.com/kubeovn/kube-ovn/issues/1957

Port exhaustion is easier than expected: https://4lowtherabbit.github.<wbr>io/blogs/2019/10/SNAT/#snat-<wbr>ports-exhaustion
Iptables manpages: https://manpages.debian.org/<wbr>unstable/iptables/iptables-<wbr>extensions.8.en.html#to~6

其他问题: snat 端口竞争状态的问题

当snat 需要创建一个端口时候，默认情况下，端口号是自动增加的，但又因为这个 “自增”的过程不是原子的，并发的链接会导致这些链接拿到同一个端口。这种结果就是一种竞争状态。 当把新的链接写到conntrack 表时，后续的记录是无法成功插入的。就会导致后续的包出现丢包。 conntrack -S 统计信息会看到 insert_failed 以及 drops。 这些统计信息表示 conntrack 插入失败并且导致丢包。

iptables 支持其他的方式分配端口， 基于--random 以及 --random-fully 选项可以避免竞争状态。

参考： https://adrian-philipp.com/notes/linux-conntrack-race-condition