NoOps

Ops make no ops | Ops的目标是没有Ops,嗯!

Juniper防火墙,LVS DR mode 与 HTTP keepalive 丢包问题追查

作者: |   6,177 浏览  | 

最近业务上新上了 Juniper 的防火墙。在防火墙上线后发现,原先业务上的调用同网段内 LVS VIP 的 HTTP 长连接在使用一段时间后频繁出现丢包重传现象,而其它网段连接此 LVS IP 则没有丢包。

 

概要

Juniper SRX 防火墙默认规则关于 TCP 连接建立的判定方法以及相关配置。

同网段中向DR模式 LVS 发出的TCP包,其回包不通过网关而是直接返回到发起机器。

使用python3 + urllib3 模拟 HTTP keepalive 长时间保持连接情况

 

症状

应用服务器上向 LVS IP 发的 HTTPS 请求丢包非常之惨烈。

first cap2

网络拓扑

先上一张网络拓扑,方便说明问题。

网络拓扑图

LVS IP 是公网IP

Juniper 防火墙设备同时充当默认网关。

 

复现、调查与分析过程

复现

为了能够在不影响业务的情况下方便调查,稳定复现问题是关键。

在复现的方法上想了很多办法,耗费了最多时间。

第一种方法,也是直接想到的方法,尝试用 curl。

但是连接丢包是在长连接建立一段时间后才发生的,所以使用 curl 需要 1) 模拟长连接 2) 长连接需要保持一段时间。

查阅手册,发现使用 curl 保持长连接不难,但是由于内网请求速度非常快,因此要保持长连接一段时间难以做到。

第二种方法,使用 python 的urllib3。

查了下urllib3的手册,写出下面代码。

运行该代码约20秒后,输出卡住了。重复多次稳定复现。

调查

先在业务机器上和 Real Server 上抓包,发现连接建立一段时间后一定会出现丢包,然后整个连接被关闭。

后尝试在 LVS 机器上和业务机器上抓包分析。

LVS 上抓包图:

LVS上抓包

业务机器上抓包图:

业务机器上抓包

蓝色的行为同一个包在 LVS 和业务机器上的同一个包。

通过在 LVS 机器和业务机器上抓包,确定是防火墙硬件将包丢弃。

至此,将调查重点放在防火墙配置上。

可疑的防火墙配置

现在问题已经明确为:

因为某个原因或者配置,防火墙将超过20秒的长连接的包丢弃了。

检查防火墙的配置,找找与 “20″ 相关的项目,在其默认配置中有所发现

其中

set security screen ids-option untrust-screen tcp syn-flood timeout 20

这一条其意义是:TCP 连接的建立必须在20秒内完成,否则该连接请求将被丢弃。链接

至此,已大致可以确定问题所在了:防火墙将超过20秒的连接强行关闭了。

LVS DR模式

在 LVS DR 模式下,请求方向 LVS 发起 TCP 请求,但是 TCP 请求的回包并不从 LVS 返回,而是由 Real Server 直接返回给请求方。

如果请求方与 LVS 不在同网段,则返回的 TCP 包需要通过网关转发给请求方。但是如果请求方与 LVS 是同网段且网关是防火墙设备,那情况要稍微复杂些。

如图:

TCP包流向图

TCP包流向图

注意到经过防火墙的 TCP 包是单方向的。防火墙一直认为 TCP 连接没有建立。

 

解决方法

根据之前的分析,想到的解决方法有两个:

  1. 调整防火墙配置和应用程序的配置,让 HTTP 长连接保持一个合适的时间。
  2. 在该网段搭建内网 LVS,流量不经由防火墙。

13 Comments

  1. wilbur
    2014/10/20 at 6:57 下午

    赞一个

  2. tomasea
    2015/02/16 at 4:22 下午

    截的图基本都说明不了啥问题啊,没有看到关键的丢包的信息

    • jiangwei
      2015/02/16 at 4:31 下午

      很说明问题啊。
      红色的记录,序列号都是重复的!

  3. JWD
    2015/09/08 at 10:06 上午

    你这种情况VIP是内网地址,同时对外有做了NAT的外网地址。
    同一个网段服务器连接的是VIP的外网地址,而非内网地址。
    经过的防火墙又没对这个网段->VIP外网地址做SNAT才出现的吧?
    我的理解正确吗?

    • jiangwei
      2015/09/08 at 10:24 上午

      VIP是外网地址哦
      老实说,你的评论我没太看懂

      • JWD
        2015/09/08 at 10:41 上午

        VIP是外网,那这几个服务器之间互联的是内网?或与VIP不同的另一个网段?
        如果VIP跟服务器都是同一个网段,应该不经过防火墙的啊。
        我是想搞清楚这种问题什么情况下会发生?
        请赐教,谢谢。

      • JWD
        2015/09/08 at 10:48 上午

        我的意思是在防火墙上对Box1做个SNAT是不是就解决这个问题了?

  4. JWD
    2015/09/08 at 10:59 上午

    还有个问题请教。
    在防火墙缓存里,连接进站时,VIP的MAC地址是LVS的MAC地址x:x:x。
    但返回数据时,VIP的MAC地址是RealServer的MAC地址:y:y:y。
    这样不会有问题吗?不会被防火墙拒绝吗?

    • JWD
      2015/09/08 at 3:33 下午

      这个问题我搞清楚了,是我把LVS结构搞错了。RealServer是用eht0给防火墙发数据,而不是VIP。
      但是我对你说的现象又有疑问,为什么同一个网段访问VIP,会通过防火墙呢?不是直接就可以访问的吗?

      • jiangwei
        2015/09/08 at 3:37 下午

        机器上的路由表写着:
        0.0.0.0 Gateway-IP 0.0.0.0 UG eth0
        VIP 是外网地址,会匹配到0.0.0.0 然后发到Gateway-IP,也就是FW上

        • JWD
          2015/09/08 at 5:27 下午

          DR模式不是VIP要跟RealServer在一个网段的吗?跟发起连接的服务器也在同一个网段,那就无所谓外网内网了。
          如果同一个网段还要走网关,那是不是发起连接的服务器子网掩码或者路由优先级不对?
          我研究了一天,感觉这个问题比较奇怪,没有理论依据。
          一般用NAT的外网IP才会出现这种情况。

        • JWD
          2015/09/09 at 8:23 上午

          我明白咋回事了。DR模式可以用不同网段。这么做不用SNAT是会出这个问题。

  5. 2016/10/24 at 9:47 下午

    我这也出现了 经过SRX能ping通服务器 但是数据不能传送过去

发表评论