【AD】AD替换老版本F5后客户反馈业务收到XFF字段不对

AD替换F5后客户反馈业务收到的XFF字段不对
正常情况下数据包应该是这样的，可以看到有两个X-Forwarded-For头部

一般业务方会通过XFF字段区去获取真正访问业务的地址，在业务开发的时候可能会获取固定字段，但是在做业务替换的时候，由于一些原因可能会导致获取的字段不正确

梳理业务逻辑

1.发现业务属于cookie类型业务

第一次访问虚拟服务后，带cookie，然后去进行认证， 认证后带着cookie会被认证网关在转发给虚拟服务，所以数据包带了两个X-Forwarded-For头部 ，而且有X-Forwarded-Host（认证网关插入）

2.分析AD插入XFF的逻辑，如果之前有插入XFF，那么AD会在数据包后插入IP，可能与业务获取IP的方式有冲突，导致业务获取IP不准确

AD替换F5后,安全设备不能统计到X-Forwarded-For携带的地址，原因是因为v13版本之前的F5设备的http profile 里的XFF功能是不检测客户端访问的数据是否携带X-Forwarded-For头部，直接插入一个X-Forwarded-For相同名字的头部，再把地址放到后面，相当于header里增加了一行。
F5从v13版本开始默认的http profile 的XFF功能的行为发生了改变，判断如果客户端请求里已经发现了了X-Forwarded-For字段，用逗号与前面的值隔开，直接把地址插入到这一行的最后面，不增加新的X-Forwarded-For头部。
AD设备HTTP优化策略的行为与F5 v13和之后版本一样，向XFF行的最后追加地址。这样导致了AD替换完老版本F5后，统计设备统计不到地址了

解决方案

1.方案一使用头部改写策略选择插入头部解决

2.方案二使用ipro脚本解决

event HTTP_REQUEST {
  local client = HTTP.remoteaddr()
  HTTP.add_header("X-Forwarded-For", client, 1)
}

验证：可以看到两个XFF

感谢楼主的分享！文章针对替换F5获取XFF字段不对的场景进行了很详细的分析，而且图文并茂，让人很容易理解；根因及解决方案都写的非常清楚，对于替换F5场景，尤其有XFF需求的非常有帮助，可以提前避免出现类似的情况
再次感谢楼主的分享，后续期待楼主更多的分享哦~

感谢分享，学习一下~

感谢分享，学习一下~

感谢分享，学习一下~

每天坚持打卡学习签到！！

打卡学习，感谢大佬分享！

感谢楼主分享，学习一下

感谢楼主的分享，学习了。期待楼主后续带来更多有价值的分享

向大佬学习，给大佬交出我的打赏，点赞，评论三连

逐句地看完这个帖子以后，我的心久久不能平静，震撼啊!为什么会有如此好的帖子!我纵横社区多年，自以为再也不会有任何帖子能打动我，没想到今天看到了如此精妙绝伦的这样一篇帖子。