使用BFE如何实现地址透传

在经过负载均衡转发后,客户端地址如何透传到下游的服务是一个常见的问题。本文将说明在BFE中是如何解决这个问题的。

1. 问题说明

在经过BFE转发后,RS无法获得原始的客户端IP地址,而只能获得BFE实例的IP地址。

如图1所示,客户端的IP地址为1.2.3.4,在经过BFE转发后,BFE和RS建立了新的TCP连接,RS只能看到BFE的地址10.1.0.1。

很多应用都需要获取请求原始的客户端IP地址。需要提供机制将原始的客户端IP地址传递到RS。


图1 经过BFE转发后客户端地址的变化

2. BFE的客户端地址透传方案

BFE在扩展模块mod_header中默认提供了捎带客户端IP地址和端口的功能。只要在BFE启动时配置加载mod_header,在转发后请求中就会包含这两个信息。

在经过BFE转发后,在HTTP请求的头部会增加2个字段:

  • X-Real-Ip:用于传递原始的客户端IP地址
  • X-Real-Port:用于传递原始的客户端端口

注:

  • mod_header的实现位于
    https://github.com/bfenetwork...
  • mod_header的说明文档位于
    https://github.com/bfenetwork...

3. 为什么不使用x-forward-for

曾经有一个朋友在《深入理解BFE》的Github讨论区中提了一个问题:为什么不使用X-Forwarded-For来传递客户端IP地址呢?

BFE使用独立定义的“X-Real-Ip”是为了避免“X-Forwarded-For”被伪造。

如果请求在到达BFE时已经包含了“X-Real-Ip”字段,BFE会将这个字段的值重写为BFE所见的客户端IP地址,从而避免这个字段被伪造。

但是BFE不能使用类似的“重写”方案来避免x-forward-for字段的伪造。

可以看看下面的两种可能的场景:

  • 场景一: 如果请求中本来没有包含X-Forwarded-For头部
    BFE可以添加新的头部,

    X-Forwarded-For: client-ip, bfe的地址
  • 场景二:如果请求中已经包含X-Forwarded-For头部,如,

    X-Forwarded-For: client1, proxy1, proxy2, proxy3

    那么BFE需要将自己的地址添加到末尾

    X-Forwarded-For: client1, proxy1, proxy2, proxy3,BFE的地址

    在这种情况下,client的地址可能为伪造。但是,BFE不能改写X-Forwarded-For的值,因为需要保留X-Forwarded-For的内容供其它可能的分析。

4. 其它信息的透传

除了原始的客户端IP地址,可能还需要BFE向下游服务透传其它信息,如本次请求所访问的服务端IP地址(VIP),本次请求所使用的TLS/SSL协议版本等。在某些场景中,由于历史的原因,可能也需要对于透传客户端IP地址的头部名称做特殊的设置。

在mod_header中,可以对每个租户提供一张配置表,可以针对符合条件的请求,对头部做指定的动作。


图2 租户的mod_header配置表

在配置表中,使用BFE的条件表达式来描述匹配的条件。对请求(Request)和响应(Response)的Header可能执行的操作包括设置、添加、删除等。针对同一个匹配条件,可以执行多个操作。

为了便于操作,在mod_header中还提供了一些内置的变量,用于在配置图2中的action时使用。如:

  • %bfe_cip,代表客户端IP (CIP)
  • %bfe_vip,代表服务端IP (VIP)

在下面这个配置的例子中,对于属于“example_product”的请求,如果请求的Path前缀为“/header”,则设置名为X-Bfe-Vip的Header,用于向下游服务传递服务端IP地址。

{

"Version": "20190101000000",

"Config": {

"example_product": [

{

"cond": "req_path_prefix_in(\"/header\", false)",

"actions": [

{

"cmd": "REQ_HEADER_SET",

"params": [

"X-Bfe-Vip",

"%bfe_vip"

]

},

],

"last": true

}

]

}

}

5. BFE如何从上游获得客户端地址

在实际部署中,在BFE的上游经常会使用四层负载均衡,以实现多个BFE实例间的流量均衡,并解决BFE的高可用。

流量在经过四层负载均衡器的转发后,BFE同样也无法直接获得原始的客户端IP地址,而只能看到四层负载均衡器的内部地址。


图3 经过四层负载均衡器后地址发生变化

由于很多四层负载均衡器不能像BFE这样修改HTTP请求头部(部分的原因是因为这样的功能对于四层负载均衡器来说太复杂;部分的原因是因为在HTTPS的场景下四层负载均衡器无法“看见”和修改请求的内容),所以需要使用更底层的机制。

常见的方案有两种:

  • 方案1:使用TOA(TCP Option Address)
    通过在TCP Options中插入客户端地址方式,将客户端地址从四层负载均衡器携带到BFE。
    LVS这样的开源负载均衡软件和F5这样的商用负载均衡产品都支持开启TOA。

    如果使用TOA方案,在BFE所在的服务器,需要安装TOA插件。这样BFE从socket中读取到的客户端IP地址就是原始的客户端IP地址。
    TOA的详情可以参考以下文章:
    https://zhuanlan.zhihu.com/p/...
    https://www.jianshu.com/p/e77...

  • 方案2:使用Proxy Protocol
    Proxy Protocol是由HAProxy发明的。其主要思想是:在发送数据之前,首先发送一个特殊的头信息,用于传递客户端IP地址、端口等信息。
    HAProxy这样的开源负载均衡软件和F5这样的商用负载均衡产品都支持开启Proxy Prococol。
    如果使用Proxy Prococol方案,需要修改BFE的配置。在bfe.conf中,需要将Layer4LoadBalancer设置为"PROXY"。

    [Server]

    # type of layer-4 load balancer (PROXY/NONE), default NONE

    Layer4LoadBalancer = "PROXY"

    可以参考
    https://github.com/bfenetwork...。
    Proxy Protocol的详情可以参考以下文章:
    https://www.haproxy.org/downl...
    https://www.jianshu.com/p/cc8...

6. 总结

在向下游服务透传原始客户端IP地址等信息方面,BFE提供了完整的支持。

在包含四层负载均衡器的场景中,可以使用TOA或Proxy Protocol将原始的客户端IP地址从客户端传递给BFE。

欢迎关注“BFE开源项目”微信公众号,获得本项目的更多更新。谢谢!

以上是 使用BFE如何实现地址透传 的全部内容, 来源链接: utcz.com/z/267713.html

回到顶部