前面有了关于链路负载均衡NAT和IPSec ×××的描述，包括IPSec ×××的隧道模式和野蛮模式的解释。还有，在一总部多分支的这种部署环境下的隧道模式该如何让site to site的隧道能正常建立，如DSR的方式。采用DSR的方式的确能在尽可能少的改动原防火墙的配置，只需要添加loopback ip（与virtual server IP相同），在负载均衡设备旁挂的情况下，就能让site to site的隧道建立正常。
我们知道，在IPSec ×××做安全协议校验时有两种模式：传输模式和隧道模式。传输模式需要在IP报文头部和高层协议报文头部之间插入IPSec ×××的报文头部，IPSec的报文头部和数据都做了加密，默认为目的地址可达，所以只能用于IP端点与IPSec端点一致的情形，如两个移动终端之间。因为传输模式不能进行NAT转换，所以site to site ×××更多采用隧道模式（保留原始IP报文头部，写入新的报文头部）。这里再详细分析一下IPSec ×××隧道建立的过程。
IPSec ×××的隧道建立分两个阶段：
第一阶段要完成三件事：
1）加密算法和各种参数的协商，这些算法和参数要用于保护隧道建立过程中的数据传输；
2）计算两端的加密的KEY值，这个KEY必须两端一致；
3）对等体的校验。说白了，譬如A要和B通信，就是为A和B各自验明正身。
第二阶段则需要在第一阶段完成了才开始，要完成的就一件事：在对等体之间协商生成IPSec SA的各种属性，SA为两个对等体加密数据，至此，隧道才真正建立起来。
在我最近遇到的IPSec ×××客户环境中，因为在出口链路前端部署了链路负载均衡设备，在建立IPSec ×××时一直出现问题。而客户又不愿意采用DSR的方式，理由是省的再去机房改线路（机房确实有点远），我晕。。。
实际上，在两端防火墙上都看到×××隧道都已建立完成，但端到端的数据过不去，而防火墙在监测到一段时间内没数据传输，就认为通道有问题，然后断开重建。
在负载均衡设备抓包中看到
@23047990 i( 1, 100, 10109)> ip 10.1.1.254 > *.*.*.* esp spi=0x7eb7fb45 seq=0x1a
@23047990 o( 6, 0, 10109)> ip 10.1.1.254 > *.*.*.* esp spi=0x7eb7fb45 seq=0x1a
@23048142 i( 1, 100, 1691d)> ip 10.1.1.254 > *.*.*.* esp spi=0x7eb7fb45 seq=0x1b
@23048142 o( 6, 0, 1691d)> ip 10.1.1.254 > *.*.*.* esp spi=0x7eb7fb45 seq=0x1b
（安全理由，此处将对端公网地址屏蔽为*.*.*.*）
此处只看到由内至外的ESP的协商，因为客户反映防火墙上已看到“隧道建立成功，但无法传输数据”，由此判断所谓隧道建立成功只是IPSec ×××的第一阶段完成，第二阶段还没成功。
@23048280 i( 1, 100, 168df)> ip 10.1.1.254 > 192.168.0.108 tcp 22518 > 1521 S 192198c5:0(0)
@23048280 o( 6, 0, 168df)> ip 183.62.*.* > 192.168.0.108 tcp 2614 > 1521 S 192198c5:0(0)
@23048348 i( 1, 100, f17f)> ip 10.1.1.254 > 192.168.0.108 tcp 60641 > 1521 S 19799d8a:0(0)
@23048348 o( 6, 0, f17f)> ip 183.62.*.* > 192.168.0.108 tcp 6753 > 1521 S 19799d8a:0(0)
@23048464 i( 1, 100, 168a3)> ip 10.1.1.254 > *.*.*.* icmp echo (ping) request seq=7948
@23048464 o( 6, 0, 168a3)> ip 183.62.*.* >*.*.*.* icmp echo (ping) request seq=7948
@23048467 o( 1, 0, 15e2d)> ip *.*.*.* > 10.1.1.254 icmp type=11 code=0
@23048468 i( 1, 100, 12861)> ip 10.1.1.254 > *.*.*.* icmp echo (ping) request seq=8048
@23048468 o( 6, 0, 12861)> ip 183.62.8.14 > *.*.*.* icmp echo (ping) request seq=8048
@23048472 o( 1, 0, 163e7)> ip *.*.*.* > 10.1.1.254 icmp type=11 code=0
后面的lan to lan通信的数据包也只有单向的传输，而没有回应。我们知道，在第二阶段建立SA的协商过程，发起方和响应方都需要向对方发送ESP/SHA/HMAC等校验，而这些校验工作都只在非TCP/UDP层工作，由此想到需要对于响应方的响应数据也得放通。在负载均衡设备配置中再加上inbound的others 0的策略（放通非TCP/UDP的流量）
vip_210.21.*.*(A) 210.21.*.*
port 0 tcp
member:***_tcp 0/tcp
port 0 udp
member:***_udp 0/udp
port 0 others
member:***_udp 0/others
再次抓包，就可以看到ping包有回应了
@1777313 i( 1, 100, 1f426)> ip 10.1.1.254 > *.*.*.* esp spi=0x50a5abe3 seq=0xf3
@1777313 o( 6, 0, 1f426)> ip 210.21.*.* > *.*.*.* esp spi=0x50a5abe3 seq=0xf3
@1777314 o( 1, 0, c2f9)> ip *.*.*.* > 10.1.1.254 esp spi=0x8dcc49fe seq=0xfa
@1777329 i( 1, 100, 1f447)> ip 10.1.1.254 > *.*.*.* esp spi=0x50a5abe3 seq=0xf4
@1777329 o( 6, 0, 1f447)> ip 210.21.*.* > *.*.*.* esp spi=0x50a5abe3 seq=0xf4
@1777331 o( 1, 0, c2fe)> ip *.*.*.* > 10.1.1.254 esp spi=0x8dcc49fe seq=0xfb
@1777390 o( 1, 0, c301)> ip 210.21.*.*> 10.1.1.254 icmp echo (ping) request seq=5496
@1777390 i( 1, 100, 1f44d)> ip 10.1.1.254 > 210.21.*.* icmp echo (ping) reply seq=5496
以上是在处理链路负载均衡NAT和IPSec ×××的一个实际案例，作为之前内容的一个补充，希望也能给大家提供参考意义。
（JM.Z）