许多时候，我们在给客户介绍负载均衡设备部署时，为了尽可能减少对客户原网络架构的改动，会推荐采用旁路部署的方式。这种方式确实给我们工程师和客户带来极大的便利：一方面，客户的原业务系统无需改动，当需要实现流量均分的时候，只需要访问新增的VIP即可，相当于多了一个业务接口；另一方面，可在不影响业务正常运行的同时一边做测试，测试验证通过了再把整体流量切换过来。旁路部署在负载均衡设备来说也比较简单，设备如添加服务器一样侧挂在交换机上，与服务器同一网段，然后在原配置基础上添加源地址转换的策略，把客户端的IP强制NAT成指定的一个地址，这样便完成了。

然而在最近的一次调测中，就是这样简单的旁挂部署，却也出现了意想不到的情况。客户的业务结构很简单，3台WEB 服务器（IIS）实现负载均衡。

当配置完成发现，登陆界面能够打开，在输入账号密码后却无法正常登陆到后台，一直停留在登陆界面，感觉就像账号验证信息无法传输到后台。开始会怀疑是某台服务器的配置出现异常，但每台服务器单独访问都很正常，最终结论还是在负载均衡设备上。

细下分析，登陆界面能打开，表明流量能正常分发，源地址转换（SNAT）也是ok的； 旁挂情况下，改变的除了客户端的源IP，还有就是目的地址，由原来的服务器IP改为负载均衡设备上的VIP。通过抓包分析，可以看到在客户端的请求包中“Referer”和“Host”字段标注了目的IP。

在一些IIS的安全设置中，需要对“Referer”和“Host”进行校验（注：我们在上网的时候经常会发现如果直接打开一个页面有时会跳转到网站首页或者显示出错信息，要求必须从网站首页进入再打开连接。这样做的目的是为了防止别人使用iframe的方式嵌入自己的网页。 遇到这样的问题是因为页面中使用了HTTP-REFERER，通过Request.ServerVariables("HTTP_REFERER")验证页面来源，如果不是指定来源那么就跳转到指定页面）。

我们在负载均衡设备上定制了一个脚本，把请求包中对应的IP改为服务器的真实地址，由此绕开服务器的校验，改动后问题解决了。

when HTTP_REQUEST_SEND {

HTTP::header replace Host [LB::server addr]

if { not ([HTTP::header "Referer"] equals "")  } {

HTTP::header replace Referer "http://[LB::server addr]/"

}

}

本文转自 virtualadc 51CTO博客，原文链接:http://blog.51cto.com/virtualadc/720268