【防火墙技术连载28】强叔侃墙 VPN篇 IPSec遭遇NAT处变不惊,见招拆招化险为夷

digest [复制链接]
发表于 : 2014-7-24 11:07:54 最新回复:2018-07-30 18:10:38
24859 27
强叔侃墙
强叔侃墙 官方号

前文说到,使用模板方式可以在总舵与公网IP不固定的分舵之间建立IPSec隧道。至此,无论是拥有固定公网IP的分舵还是动态获得公网IP的分舵,都可以通过IPSec安全地访问总舵,天地会业务兴隆一片祥和。
但Internet的江湖远非如此平静,天地会又面临新的问题。有的分舵连动态的公网IP都没有,只能先由网络中的NAT设备进行地址转换,然后才能访问Internet,此时分舵能否正常访问总舵?另外,分舵除了访问总舵之外,还有访问Internet的需求,有些分舵在网关上同时配置了IPSec和NAT,两者能否和平共处?如何解决上述这两个问题,且听强叔一一道来。

IPSec隧道途径NAT设备,NAT穿越力保畅通无阻

先来看网络中存在NAT设备的情况,如下图所示,分舵网关B的出接口IP是私网地址,必须经过NAT设备进行地址转换,转换为公网IP之后才能与总舵网关A建立IPSec隧道。


我们都知道,IPSec是用来保护报文不被修改的,而NAT却专门修改报文的IP地址,看起来两者水火不容,我们来详细分析一下。首先,协商IPSec的过程是由ISAKMP消息完成的,而ISAKMP消息是经过UDP封装的,源和目的端口号均是500,NAT设备可以转换该消息的IP地址和端口,因此ISAKMP消息能够顺利的完成NAT转换,成功协商IPSec安全联盟。但是数据流量是通过AH或ESP协议传输的,在NAT转换过程中存在问题。下面分别看一下AH和ESP报文能否通过NAT设备。

  • AH协议

因为AH对数据进行完整性检查,会对包括IP地址在内的整个IP包进行Hash运算。而NAT会改变IP地址,从而破坏AH的Hash值。因此AH报文无法通过NAT网关。

  •  ESP协议

ESP对数据进行完整性检查,不包括外部的IP头,IP地址转换不会破坏ESP的Hash值。但ESP报文中TCP的端口已经加密无法修改,所以对于同时转换端口的NAT来说,ESP没法支持。
为了解决这个问题,必须在建立IPSec隧道的两个网关上同时开启NAT穿越功能(对应命令行nat traversal)。开启NAT穿越功能后,当需要穿越NAT设备时,ESP报文会被封装在一个UDP头中,源和目的端口号均是4500。有了这个UDP头就可以正常进行转换。
根据NAT设备所处的位置和地址转换功能的不同,我们从下面三个场景来分别介绍:
场景一:NAT转换后的分舵公网地址未知,总舵使用模板方式
该场景中,NAT设备位于分舵网络之外,分舵网关B接口GE0/0/1的私网IP地址,经过NAT设备转换后变为公网IP地址。由于天地会无从获知经过NAT设备转换后的分舵公网IP地址,也就无法在总舵网关A上明确指定对端分舵的公网地址。因此,总舵网关A必须使用模板方式来配置IPSec,同时总舵和分舵的网关上都要开启NAT穿越功能。
总舵既然使用了模板方式,那就无法主动访问分舵,只能由分舵主动向总舵发起访问。


总舵和分舵网关的关键配置如下:

关键配置

总舵

分舵

IPSec安全提议

ipsec proposal pro1

 transform esp  //采用ESP协议传输报文

ipsec proposal pro1

 transform esp  //采用ESP协议传输报文

IKE对等体

ike peer fenduo

 pre-shared-key tiandihui1

 ike-proposal 10

nat traversal  //双方同时开启,默认为开启

ike peer zongduo

 pre-shared-key tiandihui1

 ike-proposal 10

 remote-address 1.1.1.1

nat traversal //双方同时开启,默认为开启

IPSec安全策略

ipsec policy-template tem1 1 //配置模板方式

 security acl 3000

 proposal pro1

 ike-peer fenduo

ipsec policy policy1 1 isakmp template tem1

ipsec policy policy1 1 isakmp

 security acl 3000

 proposal pro1

 ike-peer zongduo

 

场景二:NAT转换后的分舵公网地址可知,总舵使用模板方式或IKE方式
该场景中,NAT设备位于分舵网络之内,分舵网关B接口GE0/0/1的私网IP地址,经过NAT设备转换后变为公网IP地址。由于NAT设备在分舵控制范围之内,转换后的公网地址可知,所以总舵网关A上可以使用模板方式也可以使用IKE方式来配置IPSec。
需要注意的是,即便使用IKE方式,总舵也无法主动与分舵建立IPSec隧道。这不是IPSec的问题,而是NAT设备的问题。NAT设备只提供了源地址转换,实现分舵--->总舵这一方向的访问,分舵“隐藏”在NAT设备之后,无法实现总舵--->分舵方向的访问。如果要实现总舵主动访问分舵网关B的私网地址,则需要在NAT设备上配置NAT Server功能,我们会在场景三中详细介绍。
 


总舵和分舵网关的关键配置如下: 

关键配置

总舵

分舵

IPSec安全提议

ipsec proposal pro1

 transform esp  //采用ESP协议传输报文

ipsec proposal pro1

 transform esp  //采用ESP协议传输报文

IKE对等体

ike peer fenduo

 pre-shared-key tiandihui1

 ike-proposal 10

nat traversal  //双方同时开启,默认为开启

remote-address 2.2.2.10 //对端地址为NAT后的地址。采用IKE方式时由于对端地址为单个地址,所以要求NAT设备的地址池中只有一个地址。模板方式时无此要求。

remote-address authentication-address 172.16.0.1 //认证地址为NAT前的地址

ike peer zongduo

 pre-shared-key tiandihui1

 ike-proposal 10

 remote-address 1.1.1.1

nat traversal //双方同时开启,默认为开启

IPSec安全策略

ipsec policy policy1 isakmp

 security acl 3000

 proposal pro1

 ike-peer fenduo

ipsec policy policy1 1 isakmp

 security acl 3000

 proposal pro1

 ike-peer zongduo

 

场景三:NAT设备提供NAT Server功能,总舵使用IKE方式主动访问分舵

该场景中,NAT设备位于分舵网络之内,提供NAT Server功能,对外发布的地址是2.2.2.20,映射成私网地址是分舵网关B接口GE0/0/1的地址172.16.0.1。总舵网关A上使用IKE方式来配置IPSec,即可实现总舵--->分舵方向的访问。在NAT设备上配置NAT Server,将2.2.2.20的UDP 500端口和4500端口分别映射到172.16.0.1的UDP 500端口和4500端口,具体配置如下:

nat server protocol udp global 2.2.2.20 500 inside 172.16.0.1 500

nat server protocol udp global 2.2.2.20 4500 inside 172.16.0.1 4500

同时,由于NAT设备上配置NAT Server时会生成反向Server-map表,所以分舵的网关B也可以主动向总舵发起访问。报文到达NAT设备后,匹配反向Server-map表,源地址转换为2.2.2.20,即可实现分舵--->总舵方向的访问。

 

总舵和分舵网关的关键配置如下:

关键配置

总舵

分舵

IPSec安全提议

ipsec proposal pro1

 transform esp

ipsec proposal pro1

 transform esp

IKE对等体

ike peer fenduo

 pre-shared-key tiandihui1

 ike-proposal 10

nat traversal  //双方同时开启,默认为开启

remote-address 2.2.2.20 //对端地址为NAT后的地址

remote-address authentication-address 172.16.0.1 //认证地址为NAT前的地址

ike peer zongduo

 pre-shared-key tiandihui1

 ike-proposal 10

 remote-address 1.1.1.1

nat traversal //双方同时开启,默认为开启

IPSec安全策略

ipsec policy policy1 isakmp

 security acl 3000

 proposal pro1

 ike-peer fenduo

ipsec policy policy1 1 isakmp

 security acl 3000

 proposal pro1

 ike-peer zongduo

 

下面以第二种场景为例,分别介绍一下采用IKEv1和IKEv2时是如何进行NAT穿越。

  • IKEv1协商NAT穿越大揭秘

1. 开启NAT穿越时,IKEv1协商第一阶段的前两个消息会发送标识NAT穿越(NAT Traversal,简称NAT-T)能力的Vendor ID载荷(主模式和野蛮模式都是)。用于检查通信双方是否支持NAT-T。


 

当双方都在各自的消息中包含了该载荷时,才会进行相关的NAT-T协商。
2. 主模式消息3和消息4(野蛮模式消息2和消息3)中发送NAT-D(NAT Discovery)载荷。NAT-D载荷用于探测两个要建立IPSec隧道的网关之间是否存在NAT网关以及NAT网关的位置。

通过协商双方向对端发送源和目的的IP地址与端口的Hash值,就可以检测到地址和端口在传输过程中是否发生变化。若果协商双方计算出来的Hash值与它收到的Hash值一样,则表示它们之间没有NAT。否则,则说明传输过程中对IP或端口进行了NAT转换。
第一个NAT-D载荷为对端IP和端口的Hash值,第二个NAT-D载荷为本端IP和端口的Hash值。
3. 发现NAT网关后,后续ISAKMP消息(主模式从消息5、野蛮模式从消息3开始)的端口号转换为4500。ISAKMP报文标识了“Non-ESP Marker”。


4. 在第二阶段会启用NAT穿越协商。在IKE中增加了两种IPSec报文封装模式:UDP封装隧道模式报文(UDP-Encapsulated-Tunnel)和UDP封装传输模式报文(UDP-Encapsulated-Transport)。通过为ESP报文封装UDP头,当封装后的报文通过NAT设备时,NAT设备对该报文的外层IP头和增加的UDP头进行地址和端口号转换。UDP报文端口号修改为4500。

 

  • IKEv2协商NAT穿越大揭秘

1. 开启NAT穿越后,IKE的发起者和响应者都在IKE_SA_INIT消息对中包含类型为NAT_DETECTION_SOURCE_IP和NAT_DETECTION_DESTINATION_IP的通知载荷。这两个通知载荷用于检测在将要建立IPSec隧道的两个网关之间是否存在NAT,哪个网关位于NAT之后。如果接收到的NAT_DETECTION_SOURCE通知载荷没有匹配数据包IP头中的源IP和端口的Hash值,则说明对端位于NAT网关后面。如果接收到的NAT_DETECTION_DESTINATION_IP通知载荷没有匹配数据包IP头中的目的IP和端口的Hash值,则意味着本端位于NAT网关之后。

 

2. 检测到NAT网关后,从IKE_AUTH消息对开始ISAKMP报文端口号改为4500。报文标识“Non-ESP Marker”。

 

IKEv2中也使用UDP封装ESP报文,当封装后的报文通过NAT设备时,NAT设备对该报文的外层IP头和增加的UDP头进行地址和端口号转换。UDP报文端口号修改为4500。


在第二种场景中,配置完成后PC1可以ping通PC2。在总舵网关A上查看IKE SA和IPSec SA的建立情况:
<FW_A> display ike sa
current ike sa number: 2
---------------------------------------------------------------------
conn-id    peer                    flag          phase vpn
---------------------------------------------------------------------
40014      2.2.2.10:264             RD            v1:2  public
40011      2.2.2.10:264             RD            v1:1  public

在总舵网关A上查看会话:
<FW_A> display firewall session table
Current Total Sessions : 2 
  udp  VPN:public --> public 2.2.2.10:2050-->1.1.1.1:4500
  udp  VPN:public --> public 2.2.2.10:2054-->1.1.1.1:500
在分舵网关B上查看会话:
<FW_B> display firewall session table
Current Total Sessions : 2
  udp  VPN:public --> public 172.16.0.1:4500-->1.1.1.1:4500
  udp  VPN:public --> public 172.16.0.1:500-->1.1.1.1:500   //刚开始协商时端口号还是500
因为中间NAT设备上配置了源NAT转换,所以分舵网关B上只有分舵到总舵方向的会话,没有总舵到分舵方向的会话。

IPSec与NAT同处一墙,不同流量泾渭分明

前面讲了IPSec穿越NAT的情况,当IPSec和NAT同时配置在一台防火墙上时,由于两者处理的流量不同,只要保证两种流量互不干扰,便可相安无事。如下图所示,分舵网关B上同时配置了IPSec和NAT,IPSec用于保护分舵跟总舵通信的流量,NAT处理的是分舵访问Internet的流量。


按理说两种流量应该是泾渭分明,互不相干。其实不然,在防火墙处理流程中,NAT在上游,IPSec在下游,所以IPSec流量难免会受到NAT的干扰。IPSec流量一旦命中NAT策略就会进行NAT转换,转换后的流量不会匹配IPSec中的ACL,也就不会进行IPSec处理。
注:强叔后续会推出防火墙处理流程的介绍,敬请期待。
解决这个问题的方法就是在NAT策略中配置一条针对IPSec流量不进行地址转换的策略,该策略的优先级要高于其他的策略,并且该策略中定义的流量范围是其他策略的子集。这样的话,IPSec流量会先命中不进行NAT转换的策略,地址不会被转换,也就不会影响下面IPSec环节的处理,而需要进行NAT处理的流量也可以命中其他策略正常转换。
NAT策略的配置如下:
nat-policy interzone trust untrust outbound                                         
policy 0   //需要IPSec保护的流量不进行NAT转换
 action no-nat
 policy source 172.16.1.0 mask 24
 policy destination 192.168.0.0 mask 24
policy 5     //访问Internet的流量进行NAT转换
action source-nat                                                             
policy source 172.16.1.0 mask 24                                               
address-group 1
若分舵网关B上还配置了NAT Server,配置NAT Server时生成的反向Server-map表也干扰IPSec流量。分舵中的服务器访问总舵时,流量会命中反向Server-map表,然后进行地址转换,转换后的流量不会匹配IPSec中的ACL,也就不会进行IPSec处理。此时就需要在配置NAT Server时指定no-reverse参数,不生成反向Server-map表,关于此问题的具体说明请参见NAT Server 三十二字真言(上篇)”。
前面的讲解中,总舵和分舵进行身份认证时采用的都是预共享认证方式。预共享密钥还是需要手工配置的,跟总舵对接的分舵数量少的时候没有问题,当分舵数量多的时候,为每个分舵跟总舵规划和配置预共享密钥的工作量还是不小的。对于这种情况,采用证书认证就非常合适。那到底什么是证书,采用证书认证跟预共享认证相比在配置上有什么差别呢。预知详情,请看下回分解。

 

 

上一篇 VPN篇 IPSec模板海纳百川,不定对端有容乃大

下一篇 VPN篇 IPSec引入数字证书,身份认证简单便捷

汇总贴

本帖被以下专题推荐:

  • x
  • 常规:

点评 回复

跳转到指定楼层
kmyd
kmyd  大师 发表于 2014-7-24 13:07:14 已赞(0) 赞(0)

好资料,感谢强叔!!
  • x
  • 常规:

点评 回复

wangbenlie
wangbenlie   发表于 2014-7-24 18:14:21 已赞(0) 赞(0)

感谢分享!

  • x
  • 常规:

点评 回复

IT彬
IT彬   发表于 2014-7-24 23:25:57 已赞(0) 赞(0)

强叔,很好很强大
  • x
  • 常规:

点评 回复

shadowboy
shadowboy   发表于 2014-7-25 11:32:05 已赞(0) 赞(0)

场景二 图挂了。。支持强叔。。。。
  • x
  • 常规:

点评 回复

豆豆的新世界
豆豆的新世界   发表于 2014-9-15 15:12:36 已赞(0) 赞(0)

您好,请教一个问题:

跟场景二类似,我们办公环境用H3C的ER2100路由器在大楼内网,对端在机房是华为的usg5300,有固定公网IP。

现在配置完vpn之后,机房的服务器可以ping通办公端内网的主机,但是从办公内网无法ping通机房侧的主机。

usg设备的vpn状态如下

[Internet-5310-ike-peer-anyz_peer]dis ike sa
15:03:33  2014/09/15
current ike sa number: 3
  ---------------------------------------------------------------------
  connection-id     peer                vpn    flag        phase    doi
  ---------------------------------------------------------------------
   0x2ce         211.X.X.X:0000     0     RD          v1:1    IPSEC 
   0x2cd         211.X.X.X:0489     0     RD          v1:2    IPSEC 
   0x2cc         211.X.X.X:0489     0     RD          v1:1    IPSEC 

您能给提供一些建议吗?多谢!

  • x
  • 常规:

点评 回复

强叔侃墙
强叔侃墙 官方号 发表于 2014-7-25 17:02:31 已赞(0) 赞(0)

引用 5 楼

场景二 图挂了。。支持强叔。。。。
shadowboy 发表于 2014-07-25 11:32

看不到图吗? 我重新编辑一下。
  • x
  • 常规:

点评 回复

shadowboy
shadowboy   发表于 2014-7-25 22:05:14 已赞(0) 赞(0)

引用 6 楼


看不到图吗? 我重新编辑一下。
强叔侃墙 发表于 2014-07-25 17:02


OK 。看到了。。。

  • x
  • 常规:

点评 回复

dfcomeon
dfcomeon   发表于 2014-7-30 10:33:42 已赞(0) 赞(0)

强叔,您好!

看了您的文档,意犹未尽,能看到您写的墙技术文档,是一种福气

特地向您请教个问题:

本人管理的E8000E内部保护 的服务器十台被黑客做成肉鸡同时向公网发起攻击,此时其他服务器无法访问公网,并且从公网也无法访问进内部,登上防火墙dis firewall session table查看的会话为80万会话,并且防火墙cpu memory 所占的资源也只有10%和49%,请问当时为什么防火墙无法正常转发数据?


多谢强叔!

  • x
  • 常规:

点评 回复

jiazhaoxin
jiazhaoxin   发表于 2014-7-30 13:06:10 已赞(0) 赞(0)

请教一个问题:

防火墙上做了两个转换:

nat server 3 global 58.254.132.110 inside 192.168.1.40

nat server 35 global 58.254.132.196 inside 192.168.1.200  

192.168.1.0/24在和防火墙互联的一台交换上:
ip route-static 192.168.1.0 255.255.255.0 192.168.254.49

想问一下:192.168.1.40 这个服务器去访问 58.254.132.196 能通吗 ,可以在防火墙上看到会话吗?

  • x
  • 常规:

点评 回复

123
返回列表
发表回复
您需要登录后才可以回帖 登录 | 注册

警告 内容安全提示:尊敬的用户您好,为了保障您、社区及第三方的合法权益,请勿发布可能给各方带来法律风险的内容,包括但不限于政治敏感内容,涉黄赌毒内容,泄露、侵犯他人商业秘密的内容,侵犯他人商标、版本、专利等知识产权的内容,侵犯个人隐私的内容等。也请勿向他人共享您的账号及密码,通过您的账号执行的所有操作,将视同您本人的行为,由您本人承担操作后果。详情请参看“隐私声明
如果附件按钮无法使用,请将Adobe Flash Player 更新到最新版本!
登录参与交流分享

登录参与交流分享

登录