F5常用5种插入客户端源地址方法简述

F5常用5种插入客户端源地址方法简述
F5常用5种插入客户端源地址方法简述
常旭
2014年8月
目录
一、引言 (3)
二、测试环境 (4)
2.1、网络拓扑 (4)
2.2、基础配置 (4)
三、应用层常用方法 (5)
3.1、X-Forwarded-For (5)
3.1.1、配置步骤 (5)
3.1.2、验证 (6)
3.2、插入Header (7)
3.2.1、配置步骤 (8)
3.2.2、验证 (8)
3.3、插入Cookie (9)
3.3.1、配置步骤 (10)
3.3.2、验证 (10)
3.4、TCP-Option (11)
3.4.1、配置步骤 (12)
3.4.2、验证 (13)
3.5、TCP-payload (15)
3.5.1、配置步骤 (16)
3.5.2、验证 (17)
四、总结 (18)
一、引言
随着IT环境的高速发展,解决我们日常各种需求的应用像雨后春笋般以一个惊人的速度爆发式增长,而其中大部分应用为了抢占市场都存
在开发周期短的问题。

如果基于这样的一个背景让应用开发人员将功能是否满足需求、可用性、应用性能、安全性、是否按时上线、后期维护复杂度等几个现实问题做优先级排序,那么安全性肯定会排在最后。

但实际上现在大多数应用在设计业务逻辑时就已经对安全有了一定要求。

比如最近一段时间经常在项目上遇见后端服务器需要查看客户端源IP地址的需求。

这实际上就是一个简单的安全手段,通过查看客户端源IP地址来达到审计的目的,或者通过ACL列表过滤客户端请求等。

我们在讨论如何让后端服务器看到客户端源IP地址前先来看一下F5的几种部署模式。

首先是三角传输(即npath模式),这是一种非常古老的部署模式,主要应用于响应包明显大于请求包的场景(如请求包大小为10k,服务器回包1000M!有点夸张),但随着设备性能的不断提高且该模式配置极其复杂(需要服务器开启loopback功能,并通过iptable关闭ARP响应功能,但不同Linux版本关闭iptable命令均不同)目前已经退出了历史舞台。

其次,第二种是路由模式,由于其工作原理类似于路由器而得名。

通过这种部署模式BIG-IP就可以满足需求,让后端服务器看到客户端源IP地址。

既然这样,问题不就解决了吗??但往往生活就是这样不尽如人意。

比如后端服务器和客户端处于相同网段,当服务器看到客户端IP地址后直接通过二层回包,这样客户端收到的数据包由于请求目的地址和回包地址不同而自动被拒绝。

类似场景就比较尴尬了,即需要让后端服务器看到客户端源地址又不能让后端服务器看到客户端源地址,在这样一个矛盾的现实案例中我们要想同时满足网络和应用的需求,只能通过非常规的方法来
进行处理。

最近遇到了好几个类似的问题,但由于应用程序的不同客户端IP 地址插入的位置也不尽相同,本文通过汇总几种常用的插入IP 方式进一步展现F5在软件定义方面的强大优势,但由于应用快速发展及个人经验等客观因素影响,无法将所有方法一一进行阐述,如果哪位兄弟们有其他更好的方法烦请告诉我一下,非常感谢(联系方式mars_crow@/doc/1112248700.html,)。

二、测试环境
2.1、网络拓扑
在笔记本上安装VMware,并开启四台虚拟机。

其中两台为Virtual Edition-v11.4.1,另外两台为后端真实服务器。

访问流程如上图,通过IE 浏览器访问第一台VE的VS,由于Pool member是第二台VE的VS,因此流量自动转发到第二台VE,并最终分配到后端两台真实服务器。

本次测试所有iRule均添加到第一台VE,所有iRule验证的工作均在第二台VE 上完成,如果验证符合预期且页面能正常打开证明测试成功。

2.2、基础配置
三、应用层常用方法
3.1、X-Forwarded-For
X-Forwarded-For简称XFF头,它虽然不是RFC中定义的标准请求头信息,但市面上几乎所有HTTP代理及负载均衡设备均支持该功能。

标准格式如下:X-Forwarded-For:client1,proxy1,proxy2.
3.1.1、配置步骤
1.登录BIG-IP WebUI配置界面
2.选择Local Traffic下的Profiles
3.点击Create
4.选择HTTP profile模板
5.选择Insert X-Forwarded-For选项
6.在Insert X-Forwarded-For选择栏中选择Enabled
7.点击Clieck
8.选择Local Traffic下的Virtual Server List
9.选择测试VS
10.选择HTTP Profile选项
11.选择XFF-HTTP
12.点击Update
XFF-HTTP配置图:
VS绑定XFF-HTTP:
3.1.2、验证
1.登录第二台BIG-IP WebUI配置界面
2.选择Local Traffic下的iRule
3.点击Create
4.添加iRules(内容:log输出)
5.选择Local Traffic下的Virtual Server List
6.选择测试VS
7.添加创建后的iRules
8.点击Finished
9.登录SecureCRT
10.查看log输出内容
iRules 内容:
iRule配置图:
SecureCRT输出:
页面输出:
3.2、插入Header
有时在和应用开发人员沟通源IP地址这个问题时,他们不太希望我们插入的名字为X-Forwarded-For,反而可能是某个设备的名字、特殊定义字段等(如:infosec)。

因此,这个时候我们只能通过iRule来完成。

3.2.1、配置步骤
1.登录BIG-IP WebUI配置界面
2.选择Local Traffic下的iRules
3.点击Create
4.添加iRules
5.选择测试VS
6.添加创建后的iRules
7.点击Finished
iRule内容
注:
1、infosec为header名字
2、[IP::client_addr]为infosec值。

当然,由于事件为HTTP_REQUEST,如果使用[IP::remote_addr]也可以达到同样的效果。

3.2.2、验证
本次验证过程及配置步骤请参考3.1.2。

iRule内容:
SecureCRT输出:
页面输出:
3.3、插入Cookie
还有一种经常用的方式是将客户端源IP地址插入到指定的Cookie 中,后端服务器通过读取指定Cookie获得客户端源地址。

说到这里同志们是否想起了在Profile中有个Insert Cookie?之前我通过查看相关文档及培训PPT获得的信息是客户端首次发起访问请求后,数据包到达BIG-IP时BIG-IP不做任何操作。

当后端服务器响应后BIG-IP会自动插入一个包含客户端和真实服务器对应关系的Cookie,以此保持当前会话。

当客户端第二次发起请求时携带该Cookie,请求包到达BIG-IP后,这时候问题就出现了,文档的说明是BIG-IP先将该Cookie删除后再将请求转发给服务器,但通过抓包发现转发时Cookie未被删除,因此可能造成业务出现问题,需通过单独Rules将该Cookie删除。

当然这是题外话,我们言归正传,虽然Cookie本身存在很多问题,包括像数据大小的限制、用户配置、潜在被篡改的安全风险等等,但他的灵活性确实给我们带来了很大的方便。

我们这
次的方法就是将客户端的源地址插入到Cookie中。

3.3.1、配置步骤
1.登录BIG-IP WebUI配置界面
2.选择Local Traffic下的iRules
3.点击Create
4.添加iRules
5.选择测试VS
6.添加创建后的iRules
7.点击Finished
iRule内容
3.3.2、验证
本次验证过程及配置步骤请参考3.1.2。

iRule内容:
SecureCRT输出:
页面输出:
3.4、TCP-Option
以上三种方式的工作原理都是基于B/S架构实现的,简单、方便、好操作!但如果用户实际生成环境是C/S架构则以上方法全部歇菜。

如果我们告诉用户无法实现,显然摒弃了F5一贯高大上的定位。

其实对于应用而言,不论B/S架构还是C/S架构,他们上层应用协议可能不同,但对于OSI七层模型中传输层协议肯定是一样的,既然这样,TCP-option肯定是个不错的选择。

3.4.1、配置步骤
1.登录BIG-IP WebUI配置界面
2.选择Local Traffic下的iRules
3.点击Create
4.添加iRules
5.登录命令行模式
6.手动创建TCP-option Profile
7.选择测试VS
8.添加创建后的TCP-option Profile
9.添加创建后的iRules
10.点击Finished
TCP-option profile 命令
iRule内容
注:该rule背景是将分配至2.2.2.100的流量做IP地址插入和SNAT。

各位可根据实际情况做灵活修改。

3.4.2、验证
如果插入IP设备为第三方设备可采用如下iRule:
SecureCRT输出:
页面输出:
3.5、TCP-payload
虽然TCP-option已经可以圆满完成任务,但不得不承认TCP-
option 还存在一个问题,即目前来看该功能在v11版本以上才支持,并且还需要单独创建profile。

由于目前v11版本在用户端保有量与v10平分秋色,意
味着很多用户可能无法使用该功能,即便可以通过修改db值的方法来实现,但最终效果和是否会存在BUG没人能保证,基于以上原因我又尝试了将客户端插入到TCP-payload中来满足用户需求。

注:10.2.0 HF2至10.2.2需要重启进程,10.2.2 HF1至11.0.0之前版本可以用重启进程
3.5.1、配置步骤
1.登录BIG-IP WebUI配置界面
2.选择Local Traffic下的iRules
3.点击Create
4.添加iRules
5.选择测试VS
6.添加创建后的iRules
7.点击Finished
iRule内容
注:该rule背景是将分配至2.2.2.100的流量做IP地址插入和SNAT。

各位可根据实际情况做灵活修改。

3.5.2、验证
本次验证过程及配置步骤请参考3.1.2。

iRule内容:
SecureCRT输出:
页面输出:
四、总结
虽然这篇文档的名字叫做插入客户端源地址方法简述,实际各位兄弟会发现我所有的验证方法都是在后面的LTM上执行的,并未通过抓包等方式实现,所以这篇word实际阐述的内容是将客户端IP地址插入和提取的方法简述。

尤其是后面两种方式,在项目上用户的需求是F5需要将客户端源地址提取出来,为了验证iRule可以实现该功能不得已才写
的插入IP的iRule。

以上所有内容都是基于本人目前遇到的案例进行编写的,所有iRule也都是基于一定的测试背景,如果给位兄弟有需求可根据情况对其进行改写。

同时由于项目经验等客观条件影响,肯定会遗漏其他更好地
实现方式,如果各位兄弟有其他或者更好地实现方式烦请告诉我一下,非常感谢!
本文档下载自360文档中心，/doc/1112248700.html,更多营销,职业规划,工作简历,入党,工作报告,总结,学习资料,学习总结,PPT模板下载,范文等文档下载；转载请保留出处:/doc/1112248700.html,/doc/info-3cd86031f121dd36a22d828e.html。