我们已经知道 DPVS 是一个基于 DPDK 的高性能负载均衡器，它能够支持 DR、FNAT、NAT 等工作模式。另外支持还能够支持 SNAT 功能，实现原理和 FNAT 很相似，因此也具备高性能的特点。
在实际生产环境中，有些服务器需要通过 SNAT 功能来访问外网服务，可能的需求原因如下：
- 只提供内网服务，比如负载均衡反向代理后端的服务器，只配置内网地址
- 机房环境的原因，相关服务器临近的交换机不能配置公网 IP 资源
- 有些是出于公司商务成本考虑，为了节省开支，没有提供出公网的能力
- 有些是系统架构的设计或系统安全性的考虑
出于以上的某种原因（可能还有其他别的原因），服务器没有配置公网 IP 地址，默认是不能够出公网访问的。但实际有时会有访问外网的需求，比如，通过 yum 仓库安装软件包，或是调用外部第三方的某个接口来获取数据等等的需求场景，这时 SNAT 系统能够很方便的解决这些问题。据了解，很多公司都会提供 SNAT 服务，可能没有负载均衡服务那么重要的地位，但也属于公司内部底层基础架构的组成部分，大多时候也是必不可少的。
最常见的 SNAT 实现方式
SNAT 最常见也是最经典的实现方式就是通过 linux 提供的 iptables 功能，操作简单，大概操作方式如下：
# 开启 IPv4 的转发功能
$ echo 1 > /proc/sys/net/ipv4/ip_forward
$ iptables -t nat -A POSTROUTING -d 192.168.1.160/32 -p tcp --dport 9200 -j SNAT --to-source 192.168.1.7;
# 客户端设置默认路由，网关指向 SNAT 设备 IP 地址即可
$ ip route add default via 192.168.1.1 dev eth0
# 注：只描述大概操作步骤和方式。
在实际生产环境中，为了节省大部分服务器出公网时只设置了少量的公网 IP 地址。生产环境中的 SNAT 服务器一般会做成主备模式或 BGP 集群。
- 主备模式 。一般是 2 台服务器，都配置相同的 iptables 规则，另外需要运行 keepalived 服务来负责 网关IP 和 WAN IP 管理，本质上也是 VIP 的形式存在，如果 A 服务器宕机，B 服务器 keepalived 服务感知到后就会在本机上生成相应的 WAN IP 和 网关IP 地址，继续提供 SNAT 服务。
- BGP 集群方式 。主备方式比较简单，但是设备利用效率较低，同一时间只有一台服务器提供服务器。BGP 集群方式，VIP 不是由 keepalived 来管理，而是由交换机负责将访问的 VIP 以等价路由的方式，均衡轮询的分配到多台 SNAT 服务器上，这样内网服务器通过网关访问外网时，流量就会分摊到多台的 SNAT 设备上了。
这两种方式用来实现 SNAT 功能也比较成熟和稳定，不过由于 iptables 自身的一些问题，如 nf_conntrack 表的限制，以及大量的 iptables 规则导致的查找性能下降，整体来看，iptables 实现方式存在明显的性能瓶颈。在生产环境中，经常会遇到某个业务流量跑高导致的 cpu 告警等问题。
DPVS 关于 SNAT 功能
DPVS 本身是一个基于 DPDK 的高性能负载均衡器，比较常用的工作模式是 FNAT，这种方式从运维和管理上比较友好一些，而且它能够充分的利用多核 CPU 的处理能力，同时也做了很多无锁的优化，它的整体性能也是非常强劲。SNAT 功能在实现原理和逻辑流程上，与 FNAT 非常相似，因此也具备高性能的特点。
可以对比 FNAT 与 SNAT 来进行理解：
- 对于 FNAT 功能，使外网用户客户端访问流量到达 FNAT 时，DPVS 将数据包的源目的 IP 和端口都进行了转换，分发给后端的某个真实服务器。
- 而对于 SNAT 功能，是内网服务器作为客户端访问流量到达 FNAT 时，DPVS 同样是将源 IP 和端口转换为公网 IP，转发出去到达外网真实服务器
- 如果将 FNAT 流程反过来理解的话，就能理解 FNAT 与 SNAT 的流程非常相似。
（一）基本原理说明
先通过下图简单说明 snat 实现的大致原理：
- 内网服务器 s1，没有配置公网 IP，需要访问 baidu.com 的某个接口，s1 要将默认网关设置为 SNAT 的 gw 192.168.20.1，那么访问 baidu 的数据包就会转发给下一跳（SNAT）。
- 数据包到达 SNAT 设备后，SNAT 会根据源 IP 和协议类型来判断是否为需要处理的报文，如果查找到对应的 service 配置，则会根据查到的服务信息修改数据包，将源 IP 修改为配置的公网 IP（假设为 wip1），然后通过外网网卡转发出去。
- 外网 baidu 服务器收到请求后，正常处理并恢复响应数据包，响应数据包到达 SNAT 网关后，这时的目标 IP 是 wip1，SNAT 会根据源 IP 等信息查找连接表，查到连接表后，根据连接表信息将数据表的目标 IP 修改为内网服务器的 IP 地址，然后通过内网网卡转发出去。
- 内网服务器 s1 收到响应数据包时，都已经复原为正常的连接信息，到此为止，s1 就正常的接收到了响应的数据包了。
（二）DPVS SNAT 的基础使用操作
这里只罗列在 DPVS 上如何配置 SNAT 服务。
假设设备上有两张网卡，一个外网，一个内网，测试 SNAT 双臂模式：
- 内网网卡：dpdk0
- 外网网卡：dpdk1
- wan IP 配置时必须携带 sapool 选项
- SNAT 使用 match 类型的 service ，而不是 vip:port
- SNAT 设备上 wan 接口上需要配置默认路由（出公网）
SNAT 设置如下：
WAN_IP=123.1.2.3 # WAN IP can access Internet.
WAN_PREF=24 # WAN side network prefix length.
GATEWAY=123.1.2.1 # WAN side gateway
LAN_IP=192.168.100.1
LAN_PREF=24
# add WAN-side IP with sapool
./dpip addr add $WAN_IP/$WAN_PREF dev dpdk1 sapool # must add sapool for WAN-side IP
# add LAN-side IP as well as LAN route (generated)
./dpip addr add $LAN_IP/$LAN_PREF dev dpdk0
# add default route for WAN interface
./dpip route add default via $GATEWAY dev dpdk1
MATCH0='proto=tcp,src-range=192.168.100.0-192.168.100.254,oif=dpdk1'
MATCH1='proto=icmp,src-range=192.168.100.0-192.168.100.254,oif=dpdk1'
./ipvsadm -A -s rr -H $MATCH0
./ipvsadm -a -H $MATCH0 -r $WAN_IP:0 -w 100 -J
./ipvsadm -A -s rr -H $MATCH1
./ipvsadm -a -H $MATCH1 -r $WAN_IP:0 -w 100 -J
通过上述配置，就配置了两个 service，分别是 MATCH1 和 MATCH2，这时如果通过 ipvsadm -ln 就能看到 svc 已经生效，这里就不贴展示的内容了。
同样上述命令行实现的配置效果，用 keepalived 的配置方式也同样能够实现：
virtual_server match SNAT1 {
protocol TCP
lb_algo rr
lb_kind SNAT
src-range 192.168.100.0-192.168.100.254
oif dpdk1
real_server 123.1.2.1 0 {
weight 4
}
}
virtual_server match SNAT2 {
protocol ICMP
lb_algo rr
lb_kind SNAT
src-range 192.168.100.1-192.168.100.254
oif dpdk1
iif dpdk0
real_server 123.1.2.1 0 {
weight 4
}
}
通过上述配置，我们可以简单总结到如下的内容：
- 每个 match service 是有协议类型的，也就是说如果我们需要服务器同时支持访问 TCP、UDP、ICMP 的话，对同一个配置需要设置至少 3 个 match 服务。
- 配置中的 RS 指的是 wan ip 列表，如果指定多个 RS，那么就会轮询从 RS 列表中选择 wan ip。不过需要注意，RS 中的 Port 必须设置为 0
- 另外一个问题，DPVS SNAT 设置 WAN IP 地址时必须使用 dpip 命令行携带 sapool 选项才行，keepalived 配置 IP 地址时，默认没有不支持这个选项。这就意味着现有的方式必须通过 dpip 命令行来操作。
- 如果单机需要支持 一对一 SNAT 功能，只需要指定 src-range 为固定 IP，另外 real_server 只指定一个 RS 就能实现一对一的功能。
（三）SNAT 使用时需要考虑的一些问题
SNAT 是爱奇艺团队开发的功能，如果我们要使用的话，需要仔细分析是否与自己的需求一致，能否满足我们的使用方式。
- 实现基本的 SNAT 功能，这点应该没问题
- 确定 SNAT 各方面：配置方式、配置管理、使用方式
- 业务特殊需求：绑定固定的公网 IP 地址，如需要固定白名单场景，EIP 等需求
- 管理需求：运维查看每个业务的流量、限制每个业务的流量速率
- 服务管理：内网流量不支持使用 SNAT，是否需要支持 IPv6（貌似是支持 v6）
- 考虑特殊的情况：公网 IP 被封后如何快速方便的摘除掉
DPVS 的 SNAT 实现原理详解
通过上述内容，可以大概了解 SNAT 的基本实现原理，下边通过代码层面来分析其实现细节。主要根据数据包的流向为思路，来分析 inbond 和 outbond 方向的数据包流程。
（一）outbond 方向数据包处理流程
outbond 方向是指数据包从内网服务器 -> DPVS -> 外网服务器（如 baidu.com ）
假设内网服务器需要访问外网某个功能接口，请求数据包到达了 DPVS 服务器。数据包从网卡某个队列 queuex 进入后，被 cpux 接收并开始相关的逻辑处理。收包路径大概包括如下：
- netif_loop -> lcore_job_recv_fwd -> lcore_process_packets -> netif_deliver_mbuf
- netif_deliver_mbuf 函数中根据 packet_type 分别调用相应的 func 函数，func 类型主要包括：ipv4、ipv6、arp 三种类型。这里主要以 IPv4 分析 SNAT 整个过程。
- IPv4 类型的包处理函数是 ipv4_rcv ，经过 IP 层相关检查和校验处理后，调用 INET_HOOK 来执行相关的钩子函数，这里调用的是 INET_HOOK_PRE_ROUTING 位置钩子，包括： dp_vs_pre_routing & dp_vs_in 函数，核心代码入口在 dp_vs_in 里边。
在 dp_vs_in 中其实调用的是 __dp_vs_in 函数，主逻辑入口在这个函数中体现：
- 首先调用协议查找函数 dp_vs_proto_lookup ，确认此数据包是哪种协议类型，如 TCP 或 UDP 等，每种协议的相关处理逻辑不同，后续的相关操作会根据对应协议注册的回调函数来执行。
- 假设本次是请求是首包，需要调用 proto 的 conn_sched 函数进行连接的初始化和调度，TCP 的连接调度函数是 tcp_conn_sched 。
- 调度时，只有 TCP syn 包才能触发正常调度流程。首先，根据数据包的相关数据确认该包是否属于我们配置的服务，调用 dp_vs_service_lookup 函数进行查找，不过这里查找到的 service 类型是 match 方式。如果找不到响应的 svc 就跳出 SNAT 主流程。
- 找到 svc 后，调用 dp_vs_schedule 进行主调度流程，并创建初始化新的连接 Entry。调用 svc->scheduler->schedule 函数，从 RS 列表中挑选出一个 RS 作为 dest对于 SNAT 模式，调用 dp_vs_snat_schedule() 函数此时已确认 dest 作为源 IP 地址，调用 sa_fetch 根据源地址选择相对应的源 port调用 dp_vs_conn_fill_param 将相关数据赋值到 param 变量中去。
- 确定相关参数后，调用 dp_vs_conn_new 建立初始化新的连接条目。dp_vs_conn_alloc dp_vs_conn_hash
- 连接调度成功后，根据模式，SNAT 初始化方向为 DPVS_CONN_DIR_OUTBOUND 不同于其他模式。
- 调用 proto 的 state_trans 函数，进行相关协议状态机的转换。
- 调用 xmit_outbound 将数据包发送出去。neigh_output
到此从 SNAT 数据包的接收、处理、转发等过程，完成 SNAT outbond 方向的整个流程。
（二）inbond 方向数据包处理流程
inbound 方向是指数据包从外网服务器（如 baidu.com） -> DPVS -> 内网服务器
内网服务器发送请求数据包后，外网服务器执行相关操作，发出响应数据包，此数据包到达了 DPVS 服务器。此时 DPDK 驱动程序会根据关键字段进行 FDIR 规则匹配，数据包从同样的网卡度列 queuex 进入后，被 cpux 接收并开始相关的逻辑处理，这样整个连接都是被同一个 cpux 来处理的。收包路径大概包括如下：
在 dp_vs_in 前的收包处理流程和 outbond 基本一致，这里就不再罗列。
dp_vs_proto_lookup
xmit_inbound
不断的重复 outbond 和 inbond 流程，就能够通过多次数据包的交互完成连接过程中业务的传输，从而实现 SNAT 功能。
（三）SNAT 其他问题
- ICMP 处理问题 。内网服务器 ping 外网是一个很常见的需求，从实验测试和代码分析来看，响应 ICMP 包可能命中到其它网卡队列，导致连接表 miss 的问题，这个问题可以通过 FDIR 功能将 ICMP 包都定位到固定的网卡 queue 上，这样可以简单的方式来解决这个问题。
- 配置方式 。同一个业务配置信息，需要至少配置 3 个 service，其实也不算是大问题，如果用程序自动管理配置的话也就没什么了。
- sapool配置只能用 dpip 。wan ip 配置时需要携带 sapool 选项，目前发现貌似只能用 dpip 命令行工具来进行配置，keepalived 配置不支持 sapool 选项。
总结先到此为止，在使用过程中遇到的问题还会再来补充更新。
