TACACSD进程必须获取到认证请求的Source IP，为此我们尝试引入TProxy。 它允许你”模仿"用户的访问IP，就像负载均衡设备不存在一样，TProxy名字中的T表示的就是transparent(透明)。当网元发起的认证请求到达后端的AAA服务器时，可以通过抓包看到的请求Source IP就是网元的真实IP。
即使用上“HAProxy+TProxy”的组合拳，还是存在另外一个问题： 设备对于认证结果报文，似乎需要请求报文的目标地址(代理服务器)与结果报文的发送端(Real AAA Server)一致。
过程描述：网络设备会发送该用户的凭证到 TACACS+ 服务器进行验证，然后决定分配访问相关设备的权限，并将这些决定的结果包含在应答数据包中并发送到网络设备上，再由网络设备发送到用户终端。 至于是否真的是这个校验规则，或者我们还没有找到更好的解释。暂且搁置，引述一段RFC 1492的说明，日后再补充这个问题。 CONNECT(username, password, line, destinationIP, destinationPort) returns (result1, result2, result3)
This request can alt="物联网" width="550" height="236" />
另外，为了防止LVS控制机的单点故障问题，还选用了Keepalived，负责LVS控制机和备用机的自动故障切换。
LVS依赖项：IPVS内核模块和ipvsadm工具包。 具体配置不做过多说明，可以自行检索，关键注意以下几点： 1)检查服务器是否已支持ipvs modprobe -l |grep itvs 2)检查依赖包： rpm -q kernel-devel rpm -q gcc rpm -q openssl rpm -q openssl-devel rpm -q popt 3)配置realserver节点ARP及VIP绑定脚本 vi /etc/init.d/lvs 4)启动LVS-DR /etc/init.d/lvsdr start 5)查看VIP 情况 ip addr list 6)启动realserver节点LVS /etc/init.d/lvs start
五、小结
1. 各种负载均衡实现在网络中的位置
四层负载均衡的特点一般是在网络和网络传输层(TCP/IP)做负载均衡，而七层则是指在应用层做负载均衡。 四层负载均衡对于应用侵入比较小，对应用的感知较也少，同时应用接入基本不需要对此做特殊改造。 七层负载均衡一般对应用本身的感知比较多，可以结合一些通用的业务负载逻辑做成很细致的方案，比如我们通常用HAProxy/Nginx来做网站流量的分发。
实践再次教育我们，天下没有一招鲜，任何技术都有它的江湖位置。
2. 仿真能力
这次实践可以用一句话概括就是：“成也仿真，败也仿真”。 起初走了很长一段弯路，可以说是因为对整个负载均衡体系的理解不深入，也可以说是测试不足导致，凭着惯性，想当然地认为可以简单复制原来的“经验”，而 忽视了实验环境的构建。
后来可以快速推进，是因为重新规整了测试方法和目标，并且基于虚拟机搭建了验证环境，包括引入了可以仿真路由器的GNS3平台，完整地测试了真实的业务流程。LVS集群环境也是先完成构建、试运行一段时间之后才完成的业务割接。
IPTABLES NAT的方案并没有在早期发现性能瓶颈，也说明这快的测试能力不足。
3.花边故事
HAProxy的官网目前是被封锁的，国内不翻墙访问不了，Why ? 在他们家的操作手册后面有LVS、Nginx的推荐链接。以前并没有注意。
TPROXY最早是作为Linux内核的一个patch，从linux-2.6.28以后TPRXOY已经进入官方内核。iptables只是Linux防火墙的管理工具而已，位于/sbin/iptables。真正实现防火墙功能的是Netfilter，它是Linux内核中实现包过滤，如果要探讨Netfilter，又会是一个很长的故事。
LVS开始于1998年，创始人是章文嵩博士，从Linux2.4内核以后，已经完全内置了LVS的各个功能模块。到今天为止，依然是目前国内IT业界达到Linux标准内核模块层面的唯一硕果。章博士同时是前淘宝基础软件研发负责人、前阿里云CTO，三个月前刚转会到滴滴打车任副总裁。淘宝技术体系曾大规模使用了LVS，不过最新消息，淘宝的同学已经鼓捣出一个VIPServer，正逐步替代了LVS。
罗列的这几条信息，其实与这次的主题关系不大，但确是整理这次篇帖子过程中，感觉很有意思的事情。技术并不冰冷，它就像个江湖，到底还是关于人的故事。