负载上做地址透传后互联网用户能访问，数据透传 _上

公司对外提供一个业务，这个业务做了负载分担，实际的业务地址是172.29.9.8和172.29.9.9，对应的负载上虚拟服务的地址是192.168.201.100 。也就是用户访问的是负载，负载收到请求后，根据策略自动调度流量到两个服务器上。

用户的来源有两种，一个是办公网用户，主机地址比如是172.16.1.1 。一个是互联网用户地址是123.1.1.1 。

文章插图

互联网用户访问业务的具体流程为：123.1.1.1访问这个业务对应的公网地址，流量到了防火墙后做地址转换，目的地址变成了负载服务地址192.168.201.100 。流量到了负载上后源地址变成了192.168.201.100，目的地址变成了主机地址，比如172.29.9.8 。流量到了主机后主机回包，源是172.29.9.8，目的是192.168.201.100 。流量又到了负载上，负载根据之前保存的会话，把数据包发给123.1.1.1 。
如下图所示：

文章插图

办公网用户访问情况类似，只不过直接访问的是虚拟服务地址192.168.201.100 。流量转发路径如下图：

文章插图

我们注意到到达服务器的数据包都是从负载上过来的，那么数据包的源地址都是192.168.201.100 。业务部门反馈说，我想看到具体是哪个主机访问我的服务，比如123.1.1.1访问服务的时候我希望能看到数据包的源地址不是负载地址而是这个真实地址。

这时候就要在负载上做地址透传，可是又出现了一个新问题，经过负载后如果不做地址转换就会出现来回路径不一致的问题，导致业务无法正常访问。
比如数据包的源地址还是123.1.1.1，这时候业务主机回包到核心的时候，核心交换机就按照路由把数据包发到了公网上。这样来回路径不一样，业务访问肯定会出现问题。办公网用户访问的时候一样会出现这个情况。

这时候就要在核心交换机上做一个策略路由，源地址是172.29.9.8/9的数据包，强行指到负载上：

文章插图
【负载上做地址透传后互联网用户能访问，数据透传】

文章插图
这时候理论上来回路径都是一致的，业务可以正常访问。
但是问题来了，互联网用户可以正常访问，办公网用户不能正常访问。
办公网用户为什么不能正常访问呢？就是因为策略路由失效了。那为什么互联网用户访问的时候策略路由就没有问题呢？

服务器回包的时候目的地址是123.1.1.1，是公网地址，核心交换机是靠默认路由转发的。下一条指向出口防火墙。我们做的策略路由是默认策略路由，默认策略路由的优先级比默认路由高，所以策略路由生效了，数据包就能转发到负载上。

但是如果目的地址是172.16.1.1，核心交换机关于这个地址的路由是明细路由，指向办公网。这时候明细路由的优先级比默认策略路由要高，所以没有到负载，回到了办公网，造成了来回路径不一致。
要解决这个问题就需要把默认策略路由改成策略路由：

文章插图

这时候办公网的用户就可以正常访问业务了。原来default-next-hop和next-hop是不一样的。
最后总结一下路由的优先级：
策略路由＞明细路由＞默认策略路由＞默认路由