现在的位置: 首页 > 综合 > 正文

链路均衡设备的NAT和ipsec vpn

2012年03月25日 综合 ⁄ 共 2394字 ⁄ 字号 暂无评论

IPSec VPN的隧道建立分两个阶段:

第一阶段要完成三件事:

1)加密算法和各种参数的协商,这些算法和参数要用于保护隧道建立过程中的数据传输;

2)计算两端的加密的KEY值,这个KEY必须两端一致;

3)对等体的校验。说白了,譬如A要和B通信,就是为A和B各自验明正身。

第二阶段则需要在第一阶段完成了才开始,要完成的就一件事:在对等体之间协商生成IPSec SA的各种属性,SA为两个对等体加密数据,至此,隧道才真正建立起来。

在我最近遇到的IPSec VPN客户环境中,因为在出口链路前端部署了链路负载均衡设备,在建立IPSec VPN时一直出现问题。而客户又不愿意采用DSR的方式,理由是省的再去机房改线路(机房确实有点远),我晕。。。

实际上,在两端防火墙上都看到VPN隧道都已建立完成,但端到端的数据过不去,而防火墙在监测到一段时间内没数据传输,就认为通道有问题,然后断开重建。

在负载均衡设备抓包中看到

@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 VPN的第一阶段完成,第二阶段还没成功。

@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:vpn_tcp 0/tcp

port 0 udp

member:vpn_udp 0/udp

port 0 others

member:vpn_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 VPN的一个实际案例,作为之前内容的一个补充,希望也能给大家提供参考意义。

给我留言

留言无头像?