一探究竟 | eBay流量管理之DSR在基础架构中的运用及优化
供稿 | eBay Infraops Team
作者 | 梅南翔
审稿 | 杨胜辉
编辑 | 顾欣怡
本文4536字，预计阅读时间14分钟
更多干货请关注“eBay技术荟”公众号
导读
本文对负载均衡器的 DSR(Direct Server Return)模式 进行了原理分析，并以业界普遍使用的F5 LTM+CentOS为例，探究了DSR配置的关键技术点，最后借助 Linux内核分析 ，对F5提供的官方步骤提出了优化方案。希望能对读者有所启发和帮助。
一、背景
在现代企业内部， 负载均衡器 (LoadBalancer，以下简称 LB )被大量使用。负载均衡器的常用模式如下图1所示:
图1 负载均衡的常用模式（代理模式）
（点击可查看大图）
负载均衡的常用模式可概述为下（详情可见： 分享 | eBay流量管理之负载均衡及应用交付 ）：
1. 客户端向负载均衡器提供的虚拟IP地址VIP发送请求 （CIP → VIP） ；
2. 负载均衡器从提前配置的多个子网IP地址中选择一个(SNAT IP)，替代客户端请求的源IP，并依据负载均衡算法，选择一个服务器IP作为目的IP，发送请求 (SNIP → SIP) ；
3. 服务器处理后将响应结果发回负载均衡器 （SIP → SNIP） ；
4. 负载均衡器将最终结果返回给客户端 （VIP → CIP ） 。
但负载均衡器的这种 经典SNAT模式 ，在基础架构运维中有以下 缺点 ：
1. 由于信息量的因素，网络请求的回包往往会比请求包大很多。一般达到 10倍 [1] ， 20 Mbps 的请求，其回包可能达到 200 Mbps 。这样一来，由于回包也是经过LB，就会大量增加LB的带宽使用，减小LB的有效处理容量。
2. 基础架构的服务(DNS,MAIL,LDAP等）工作在TCP/UDP传输层之上，所以无法像其它工作在HTTP协议以上的应用那样，用HTTP header里边的X-Forwarded-For字段来保存客户端真实IP。 这些基础架构服务的请求包在被LB进行SNAT之后，客户端的真正IP被替换为LB的SNAT IP。 这样造成的结果就是，后端服务器无法知道真实的客户端IP是什么，给问题排查、攻击检测、运行指标统计等运维活动带来极大不便。
而DSR (Direct Server Return,服务器直接返回)技术 （其在Layer 2实现时叫Direct Routing，F5称之为nPath）， 顾名思义，就是让后端服务器绕开LB直接回包给客户端 （如下图2 [2] ），从而实现节省LB带宽和获取客户端真实IP的目标。
图2 DSR数据流图
（点击可查看大图）
二、原理
那么DSR又是通过怎样的独到之处，跟LB的看家本领SNAT叫板的呢？ 原来，在DSR模式下，当网络请求包到达LB时，LB并不做SNAT，而是把包的源IP地址原封不动地转发给后端服务器。 当后端服务器拿到请求包以后，由于包里边携带了客户端的源IP地址，它就可以直接将回包通过网络路由给这个源IP地址，到达客户端手中。
不过，等等，这幸福来得也太突然了吧？让我们来仔细分析一下，看看这中间的重重险阻在哪里。
设想一下，服务端如果傻傻地用[src=SIP；dst=CIP]回包，那么客户端收到这个包以后，会怎么样？——当然是丢掉。为什么？因为客户端也不傻，它知道自己请求的是VIP，所以期待的是VIP给它的回包。至于这个服务端SIP又是个什么鬼？不需要，丢弃即可。因此，为了绕过客户端这道安全防线，聪明的工程师们想到了一个绝好的办法， 就是让服务端伪装自己的IP地址为VIP，用[src=VIP；dst=CIP]回包，以期能骗过客户端，让客户端误以为是LB的VIP回复给它的。
那是不是我们直接在服务端网卡上配置VIP，让服务端通过该网卡应答就可以？答案是No，因为这样虽然确保了客户端收到的应答包是[src=VIP,dst=CIP]，但带来的问题是：服务端和LB将同时应答ARP，引发IP地址冲突。所以，服务端伪装VIP可以，但一定要低调，万万不可让其他人知道—— 有一个绝好的办法，就是将VIP偷偷地配置到loopback网卡或者tunl0这些本地的网络接口上 ，既骗过了内核，让它以为真的有这个合法IP地址，又不会被外边的设备发现，一石二鸟，想想都激动。
还有一个问题，怎么样才能让服务端内核以[src=VIP,dst=CIP]的组合回包呢？由于内核是严格按照(src→dst, dst→src)的方式进行回包的，那让服务端内核如此回包的最好办法，当然是让LB转发[src=CIP,dst=VIP]的包给服务端的内核啦。但是，这听上去有点像天方夜谭，服务端的VIP是一个“偷偷摸摸”的配置，所以LB发出的[src=CIP,dst=VIP]的IP包，在路由时，一定是找到了LB上的VIP，绝无可能被路由到服务端去。怎么办？我可太“南”了…
针对上述问题，有一个办法，就是LB跳过L3三层路由，直接把[src=CIP, dst=VIP]的IP包，塞到一个目标MAC地址为服务端网卡MAC地址的L2网络包里，送达服务端网卡 （相当于将从客户端到LB的L2数据包更换一下目标MAC地址。对应于NAT，这种实现方法也被称作MAT，即MAC Address Translation [3] ，参见图3）。
图3 L2 DSR替换请求包的目标MAC地址
（点击可查看大图）
这个方法实现简单，但有一个硬伤，就是当LB和后端服务器不在同一个L2网络的时候就无能为力了。所以我们还是回到L3网络来考虑这个问题，也就是如何让LB把[src=CIP,dst=VIP]的IP包转发给服务端的内核。 如果把网络通信类比于传统信件，那我们现在的需求就是，让LB送一封“收件人”为VIP的信件，并且保证该信件是送到服务端而不是LB自己。 通过这一类比，我们不难想出一个好办法，就是让LB给服务端送一封信([dst=SIP])，然后在这封信里再嵌入一封“收件人”为VIP的信([dst=VIP])；同时在外层信封上标注——这里边装的不是TCP，也不是UDP，而是另外一封信（协议）。这样当服务端收到外边的信封以后，它继续拆开里面的信，就可以获取到[src=CIP,dst=VIP]的数据了。
事实上，这种做法就是 网络隧道(Network Tunnel) 的概念——将一种网络协议包(inner packet)作为payload嵌入外层网络协议包中，并利用外层网络协议进行寻址和传输，从而实现原本割裂的内层网络像隧道一样被打通了的效果。
最常见的网络隧道就是我们使用的VPN ：当拨入VPN之后，我们就可以访问10.x.x.x这种内网地址了。很显然是10.x.x.x这种IP包被封装进了某种特殊的通道，也就是一些基于公网VPN协议的网络隧道。 类似于VPN，在DSR这种场景下，我们就是要将访问VIP的IP包通过至SIP形成的隧道进行传输。 Linux支持的IP in IP协议主要有 IPIP 和 GRE 两种，IPIP隧道不对内层IP数据进行加密 [4] ，所以它最简单，效率最高，如图4所示 。由于是内网可信网络，因此选用IPIP这种最简单高效的隧道协议。
图4 IPIP隧道协议
（点击可查看大图）
我们可以让LB生成这样的一个IPIP包[src=CIP, dst=SIP, protocol=IPIP, payload=[src=CIP, dst=VIP] ]并发出去。由于外层的IP包目标地址是服务端IP，所以外层IP包顺利到达服务端内核；服务端内核拆包一看，这里边又是一个IPIP包，于是进一步解包，发现是[src=CIP,dst=VIP]的包。 这时内核检查dst=VIP是本地一个合法的IP地址（因为本地网卡已经配置了VIP），于是欣然接受，并根据TCP/UDP的目标端口转给应用程序处理。 而应用程序处理完，就顺理成章地交由内核，按照(src→dst, dst→src)的原则，产生[src=VIP, dst=CIP]的IP包进入网络路由至客户端，问题解决！此时的数据流图参见下图5：
图5 使用IPIP隧道的DSR数据流图
（点击可查看大图）
三、探究
下面，我们以业界普遍使用的 F5负载均衡器 LTM + CentOS 7 为例，实战分析探究一下DSR配置的关键技术。
Step 1
如下所示，在LB上配置一个有2个成员的负载均衡池(pool)，并创建一个VIP对应到该pool：
-
该pool指定的profile为IPIP，表示LB和该pool的成员通讯，走IPIP隧道；
-
要关闭PVA-Acceleration，因为DSR模式下，client不再直接与VIP建立TCP连接，所以用不到L4的PVA硬件加速；
-
该VIP指定translate-address disabled，表示不对请求该VIP的流量进行SNAT。
（点击可查看大图）
Step 2
此时，我们在server端先不做任何配置，直接从client去telnet VIP，并且从server端分别用VIP和CIP抓包（如表1），看有什么现象发生。
表1 分别用VIP和CIP作为条件抓包
（点击可查看大图）
从wireshark中可以看到，LB在收到[CIP,VIP]的请求后，产生一个IPIP的包[src=CIP, dst=SIP, protocol=IPIP, payload=[src=CIP, dst=VIP] ]。这时候，由于我们还没有从服务端正确地配置IPIP Tunnel和VIP， 所以这个包无法正确地被识别和处理， 导致了 3次 SYN包的重传和 1次 RST （图6中的包3,5,7和9)，同时服务端以ICMP的形式告诉client，由于目标IP地址无法抵达的缘故，之前的包无法被正常传递 [5] （图中包2,4,6,8,10）。
图6 LB通过IPIP隧道发到服务端的数据包
（点击可查看大图）
Step 3
进一步分析，由于服务端的内核还没有加载IPIP模块，所以它不能识别Protocol=IPIP的数据包，无法解析出嵌入在IPIP包里的内层IP数据包。由于VIP只出现在内层IP包里，因此以VIP作为filter抓包，自然是抓不到了。 现在我们尝试让内核加载IPIP模块并再次抓包，看它能否识别并解开内层IP包。
我们重新做一次表1的telnet和tcpdump，相比于上一次的抓包，这次我们以VIP作为filter就可以抓到内层IP包了。 这说明内核加载IPIP模块后就可以识别Protocol=IPIP的数据包了。 但到这里，由于我们并没有在服务端的任何网络接口(interface)上配置VIP，所以服务端仍然未作出回包处理。
Step 4
下一步，就是将VIP配置到tunl0或者lo上，让内核识别到这是一个合法的IP地址。在F5提供的参考配置文档 [6] 中，就是将VIP配置到loopback网卡lo:1上，并在tunl0上配置SIP。但是仔细思考一下，F5官方提供的这个配置并不令人十分满意——根据我们前边的分析，我们只要在loopback或者tunl0这类本地网卡上配置VIP，让内核认为只是一个合法的地址就行了，为什么还要多此一举地往tunl0上配置SIP？
既然有这个疑问了，我们索性逐步推进，看看， 如果不在tunl0上配置SIP到底会发生什么？
Step 4.1
首先，我们在lo:1上配置VIP，并且不在tunl0上配置任何IP地址。
再次重做telnet，并用CIP作为filter抓包（语句见表1)，结果如图7所示，只能抓到客户端到服务端的请求包（奇数行为eth0收到的外层包，偶数行为tunl0收到的内层包， 总共是 1 次 SYN+ 3次 SYN重传，和 1次 RST ）。
图7 服务端未回包
（点击可查看大图）
可见服务端内核确实收到了[dst=VIP]的包，但既没有送给应用程序，也没有回包，那是内核将这些包丢弃了吗？此时用dmesg命令检查一下内核日志，发现在对应时间段有 5条 下述日志：
这个报错是什么意思呢？原来，网络攻击者（例如DDOS）在攻击时，都会伪装自己的IP地址（IP Address Spoofing），以绕开IP源地址检查或是防止DDOS回包回到自身。由于源地址无法路由可达（route back），这时服务端就会不断保持连接并等待，直到连接超时，造成资源耗竭无法正常提供服务。
为了应对这种攻击，Linux内核加上了一个叫做 反向路径过滤（reverse path filtering [7] ）的机制，这个机制会检查，收到包的源地址是否能从收包接口(interface)路由可达，如果不可达，就会将该包丢弃，并记录 “martian source” 日志 。回到我们问题的场景，tunl0在收到内部IP包[src=CIP, dst=VIP]这个包之后，就会去尝试验证从tunl0这个接口能不能连通CIP=10.218.98.18，由于tunl0无法路由到CIP，所以出现了上述的报错。
那有什么办法，既能够保证一定程度的安全，又可以支持DSR这种场景呢？rp_filter这个参数有 3个 值 [8 ] ，如图8，其中Loose mode下，只要从任何接口可以路由到源IP地址（而不限于收包接口），就不做丢弃处理。所以， 我们可以将tunl0的rp_filter设置成 2 ，这样由于CIP可以经由eth0路由，验证应该会成功。
图8 Linux内核关于rp_filter的定义
（点击可查看大图）
Step 4.2
如下所示， 设置tunl0的rp_filter= 2 ，也就是对从tunl0进入的IP网络包，如果其源IP地址可经由机器上任意网卡(例如eth0)路由到，就认为它是一个合法的报文。
然后重新做一次telnet和tcpdump，奇怪的是，我们依旧没有看到服务端内核回包，并且内核日志仍旧报 “martian source” 的错误。这又是怎么回事呢？看来，F5官方文档让在tunl0上配置SIP的要求似乎是不能省略的。
Step 4.3
接下来我们往tunl0上配置SIP，然后重做telnet和tcpdump。不出所料，此时服务端给出了正确的DSR回包（限于篇幅，此处略去抓包结果）。
到这里，DSR误打误撞地完成了配置，但我心里还有些难以平复—— Tunl0网卡的作用在于接收IPIP隧道内的内层IP包，但是服务端内核在回包时，是直接将[src=VIP, dst=CIP]的IP包经由eth0路由出去的，根本就没有tunl0什么事。 所以tunl0上理论上不需要配置任何IP，但为什么在tunl0上配置SIP以后，就能解决"martian source"的问题呢？
怀着这个问题，我在网上找了很久的答案都没找到，最终通过eBPF对linux内核源码进行分析， 发现在linux的rp_filter代码中，如果网络接口（这里是tunl0）不配置任何ip（ifa_list == NULL)，那么就会返回验证失败。
具体请参考github链接：
https://github.com/centurycoder/martian_source
（点击可查看大图）
Step 5
既然linux内核要求tunl0上必须配置IP地址，那是不是意味着我们必须按照F5提供的官方步骤进行配置呢？不是的，我们前面已经分析，只要是在loopback或者tunl网卡上配置VIP骗过内核就行， 那我们就索性将VIP直接配置到tunl0网卡上，这样既实现了tunl0上有IP地址的要求，又满足了VIP是一个合法目标地址的要求。
我们将第4步的配置回退后，在tunl0上配置VIP和rp_filter，如下所示:
然后按照表1重新做一次telnet和tcpdump，如图9所示，客户端和服务端通过DSR成功完成TCP的3次握手（ 1 是eth0端口上抓到的外层包， 2 是tunl0上抓到的内层包，它们其实是同一个 SYN包 ，所以被wireshark标记为TCP Out-of-Order； 3 是服务端回复的 SYN/ACK包 ，它不走Tunnel，所以没有成对出现； 4 和 5 是客户端发的 ACK包 ，分别是eth0抓到的外层包和tunl0抓到的内层包，被wireshark误认为是重复的ACK）。
图9 成功的DSR通讯
（点击可查看大图）
四、总结
到这里，我们就完成了DSR的原理分享和探究，并且通过对原理以及Linux内核源码的分析，对F5官方提供的步骤进行了解析和优化。总的来说，从运用方面来看， 相比于SNAT模式，DSR在提高LB带宽容量、保持客户端真实IP等方面有很大优势。 但在选择DSR或者SNAT模式时还要考虑实际运用场景。 DSR往往更适用于LB仅用作负载均衡功能的场景 ，而如果LB还承担SSL offload、Cache、加速或者其它安全相关功能时，则只能选取经典SNAT模式 [9] 。希望本文能对各位读者理解和运用DSR技术有所帮助和启发。
参考资料：
[1]https://kemptechnologies.com/au/white-papers/what-is-direct-server-return/
[2]https://www.loadbalancer.org/blog/15-years-later-we-still-love-dsr/
[3]https://www.haproxy.com/support/technical-notes/an-0053-en-server-configuration-with-an-aloha-in-direct-server-return-mode-dsr/
[4]https://developers.redhat.com/blog/2019/05/17/an-introduction-to-linux-virtual-interfaces-tunnels/
[5]https://tools.ietf.org/html/rfc792
[6]https://techdocs.f5.com/en-us/bigip-15-0-0/big-ip-local-traffic-manager-implementations/configuring-layer-3-npath-routing.html
[7]https://www.slashroot.in/linux-kernel-rpfilter-settings-reverse-path-filtering
[8]https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
[9]https://devcentral.f5.com/s/articles/the-disadvantages-of-dsr-direct-server-return
您可能还感兴趣：
干货 | Rheos SQL: 高效易用的实时流式SQL处理平台
分享 | eBay流量管理之Kubernetes网络硬核排查案例
:point_down:点击 阅读原文 ，一键投递
