Radware IPv6链外天窗案例-百度地图外链解决方案（二）来啦！

百度地图外链解决思路

这个是我们在某证券的IPv6测试中总结出的一个案例，因为这个外链天窗解决的过程和解决的手段都足够复杂，可以为大家提供更多的解决思路。但凡遇到百度地图这种外链的事情，该手册一定会起到相当大的辅助作用。（VS即Virtual Server 虚拟服务）

先看基础的配置：

主站VS——v6 转 v4

/c/slb/virt ipv6

ena

ipver v6

vip 240e:644:100:0:0:0:0:7

rtsrcmac ena

dname "inherit"

wanlink "ipv6"

type wizard

/c/slb/virt ipv6/service 8088 http

group test

rport 80

dbind forceproxy

/c/slb/virt ipv6/service 8088 http/pip

mode address

addr v4 58.56.105.10 255.255.255.255 persist disable

/c/slb/gslb/network 100

ena

ipver v6

sip 0:0:0:0:0:0:0:0

addvirt ipv6 65535

/c/slb/gslb/rule 100

ena

type inbound-llb 8088

ttl 0

rr 1

dname ";

/c/slb/gslb/rule 100/metric 1

gmetric network

addnet 100

/c/slb/gslb/rule 100/metric 2

gmetric proximity

/c/slb/gslb/rule 100/metric 3

gmetric bandwidth

这个是主页的地址（240e:644:100:0:0:0:0:7）和解析（），这个主页中的某个子页面下有一处外链了百度地图（api.map.baidu.com）（VS即Virtual Server）

创建修改策略，关联主站VS

创建修改外链的策略

/c/slb/layer7/httpmod 1

ena

/c/slb/layer7/httpmod 1/rule 2 text

ena

body include

action remove "TEXT=Accept-Encoding: gzip, deflate"

/c/slb/layer7/httpmod 1/rule 3 text

ena

directn resp

body include

action replace "FROMTEXT=; "TOTEXT=;

将 httpmod 关联至主站VS

/c/slb/virt ipv6/service 8088 http/http

httpmod 1

该策略使得主站可以返回修改后的域名，客户端请求到该域名就相当于请求到链路负载上的某个VS，即外链VS。

2.1.是基于域名的外链

然后我们还要创建外链VS，以及外链VS的解析（map.95538.cn）

（通过Alteon自身去ping api.map.baidu.com得到外链的地址，real及group部分的配置不再展示）

外链VS——v6 转 v4

/c/slb/virt baidu_map_api

ena

ipver v6

vip 240e:644:100:0:0:0:0:16

rtsrcmac ena

dname "inherit"

wanlink "ipv6"

/c/slb/virt baidu_map_api/service 8088 http

group baidu_map_api

rport 80

dbind forceproxy

/c/slb/virt baidu_map_api/service 8088 http/pip

mode address

addr v4 58.56.105.10 255.255.255.255 persist disable

/c/slb/gslb/network 110

ena

ipver v6

sip 0:0:0:0:0:0:0:0

addvirt baidu_map_api 65535

/c/slb/gslb/rule 110

ena

type inbound-llb 8088

ttl 0

rr 1

dname "map.95538.cn"

/c/slb/gslb/rule 110/metric 1

gmetric network

addnet 110

/c/slb/gslb/rule 110/metric 2

gmetric proximity

/c/slb/gslb/rule 110/metric 3

gmetric bandwidth

请求该外链当然还需要修改request请求头中HOST的值，否则百度地图API会返回503。

创建修改HOST的策略

/c/slb/layer7/httpmod 2

ena

/c/slb/layer7/httpmod 2/rule 2 text

ena

action replace "FROMTEXT=map.95538.cn:8088" "TOTEXT=api.map.baidu.com"

将修改HOST的 httpmod 策略关联至外链VS

/c/slb/virt baidu_map_api/service 8088 http/http

httpmod 2

正常情况的外链到这一步基本就结束了，但是，百度地图API的外链才算是刚刚开始。

2.2.外链返回的外链

百度地图API的这个外链，并没有将地图信息回传给我们，而是又返回了两个外链，当然同样是（api.map.baidu.com），只是uri信息不同。

上图展示的是原网站的信息，而实际的情况除了第一条被修改成了（map.95538.cn:8088），后面两条还是（api.map.baidu.com）。当时的抓包信息：

我们的modification没有将后续的（api.map.baidu.com）进行修改？而且通过这个包我们还可以看到respond信息中还有一条Set-Cookie……

针对外链回传的外链没有被修改的问题，我们通过httpmod进行了各种尝试，包括将text修改成url，包括将相同的text创建两条，均没有任何效果。

2.2.1. http modification性能的不足和异常

性能不足：无法对外链返回的外链进行修改

异常：http modification修改request后，会使得request发生两次，导致服务器间歇性返回 400 bad request。

我不是太确定产生两次GET的原因是modification本身的缺陷，还是跟Alteon软件版本有关，可以确定的是，这种情况在31.0.6的时候是没有的。而且，如果不把客户端request请求头中“Accept-Encoding:gzip, deflate”删掉，这种情况是不会出现的。

但因为400 Bad Request，并非只发生在此处，而是但凡关联了httpmod 的VS都会有这种现象发生，而且频率非常高，造成了非常差的体验感。

2.2.2. 使用as++替换http modification 解决性能不足和异常

抱着侥幸的心理，我们使用as++将modification 策略替换掉了

主站VS下的as++

（CLIENT_DATA相当于HTTP_REQUEST）

（SERVER_DATA相当于HTTP_RESPOND和HTTP_RESPOND_DATA）

/c/slb/appshape/script http_body_ipv6

ena

import text

when CLIENT_ACCEPTED {

TCP::collect

}

when CLIENT_DATA {

set re_gzip "Accept-Encoding: gzip, deflate"

set re_null " "

set j [TCP::payload find $re_gzip]

if { $j != -1 } {

TCP::payload replace $j 30 $re_null

}

TCP::release

TCP::collect

}

when SERVER_CONNECTED {

TCP::collect

}

when SERVER_DATA {

set map_baidu "api.map.baidu.com"

set change_data "map.95538.cn:8088"

foreach start_str [TCP::payload find_all $map_baidu] {

TCP::payload replace $start_str 17 $change_data

}

TCP::release

TCP::collect

}

-----END

外链VS下的as++

/c/slb/appshape/script http_body

ena

import text

when CLIENT_ACCEPTED {

TCP::collect

}

when CLIENT_DATA {

set old_host "map.95538.cn:8088"

set new_host "api.map.baidu.com"

set i [TCP::payload find $old_host]

if { $i != -1 } {

TCP::payload replace $i 17 $new_host

}

set re_gzip "Accept-Encoding: gzip, deflate"

set re_null " "

set j [TCP::payload find $re_gzip]

if { $j != -1 } {

TCP::payload replace $j 30 $re_null

}

TCP::release

TCP::collect

}

when SERVER_CONNECTED {

TCP::collect

}

when SERVER_DATA {

set map_baidu "api.map.baidu.com"

set change_data "map.95538.cn:8088"

foreach start_str [TCP::payload find_all $map_baidu] {

TCP::payload replace $start_str 17 $change_data

}

TCP::release

TCP::collect

}

-----END

测试证明，http modification 与 as++并不一样，至少能力差很多。

set map_baidu "api.map.baidu.com"

set change_data "map.95538.cn:8088"

foreach start_str [TCP::payload find_all $map_baidu] {

TCP::payload replace $start_str 17 $change_data

}

（api.map.baidu.com）都完全修改掉了，不止刚刚看到的那两处。

经过这样的修改之后，再次抓包发现，我们请求到了更多的信息，但遗憾的是，百度地图依然不显示。对比正常能请求到地图的包发现，正常的数据包从请求第一个（api.map.baidu.com）开始，余下的session全是在同一个会话当中。而请求不到地图，但确实返回了大量信息的包中，我们发现每个session都是一个独立的会话。

我们猜测，这可能与会话保持有关，我们通过v6请求过去，百度地图API返回了Set-Cookie之后，我们后续的请求，会自动丢弃百度API返回的Cookie，而且很显然，我们每次请求都发往了不同的百度地图服务器。

2.3.外链有基于cookie的会话保持

我们尝试了insert，passive，rewrite各种方式，企图将Cookie插入，甚至，我们都用上了手动插入，就是用as++写入一条静态的，百度地图API返回过来的Cookie，完全没有任何效果。

观察一下这个Cookie吧，这个Cookie中包含了很多信息，我做了一个这样的猜想，会不会是因为这些信息中的某一条导致了客户认为这个set-cookie是不安全，不合法的呢。比如“domain=.baidu.com”，仅仅只是一种猜测，不过没有别的办法还是可以尝试一下。于是，通过as++在respond方向，将多余的cookie信息remove掉。

set fg_ex "FG=1; expires="

set fg "FG=1"

set i [TCP::payload find $fg_ex]

if { $i != -1 } {

TCP::payload replace $i 97 $fg

}

在外链VS中SERVER_DATA中添加了这么一段。将FG=1；后面的内容全部移除。

然后，激动人心的事情发生了。刷新页面后，百度的地图的一些控制缩放的原件出现了，而地图也在反复的缩放过程中，似有似无的出现。

当出现这个结果时，我几乎都认为，这恐怕就是最好的结果了。

可惜，依旧经不起考验，这种奇迹，就只出现了一次，清空浏览器缓存，再次刷新，地图再没出现过。

此项问题该如何解决呢？限于篇幅原因，请大家期待下一章节，Radware IPv6链外天窗案例-百度地图外链解决方案（三）