什么是防火墙

防火墙主要部署在网络边界，对进出网络的访问行为进行控制，安全防护是其核心特性。

路由器与交换机的本质是转发，防火墙的本质是控制。

防火墙的发展史

1989-1994
1989年产生了包过滤防火墙，实现简单的访问控制，我们称之为第一代防火墙。
随后出现了代理防火墙，在应用层代理内部网络和外部网络之间的通信，属于第二代防火墙。代理防火墙安全性较高，但处理速度慢，而且对每一种应用开发一个对应的代理服务是很难做到的，因此只能对少量的应用提供代理支持。
1994年CheckPoint公司发布了第一台基于状态检测技术的防火墙，通过动态分析报文的状态来决定对报文采取的动作，不需要为每个应用程序都进行代理，处理速度快而且安全性高。状态检测防火墙被称为第三代防火墙。（关于Checkpoint：以色列的一家安全厂商，发布了第一台基于状态检测技术的商业化防火墙。）

1995-2004
状态检测防火墙已经成为趋势。除了访问控制功能之外，防火墙上也开始
增加一些其他功能，如VPN。
一些专用设备也在这一时期出现了雏形。例如，专门保护Web服务器安全的WAF（WebApplicationFirewall，Web应用防火墙）设备。
2004年业界提出了UTM（UnitedThreatManagement，统一威胁管理）的概念，将传统防火墙、入侵检测、防病毒、URL过滤、应用程序控制、邮件过滤等功能融合到一台防火墙上，实现全面的安全防护。

2005-now
2004年后，UTM市场得到了快速的发展，UTM产品如雨后春笋般涌现，但面临新的问题。首先是对应用层信息的检测程度受到限制，就像允许女人和男人通过，拒绝大象通过，那是否允许武装直升机通过呢？此时就需要
更高级的检测手段，这使得DPI（DeepPacketInspection，深度报文检测）技术得到广泛应用。其次是性能问题，多个功能同时运行，UTM设备的处理性能将会严重下降。
2008年PaloAltoNetworks公司发布了下一代防火墙，解决了多个功能同时运行时性能下降的问题。同时，还可以基于用户、应用和内容来进行管控。（关于PaloAltoNetworks：美国的一家安全厂商，率先推出了下一代防火墙，称得上是下一代防火墙的开山鼻祖。）
2009年Gartner对下一代防火墙进行了定义，明确下一代防火墙应具备的功能特性。随后各个安全厂商也推出了各自的下一代防火墙产品，防火墙进入了一个新的时代。（关于Gartner：著名的IT研究与顾问咨询公司，其研究范围覆盖全部IT产业，众所周知的魔力象限就出自Gartner。在2013年华为成为首家进入Gartner防火墙和UTM魔力象限的中国厂商，充分证明了华为安全产品的质量和实力。）

从发展历史看防火墙特点

• 访问控制越来越精确从最初的简单访问控制，到基于会话的访问控制，再到下一代防火墙上基于应用、用户和内容来做访问控制，都是为了实现更有效更精确地访问控制。
• 防护能力越来越强，防护手段越来越多，防护的范围也越来越广。
• 性能越来越高各个防火墙厂商通过对硬件和软件架构的不断改进，使防火墙的处理性能与业务流量相匹配。

华为防火墙产品介绍

USG2000和USG5000系列定位于UTM产品，USG6000系列属于下一代防火墙产品，USG9500系列属于高端防火墙产品。下面强叔就挑出几个有代表性的防火墙产品，为大家逐一介绍。

USG2110

USG2100集防火墙、UTM、VPN、路由、无线（WIFI/3G）等十八般武艺于一身，即插即用，配置方便，为客户提供安全、灵活、便捷的一体化组网和接入解决方案。

USG6000

为华为面向下一代网络环境的防火墙产品，USG6600提供以应用层威胁防护为核心的下一代网络安全方案，让网络管理员重新掌控网络，看得更清、管得更细、用得更易。

USG9500

业界首款T级数据中心防火墙，USG9500采用分布式软硬件设计，，将交换、路由、安全服务整合到统一的设备中，在大型数据中心、大型企业、教育、政府、广电等行业和典型场景得到广泛应用。

安全区域

在防火墙上引入了一个重要的概念：安全区域（SecurityZone），简称为区域（Zone）。

安全区域是一个或多个接口的集合，是防火墙区别于路由器的主要特性。防火墙通过安全区域来划分网络、标识报文流动的“路线”，当报文在不同的安全区域之间流动时，才会触发安全检查

防火墙通过接口来连接网络，将接口划分到安全区域后，通过接口就把安全区域和网络关联起来。通常说某个安全区域，就可以表示该安全区域中接口所连接的网络。

通过把接口划分到不同的安全区域中，就可以在防火墙上划分出不同的网络。

接口1和2放到安全区域A中

接口3放到安全区域B中

接口4放到安全区域C中

这样在防火墙上就存在了三个安全区域，对应三个网络。

华为防火墙产品上默认已经为大家提供了三个安全区域，分别是Trust、DMZ和Untrust，

Trust：该区域内网络的受信任程度高，通常用来定义内部用户所在的网络
DMZ：该区域内网络的受信任程度中等，通常用来定义内部服务器所在的网络
Untrust：该区域代表的是不受信任的网络，通常用来定义Internet等不安全的网络

由此我们可以得知，不同网络间互访时报文在防火墙上所走的路线。例如，当内部网络中的用户访问Internet时，报文在防火墙上的路线是从Trust区域到Untrust区域；当Internet上的用户访问内部服务器时，报文在防火墙上的路线是从Untrust区域到DMZ区域。

除了在不同网络之间流动的报文之外如何在防火墙上标识（例如我们登录到防火墙上进行配置），以及从防火墙本身发出的报文的路线呢？

防火墙上提供了Local区域，代表防火墙本身。凡是由防火墙主动发出的报文均可认为是从Local区域中发出，凡是需要防火墙响应并处理（而不是转发）的报文均可认为是由Local区域接收

关于Local区域，Local区域中不能添加任何接口，但防火墙上所有接口本身都隐含属于Local区域。

:::info
报文通过接口去往某个网络时，目的安全区域是该接口所在的安全区域；报文通过接口到达防火墙本身时，目的安全区域是Local区域。

:::

级别确定，安全区域就被分成了三六九等，报文在两个安全区域之间流动时，规定：

报文从低级别的安全区域向高级别的安全区域流动时为入方向（Inbound），报文从由高级别的安全区域向低级别的安全区域流动时为出方向（Outbound）。

---

报文在两个方向上流动时，将会触发不同的安全检查。下图标明了Local区域、Trust区域、DMZ区域和Untrust区域间的方向。

下面给出了防火墙部署在企业内部的真实环境组网图。从图中我们可以看出，企业内部网络中的用户、服务器，以及位于外部的Internet，都被划分到不同的安全区域中了，防火墙对各个安全区域之间流动的报文进行安全检查。

:::info
DMZ（DemilitarizedZone）起源于军方，是介于严格的军事管制区和松散的公共区域之间的一种部分管制的区域。防火墙引用了这一术语，指代一个与内部网络和外部网络分离的安全区域。

:::

状态检测

状态检测防火墙的出现是防火墙发展历史上里程碑式的事件，而其所使用的状态检测和会话机制，目前已经成为防火墙产品的基本功能，也是防火墙实现安全防护的基础技术。

从状态检测防火墙产生的背景说起。

先看一个简单的网络环境，如下图所示，PC和Web服务器位于不同的网络，分别与防火墙相连，PC与Web服务器之间的通信受到防火墙的控制。

当PC需要访问Web服务器浏览网页时，在防火墙上必须配置如下的一条规则，允许PC访问Web服务器的报文通过。

源端口处的*表示任意的端口，这是因为PC在访问Web服务器时，它的操作系统决定了所使用的源端口，例如，对于WINDOWS操作系统来说，这个值可能是1024~65535范围内任意的一个端口。这个值是不确定的，所以这里设定为任意端口。

配置了这条规则后，PC发出的报文就可以顺利通过防火墙，到达Web服务器。然后Web服务器将会向PC发送回应报文，这个报文也要穿过防火墙才能到达PC。在状态检测防火墙出现之前，包过滤防火墙还必须配置如下所示的规则2，允许反方向的报文通过。

在规则2中，目的端口也设定为任意端口，因为我们无法确定PC访问Web服务器时使用的源端口，要想使Web服务器回应的报文都能顺利穿过防火墙到达PC，只能将规则2中的目的端口设定为任意端口。

如果PC位于受保护的网络中，这样处理将会带来很大的安全问题。规则2将去往PC的目的端口全部开放，外部的恶意攻击者伪装成Web服务器，就可以畅通无阻地穿过防火墙，PC将会面临严重的安全风险。

状态检测防火墙解决这个问题：

首先需要在防火墙上设定规则1，允许PC访问Web服务器的报文通过。当报文到达防火墙后，防火墙允许报文通过，同时还会针对PC访问Web服务器的这个行为建立会话（Session），会话中包含了PC发出的报文信息，如地址和端口等。当Web服务器回应给PC的报文到达防火墙后，防火墙会把报文中的信息与会话中的信息进行比对，发现报文中的信息与会话中的信息相匹配，并且符合协议规范对后续包的定义，则认为这个报文属于PC访问Web服务器行为的后续回应报文，直接允许这个报文通过，如下图所示。

而恶意攻击者即使伪装成Web服务器向PC发起访问，由于这类报文不属于PC访问Web服务器行为的后续回应报文，防火墙就不会允许这些报文通过。这样就解决了包过滤防火墙大范围开放端口带来的安全风险，同时也保证了PC可以正常访问Web服务器。

总结：

• 包过滤防火墙只根据设定好的静态规则来判断是否允许报文通过，它认为报文都是无状态的孤立个体，不关注报文产生的前因后果。
• 状态检测防火墙使用基于连接状态的检测机制，将通信双方之间交互的属于同一连接的所有报文都作为整体的数据流来对待。为数据流的第一个报文建立会话，数据流内的后续报文直接根据会话进行转发，提高了转发效率。

会话机制

会话是通信双方的连接在防火墙上的具体体现，代表两者的连接状态，一条会话就表示通信双方的一个连接。防火墙上多条会话的集合就叫做会话表（Sessiontable）

示例：

httpVPN:public-->public1.1.1.1:2049-->2.2.2.2:80

表项中的关键字段：

http表示协议（此处显示的是应用层协议，该会话在IP报文头中的协议是TCP协议）

1.1.1.1表示源地址

2049表示源端口

2.2.2.2表示目的地址

80表示目的端口

通过“–>”符号就可以直观区分，符号前面的是源，符号后面的是目的

源地址、源端口、目的地址、目的端口和协议这五个元素是会话的重要信息，称之为“五元组”

一个五元组同属一条流，在防火墙上通过这五个元素就可以确定唯一一条连接

会话是动态生成的，但不是永远存在的。如果长时间没有报文匹配，则说明通信双方已经断开了连接，不再需要该条会话了。此时，为了节约系统资源，防火墙会在一段时间后删除会话，该时间称为会话的老化时间。

验证状态检测机制

拓扑：

防火墙上只配置了一条规则：允许PC访问Web服务器的报文通过。在PC上使用HttpClient程序访问Web服务器，发现可以成功访问：

在防火墙上使用displayfirewallsessiontable命令查看会话表的信息，发现已经建立一条会话：

说明状态检测机制工作正常，防火墙收到Web服务器返回给PC的报文后，发现该报文可以匹配到该条会话，即使没有配置允许反方向报文通过的规则，防火墙也允许其通过。

安全策略

防火墙的基本作用是保护特定网络免受“不信任”的网络的攻击，但是同时还必须允许两个网络之间可以进行合法的通信。安全策略的作用就是对通过防火墙的数据流进行检验，符合安全策略的合法数据流才能通过防火墙。

如上图所示，可以在不同的域间方向应用不同的安全策略进行不同的控制。

安全策略是由匹配条件和动作（允许/拒绝）组成的控制规则，可以基于IP、端口、协议等属性进行细化的控制。例如下边这条安全策略控制源IP是1.1.1.1的流量可以访问目的地址为2.2.2.2的Web服务器。

缺省情况下，所有域间的所有方向都禁止报文通过。

对于路由、ARP等底层协议一般是不受安全策略控制的，直接允许通过。当然这和具体产品实现有关，产品间可能有差异。

除了经过防火墙转发的数据流，设备本身与外界互访的数据流也同样受安全策略的控制哦！例如当登录设备、网管与设备对接时，需要配置登录PC/网管所在安全区域与Local域之间的安全策略。

华为防火墙还支持配置域内策略，也就对同一个安全区域内经过防火墙的流量进行安全检查。当然缺省情况下是允许所有域内报文通过防火墙的。

防火墙出于安全考虑缺省情况拒绝所有流量经过，但是这个缺省情况是可以修改的，这就是“缺省包过滤”。如果流量没有匹配到任何安全策略，将按缺省包过滤的动作进行处理。因此实现上述需求可只配置拒绝流量通过的安全策略，缺省包过滤改为permit。

安全策略的应用方向

一个域间有Inbound和Outbound两个方向，那是否需要为访问的双向流量同时配置安全策略呢？No，对于同一条数据流，在访问发起的方向上应用安全策略即可反向报文不需要额外的策略。这点和路由器、交换机包过滤不一样，主要原因就是防火墙是状态检测设备，对于同一条数据流只有首包匹配安全策略并建立会话，后续包都匹配会话转发。

:::info
如上图所示，Trust域的PC访问Untrust域的Server，只需要在Trust到Untrust的Outbound方向上应用安全策略允许PC访问Server即可，Server回应PC的应答报文会命中首包建立的会话而允许通过。如果确实需要开放Server主动访问PC的权限，这时才需要在Inbound方向上也应用安全策略。

:::

安全策略的匹配

防火墙将流量的属性与安全策略的条件进行匹配。如果所有条件都匹配，则此流量成功匹配安全策略。如果其中有一个条件不匹配，则未匹配安全策略。

同一域间或域内应用多条安全策略，策略的优先级按照配置顺序进行排列，越先配置的策略优先级越高，越先匹配报文。如果报文匹配到一条策略就不再继续匹配剩下的策略，如果没有匹配到任何策略就按缺省包过滤处理。所以配置策略还是有一定讲究的，要先细后粗。

例子：企业FTP服务器地址为10.1.1.1，办公区IP段为10.2.1.0/24，要求禁止两台临时办公PC（10.2.1.1、10.2.1.2）访问FTP服务器。如下这样配置有什么问题？

这样配置将无法实现“禁止两台临时办公PC（10.2.1.1、10.2.1.2）访问FTP服务器”的需求因为这两个IP已经命中了第一条宽泛的策略，无法再命中第二条策略。所以两条策略需要调换顺序。

安全策略的发展

随着防火墙产品的推陈出新，包过滤也逐渐进化，已经发展成为可以做深度内容检查的“安全策略”。策略匹配条件也已经在“五元组”的基础上增加了用户、应用等匹配条件，还增加了内容安全检测处理。下图展现了安全策略的发展历程，大家可以看到NGFW中已经实现了基于“七元组”的安全策略。细粒度的安全管控使藏匿于流量中的危险分子无所遁形。

USG2000/5000是UTM产品，USG6000是下一代防火墙NGFW产品。USG9500高端墙也在逐步切换到安全策略，单纯基于ACL的包过滤正在逐步退出历史舞台。

基于ACL的包过滤

前期已经提到这种单纯的包过滤正在逐步退出历史舞台

包过滤的处理过程：
1、获取需要转发数据包的报文头信息
2、与设定的ACL规则进行比较，根据比较的结果对数据包进行转发或者丢弃

实现包过滤的核心技术是访问控制列表ACL

因此包过滤只能基于IP地址、端口号等控制流量是否可以通过防火墙，无法准确识别应用。

基于ACL的包过滤的配置方式是先配置好包含多条数据流规则（rule）的ACL，其中每条rule包含数据流的匹配条件和permit/deny动作，然后ACL再被域间包过滤引用。一个域间只能引用一个ACL。

发展中期的UTM设备安全策略

随着USG2000/5000系列UTM产品的推出，“安全策略”这个概念被提出。是因为策略中集成了UTM检测功能，配置方式也由ACL方式变为Policy方式。所以不叫包过滤了。

通过下边界面可以直观的看到安全策略的组成：

包过滤+UTM。不启用UTM功能时就是原始的包过滤；动作为permit的安全策略可以引用IPS、AV等UTM策略，对流量进一步进行UTM检测，通过检测的流量才能真正通过防火墙。

华为UTM产品中已经增加“用户”这个匹配条件，另外配置方式上也变为Policy方式，即在配置安全策略时直接指定匹配数据流的多种条件以及动作，配置更简单。

此时的安全策略已经有一体化安全处理的雏形了，将防火墙包过滤功能和内容安全功能进行了融合，但是还有一定局限性。

UTM更多的是体现功能集成，将传统防火墙、入侵防御设备、反病毒设备等集成到一个硬件。UTM设备的多个安全功能之间的紧密度不高，报文匹配安全策略的匹配条件后需要逐一进入各个UTM模块进行检测和处理，如果同时开启多个安全功能，设备性能往往大幅下降。

另外基于应用的管控需要配置额外的应用控制策略，不能直接将应用类型作为策略的匹配条件。例如需要禁止员工使用IM应用，此时要额外配置禁止IM应用的“应用控制策略”然后再在安全策略引用生效。也就是应用识别与管控需要进入另外一个模块处理。这样就需要引入新的概念

NGFW（NextGenerationFirewall）一体化安全策略

到了NGFW（下一代防火墙）阶段，对一体化、应用识别与管控、高性能等要求更高。安全策略充分体现了这些特质，通过应用、用户、内容、威胁等多个维度的识别将模糊的网络环境映射为实际的业务环境，从而实现精准的访问控制和安全检测。

那么NGFW安全策略在配置和实现上到底有哪些不同呢？

• NGFW之前的安全策略都是应用在域间的（安全区域必配），NGFW的安全策略应用在全局，安全区域与IP地址等一样只是作为可选的匹配条件。而且安全区域支持多选。这样配置更灵活，可以不关注安全区域、域间方向，只需关注访问的源/目的。另外还可以实现跨多域的访问的一次性配置。
• 缺省包过滤也是全局只有一条，不再区分域间。
• 增加应用作为匹配条件，对应用的阻断/允许直接在安全策略中配置。
• 增加用户作为匹配条件，实现基于用户的管控，即使IP发生变化用户的权限也是不变的。
• 也就是应用和用户的识别都融入了防火墙安全策略的处理流程中，无论从配置还是设备处理上都体现了“一体化”。
• 通过高性能的一体化检测引擎实现一次扫描、实时检测，即使开启所有内容安全功能，也不会造成设备性能的大幅下降。

安全策略配置

来使用eNSP实战一把安全策略的配置。通过eNSP搭建如下环境，FTP客户端经过防火墙访问FTP服务器，安全策略怎么配置呢？

这还不容易，在Trust到Untrust配置安全策略，指定源/目的IP、指定协议为FTP不就好了。

然后我们看看FTP客户端能否成功访问？

怎么看不到服务器文件，看日志信息发现用户认证已经通过了，但是数据连接建立失败。

再检查一下配置：Trust和Untrust的域间缺省包过滤关闭，在Outbound方向配置了允许PC访问FTP服务器的一条安全策略。

查看会话表也成功建立了会话：

那分析一下FTP协议是否有什么特殊之处呢？

FTP协议是一个典型的多通道协议，在其工作过程中，FTPClient和FTPServer之间将会建立两条连接：控制连接和数据连接。控制连接用来传输FTP指令和参数，其中就包括建立数据连接所需要的信息；数据连接用来获取目录及传输数据。数据连接使用的端口号是在控制连接中临时协商的。

根据数据连接的发起方式FTP协议分为两种工作模式：主动模式（PORT模式）和被动模式（PASV模式）。主动模式中，FTPServer主动向FTPClient发起数据连接；被动模式中，FTPServer被动接收FTPClient发起的数据连接。

模式在一般的FTP客户端中都是可以设置的，这里我们以主动模式为例进行讲解，主动模式的协议交互流程如下：

首先FTP客户端向FTP服务器的21端口发起连接建立控制通道，然后通过PORT命令协商客户端使用的数据传输端口号。协商成功后，服务器主动向客户端的这个端口号发起数据连接。而且每次数据传输都会协商不同的端口号。

而我们配置的安全策略仅开放了FTP协议，也就是21端口。当FTP客户端向服务器发起控制连接时建立了如下会话。

而服务器向客户端发起数据连接的源/目的端口号分别是20和临时协商的端口号yyyy，显然不是这条连接的后续报文，无法命中此会话转发。因此会出现可以验证用户密码，但是无法获取目录列表的现象。

那么在服务器到客户端的方向也配置安全策略就行了吧？这是一种方法，但是这样必须开放客户端的所有端口有安全隐患。要是有一种方法可以自动记录数据连接就好了！这就需要引入ASPF（ApplicationSpecificPacketFilter）

ASPF（ApplicationSpecificPacketFilter）

ASPF是针对应用层的包过滤其原理是检测通过设备的报文的应用层协议信息，记录临时协商的数据连接，使得某些在安全策略中没有明确定义要放行的报文也能够得到正常转发。

记录临时协商的数据连接的表项称为Server-map表这相当于在防火墙上开通了“隐形通道”，使得像FTP这样的特殊应用的报文可以正常转发。当然这个通道不是随意开的，是防火墙分析了报文的应用层信息之后，提前预测到后面报文的行为方式，所以才打开了这样的一个通道。

Server-map表在防火墙转发中非常重要，不只是ASPF会生成，NATServer、SLB等特性也会生成Server-map表

ASPF怎么配置呢，很简单，在域间配置一条命令即可deteceprotocol。

FTP访问成功：

此时查看Server-map，可以看到已经自动生成了维护FTP数据连接的表项：

Server-map表中记录了FTP服务器向FTP客户端的2071端口号发起的数据连接，服务器向客户端发起数据连接时将匹配这个Server-map表转发，而无需再配置反向安全策略。

数据连接的第一个报文匹配Server-map表转发后，防火墙将生成这条数据连接的会话，该数据连接的后续报文匹配会话表转发，不再需要重新匹配Server-map表项。

Server-map表项由于一直没有报文匹配，经过一定老化时间后就会被删除。这种机制保证了Server-map表项这种较为宽松的通道能够及时被删除，保证了网络的安全性。当后续发起新的数据连接时会重新触发建立Server-map表项。

上述以FTP协议的主动模式为例

配置了ASPF可以生成动态维护临时协商的数据连接的表项，既简化了安全策略的配置又确保了安全性。

单包攻击及防御

提到“网络攻击”，就不能不说说DoS/DDoS攻击，防范DoS/DDoS攻击是防火墙的基本安全功能，九十年代，攻击随着互联网的蓬勃发展从实验室走向了Internet。全球的攻击爱好者由于共同的信仰“OpenFreeShare（开源、免费、共享）”建立了同盟，很多年以后这帮人被叫做“黑客”。最初的黑客一般都是一些高级的技术人员，他们热衷于挑战、崇尚自由并主张信息的共享。随着Internet在全球的迅猛发展，政治、经济、军事、科技、教育、文化、生活等各个方面都逐渐网络化，信息已经成为物质和能量以外维持人类社会的第三资源，黑客也逐渐变成了一种有特殊目的的产业。

什么是DoS攻击

DoS是DenialofService的简称，即拒绝服务，造成DoS的攻击行为被称为DoS攻击，其目的是使计算机或网络无法提供正常的服务。

“拒绝服务”是什么意思呢？

就像街边有一个小餐馆为大家提供餐饮服务，但是这条街上有一群地痞总是对餐馆搞破坏，比如：霸占着餐桌不让其他客人吃饭也不结账、或者堵住餐馆的大门不让客人进门，甚至骚扰餐馆的服务员或者厨师不让他们正常干活，这样餐馆就没有办法正常营业了，这就是“拒绝服务”。

黑客想要对这些计算机或者服务器进行DoS攻击的话，也使用消耗计算机或服务器性能、抢占链路带宽等手段！最常见的DoS攻击就是我们常常提到的单包攻击。这类攻击一般都是以个人为单位的黑客发动的，攻击报文也比较单一，虽然破坏力强大，但是只要掌握了攻击的特征，防御起来还是比较容易的。

防火墙支持的单包攻击包括以下三大类：

• 畸形报文攻击：通常指攻击者发送大量有缺陷的报文，从而造成主机或服务器在处理这类报文时系统崩溃。
• 扫描类攻击：是一种潜在的攻击行为，并不具备直接的破坏行为，通常是攻击者发动真正攻击前的网络探测行为。
• 特殊控制报文攻击：也是一种潜在的攻击行为，不具备直接的破坏行为，攻击者通过发送特殊控制报文探测网络结构，为后续发动真正的攻击做准备。

单包攻击防御是防火墙具备的最基本的防范功能，华为全系列防火墙都支持对单包攻击的防御。

几种典型的单包攻击

PingofDeath攻击及防御

操作系统处理数据包的大小是有限制的，IP报文的长度字段为16位，即IP报文的最大长度为65535。如果遇到大小超过65535的报文，会出现内存分配错误，从而使接收方的计算机系统崩溃。PingofDeath攻击就是攻击者不断的通过Ping命令向攻击目标发送超过65535的报文，就可以使目标计算机的TCP/IP堆栈崩溃，致使接收方系统崩溃。

防火墙在处理PingofDeath攻击报文时，是通过判定数据包的大小是否大于65535字节，如果数据包大于65535字节，则判定为攻击报文，直接丢弃。

Land攻击及防御

Land攻击是指攻击者向受害者发送伪造的TCP报文，此TCP报文的源地址和目的地址同为受害者的IP地址。这将导致受害者向它自己的地址发送回应报文，从而造成资源的消耗。

防火墙在处理Land攻击报文时，通过检查TCP报文的源地址和目的地址是否相同，或者TCP报文的源地址是否为环回地址，如果是则丢弃。

IP地址扫描攻击

IP地址扫描攻击是攻击者运用ICMP报文（如Ping和Tracert命令）探测目标地址，或者使用TCP/UDP报文对一定地址发起连接，通过判断是否有应答报文，以确定哪些目标系统确实存活着并且连接在目标网络上。

防火墙对收到的TCP、UDP、ICMP报文进行检测，当某源IP地址连续发送报文的目的IP地址与前一个报文的目的IP地址不同时，则记为一次异常，当异常次数超过预定义的阈值时，则认为该源IP的行为为IP地址扫描行为，防火墙会将该源IP地址加入黑名单。

IP地址扫描攻击并没有直接造成什么恶劣后果，它只是一种探测行为，通常是为了后续发动破坏性攻击做准备，尽管如此，这种行为防火墙也不会放过的。

单包攻击一般都具有明显的特征，所以防火墙在防御单包攻击时，只要匹配了攻击特征，就可以很容易防御。

配置建议

防火墙支持的单包攻击防御种类繁多，在现网使用过程中，哪些需要配置，或者哪些不建议配置

建议开启的单包攻击防御一般是现网比较常见的攻击，这种攻击开启以后，防火墙可以很好的进行防御，对性能等方面没有影响。而扫描类攻击在防御过程中比较消耗防火墙的性能，所以不建议开启。

单包攻击在现网中所占的比例并不高，现网中最主流，也让人们最头疼的攻击其实是DDoS攻击。DDoS攻击种类比较多，华为防火墙支持的DDoS攻击包括SYNFlood、UDPFlood、ICMPFlood等流量型攻击，以及HTTPFlood、HTTPSFlood、DNSFlood等应用层攻击

流量型攻击之SYNFlood及防御

在现网中单包攻击只占了很小一部分比例，更多的攻击还是集中在流量型攻击和应用层攻击。

攻击者所面临的主要问题是网络带宽，由于较小的网络规模和较慢的网络速度的限制，攻击者无法发出过多的请求。虽然类似“PingofDeath”的攻击类型只需要较少量的包就可以摧毁一个没有打过补丁的操作系统，但大多数的DoS攻击还是需要相当大的带宽，而以个人为单位的黑客们很难消耗高带宽的资源。为了克服这个缺点，DoS攻击者开发了分布式的攻击。

木马成为黑客控制傀儡的工具，越来越多的计算机变成了肉鸡，被黑客所利用，并变成了他们的攻击工具。黑客们利用简单的工具集合许多的肉鸡来同时对同一个目标发动大量的攻击请求，这就是DDoS(DistributedDenialofService)攻击。随着互联网的蓬勃发展，越来越多的计算机不知不觉的被利用变成肉鸡，攻击逐渐变成一种产业。

提起DDoS攻击，首先想到的一定是SYNFlood攻击。

最初的SYNFlood攻击类似于协议栈攻击，在当年的攻击类型中属于技术含量很高的“高大上”。当年由于系统的限制以及硬件资源性能的低下，称霸DDoS攻击领域很久。它与别人的不同在于，你很难通过单个报文的特征或者简单的统计限流防御住它，因为它“太真实”、“太常用”。

SYNFlood具有强大的变异能力，在攻击发展潮流中一直没有被湮没，这完全是他自身的优秀基因所决定的：

• 单个报文看起来很“真实”，没有畸形。
• 攻击成本低，很小的开销就可以发动庞大的攻击。

2014年春节期间，某IDC的OSS系统分别于大年初二、初六、初七连续遭受三轮攻击，最长的一次攻击时间持续将近三个小时，攻击流量峰值接近160Gbit/s！事后，通过对目标和攻43攻击防范篇击类型分析，基本可以判断是有一个黑客/黑客组织发起针对同一目标的攻击时间。经过对捕获的攻击数据包分析，发现黑客攻击手段主要采用SYNFlood。

2013年，某安全运营报告显示，DDoS攻击呈现逐年上升趋势，其中SYNFlood攻击的发生频率在2013全年攻击统计中占31%。

攻击原理

TCP三次握手

SYNflood是基于TCP协议栈发起的攻击，在了解SYNflood攻击和防御原理之前，还是要从TCP连接建立的过程开始说起。在TCP/IP协议中，TCP协议提供可靠的连接服务，无论是哪一个方向另一方发送数据前，都必须先在双方之间建立一条连接通道，这就是传说中的TCP三次握手。

第一次握手：客户端向服务器端发送一个SYN（Synchronize）报文，指明想要建立连接的服务器端口，以及序列号ISN

第二次握手：服务器在收到客户端的SYN报文后，将返回一个SYN+ACK的报文，表示客户端的请求被接受，同时在SYN+ACK报文中将确认号设置为客户端的ISN号加1。ACK即表示确认（Acknowledgment）

第三次握手：客户端收到服务器的SYN-ACK包，向服务器发送ACK报文进行确认，ACK报文发送完毕，三次握手建立成功。

如果客户端在发送了SYN报文后出现了故障，那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的，即第三次握手无法完成，这种情况下服务器端一般会重试，向客户端再次发送SYN+ACK，并等待一段时间。如果一定时间内，还是得不到客户端的回应，则放弃这个未完成的连接。这也是TCP的重传机制。

防火墙针对SYNFlood攻击，一般会采用TCP代理和源探测两种方式进行防御。

TCP代理

TCP代理是指我们的防火墙部署在客户端和服务器中间，当客户端向服务器发送的SYN报文经过防火墙时，防火墙代替服务器与客户端建立三次握手。一般用于报文来回路径一致的场景。

• 防火墙收到SYN报文，对SYN报文进行拦截，代替服务器回应SYN+ACK报文
• 如果客户端不能正常回应ACK报文，则判定此SYN报文为非正常报文，防火墙代替服务器保持半连接一定时间后，放弃此连接。
• 如果客户端正常回应ACK报文，防火墙与客户端建立正常的三次握手，则判定此SYN报文为正常业务报文，非攻击报文。防火墙立即与服务器再建立三次握手，此连接的后续报文直接送到服务器。

整个TCP代理的过程对于客户端和服务器都是透明的。TCP代理过程中，防火墙会对收到的每一个SYN报文进行代理和回应，并保持半连接，所以当SYN报文流量很大时，对防火墙的性能要求非常的高。

TCP代理的本质就是利用防火墙的高性能，代替服务器承受半连接带来的资源消耗，由于防火墙的性能一般比服务器高很多，所以可以有效防御这种消耗资源的攻击。

但是TCP代理只能应用在报文来回路径一致的场景中，如果来回路径不一致，代理就会失败。那这种情况下如果发生了SYNFlood攻击，防火墙要怎么防呢？

TCP源探测

TCP源探测是防火墙防御SYNFlood攻击的另一种方式，没有报文来回路径必须一致的限制，所以应用普遍。

• 当防火墙收到客户端发送的SYN报文时，对SYN报文进行拦截，并伪造一个带有错误序列号的的SYN+ACK报文回应给客户端。
• 如果客户端是虚假源，则不会对错误的SYN+ACK报文进行回应。
• 如果客户端是真实源发送的正常请求SYN报文，当收到错误的SYN+ACK报文时，会再发出一个RST报文，让防火墙重新发一个正确的SYN+ACK报文；防火墙收到这个RST报文后，判定客户端为真实源，则将这个源加入白名单，在白名单老化前，这个源发出的报文都认为是合法的报文，防火墙直接放行，不在做验证。

现TCP源探测对客户端的源只做一次验证通过后，就加入白名单，后续就不会每次都对这个源的SYN报文做验证，这样大大提高了TCP源探测的防御效率和防御性能，可以有效缓解防火墙性能压力。

很长一段时间里，SYNFlood在防火墙TCP代理和TCP源探测双重防御的压制下，得到了遏制。但是随着木马被广泛植入到更多的肉鸡，一个初级黑客简单操作就可以操纵动则上G流量的时候，SYNFlood变得更加嗜血。TCP代理和TCP源探测方式说到底都是使用防火墙牺牲自身的CPU不断的来解决问题。但是一旦海量低开销的SYNFlood攻击报文同时蜂拥而至时，这种伤敌一千自损八百的方式将走向另外一个极端，防火墙很有可能成为瓶颈。华为防火墙在不断提升自身性能的同时，还是可以承担一定的开销。但是传统的防御手段都是反弹，也就是说如果攻击流量是1G的话，防火墙的反弹流量也有1G，这样就相当于有2G的“攻击”流量在互联网上占据着带宽，我们在防御的过程中不自觉的放大了垃圾流量，拥塞了链路。

随着SYNFlood攻击的不断变异，防火墙也一直不断地提升着自身的防御能力。TCP提供可靠的传输层，其中可靠性的保障之一就是确认从另一端收到的数据。但是数据和确认在传输过程中都有丢弃的可能，所以TCP通过在发送时设置一个定时器来解决这个问题。如果定时器到达设置的时间了，还是没有收到某个数据的确认报文，则TCP就会重传这个数据。华为专业AntiDDoS设备正是利用了TCP这种重传的机制，推出“首包丢弃”功能与“TCP源探测”结合的防御方式，以应对超大流量的SYNFlood攻击。当SYN报文蜂拥而至时，专业AntiDDoS设备会将收到的第一个报文记录并直接丢弃，然后等待第二个重传报文。收到重传报文后，再对重传报文进行源探测。

虽然防火墙具备DDoS防御能力，但是他毕竟不是专业的防攻击设备，术业有专攻，华为公司推出的AntiDDoS1000和AntiDDoS8000系列是专业的AntiDDoS设备

流量型攻击之UDPFlood及防御

UDP协议与TCP协议不同，UDP是一个无连接协议。使用UDP协议传输数据之前，客户端和服务器之间不建立连接，如果在从客户端到服务器端的传递过程中出现数据报的丢失，协议本身并不能做出任何检测或提示。通常人们把UDP协议称为不可靠的传输协议。

在有些情况下UDP协议可能会变得非常有用。因为UDP具有TCP所望尘莫及的速度优势。虽然TCP协议中植入了各种安全保障功能，但是在实际执行的过程中会占用大量的系统开销，无疑使传输速度受到严重的影响。反观UDP，由于排除了信息可靠传递机制，将安全和排序等功能移交给上层应用来完成，极大降低了执行时间，使传输速度得到了保证。

正是UDP协议的广泛应用，为黑客们发动UDPFlood攻击提供了平台。UDPFlood属于带宽类攻击，黑客们通过僵尸网络向目标服务器发起大量的UDP报文，这种UDP报文通常为大包，且速率非常快，通常会造成以下危害：

• 消耗网络带宽资源，严重时造成链路拥塞。
• 大量变源变端口的UDPFlood会导致依靠会话转发的网络设备，性能降低甚至会话耗尽，从而导致网络瘫痪。

防火墙对UDPFlood的防御并不能像SYNFlood一样，进行源探测，因为它不建立连接。

最初防火墙对UDPFlood的防御方式就是限流，通过限流将链路中的UDP报文控制在合理的带宽范围之内。

防火墙上针对UDPFlood的限流有三种：

• 基于目的IP地址的限流：即以某个IP地址作为统计对象，对到达这个IP地址的UDP流量进行统计并限流，超过部分丢弃。
• 基于目的安全区域的限流：即以某个安全区域作为统计对象，对到达这个安全区域的UDP流量进行统计并限流，超过部分丢弃。
• 基于会话的限流：即对每条UDP会话上的报文速率进行统计，如果会话上的UDP报文速率达到了告警阈值，这条会话就会被锁定，后续命中这条会话的UDP报文都被丢弃。当这条会话连续3秒或者3秒以上没有流量时，防火墙会解锁此会话，后续命中此会话的报文可以继续通过。

限流虽然可以有效缓解链路带宽的压力，但是这种方式简单粗暴，容易对正常业务造成误判。为了解决这个问题，防火墙又进一步推出了针对UDPFlood的指纹学习功能。

UDPFlood攻击报文具有一定的特点，这些攻击报文通常都拥有相同的特征字段，比如都包含某一个字符串，或整个报文内容一致。这些字段来自于DDoS工具自带的默认字符串，所以防火墙是通过收集这些字符串来检测UDPFlood。这种防御算法在现网使用很多，主要因为黑客为了加大攻击频率，快速、长时间挤占攻击目标所在网络带宽，在使用攻击工具实现时直接在内存存放一段内容，然后高频发送到攻击目标，所以攻击报文具有很高的相似性。而正常业务的UDP报文一般每个报文负载内容都是不一样的，这样可以减少误判。

从下面的抓包中可以看出，到达相同目的IP地址的两个UDP报文的载荷是完全一样的，如果防火墙收到大量的类似这样的UDP报文，那么就有可能是发生了UDPFlood攻击。

指纹学习是通过分析客户端向服务器发送的UDP报文载荷是否有大量的一致内容，来判定这个UDP报文是否异常。防火墙对到达指定目的地的UDP报文进行统计，当UDP报文达到告警阈值时，开始对UDP报文的指纹进行学习。如果相同的特征频繁出现，就会被学习成指纹，后续命中指纹的报文判定这是攻击报文，作为攻击特征进行过滤。

防火墙防御UDPFlood攻击主要有两种方式：限流和指纹学习

限流方式属于暴力型，可以很快将UDP流量限制在一个合理的范围内，但是不分青红皂白，超过就丢，可能会丢弃正常报文；而指纹学习属于理智型，不会随意丢弃报文，但是发生攻击后需要有个指纹学习的过程。目前，指纹学习功能是针对UDPFlood攻击的主流防御手段，在华为防火墙产品中广泛应用。

应用层攻击及防御

随着计算机硬件的不断提升，运营商网络不断的扩容，防火墙逐渐在线上增加，依靠抢占带宽制造的流量型攻击效果越来越差。黑客们开始寻求新的突破，转而向上进行应用层的攻击，应用层攻击逐渐变为黑客的焦点。应用层攻击比传输层攻击对于目标服务器造成更大的伤害。比如大型网站动态数据库链接的不断调用会比SYNFlood更加消耗系统的资源。今天强叔就给大家讲讲防火墙支持的DNSFlood和HTTPFlood攻击以及防御对策。

2009年5月19日晚，江苏、安徽、广西、海南、甘肃、浙江等6省，分别报告省内域名递归解析服务因大量DNS请求陆续出现故障，其他多个省市则报告互联网域名解析服务出现异常，互联网运行受到严重影响，网络长时间处于断网状态。

5月19日事发当晚，攻击者受利益驱使，对其他游戏“私服”网站的域名解析服务器DNSPod实施攻击，攻击流量超过10G，导致DNSPod域名解析服务瘫痪。而DNSPod同时为暴风影音公司网站提供域名解析服务。

由于暴风影音软件中，有一项强制随机启动的名为stormliv.exe的进程，只要用户安装了暴风影音，该进程就会自动运行，并不断连接暴风影音网站，下载广告或升级。因此，当DNSPod服务器被攻击瘫痪时，数以千万计的暴风影音用户就充当了“肉鸡”，向运营商DNS递归服务器发送大量请求，DNS访问流量瞬间就超过30G，导致了本次重大网络安全事件。

随后，公安机关介入侦查，攻击者于5月29日被抓获。调查发现，他们长期在互联网上经营游戏“私服”，并租用服务器专门协助他人攻击其他游戏“私服”和“私服”网站以谋取利益。

应用层攻击造成的伤害是巨大的，直接会影响到我们的正常生活，加强应用层攻击防御刻不容缓。下面强叔就从DNSFlood讲起。

DNSFlood

通常情况下，我们在上网访问网页的时候，输入的网址都是域名，比如www.huawei.com，这个请求的域名会发送到DNS缓存服务器，以请求其对应的IP地址。如果DNS缓存服务器上有此域名和IP地址的映射关系，DNS缓存服务器就会将查询到得IP地址返回给客户端。当DNS缓存服务器查找不到该域名与IP地址对应关系时，它会向授权DNS服务器发出域名查询请求。为了减少Internet上DNS的通信量，DNS缓存服务器会将查询到的域名和IP地址对应关系存储在自己的本地缓存中。后续再有主机请求该域名时，DNS缓存服务器会直接用缓存区中的记录信息回应，直到该记录老化，被删除。

常见的DNSFlood攻击一般都是攻击者向DNS服务器发送大量的不存在的域名解析请求，导致DNS缓存服务器不停向授权服务器发送解析请求，最终导致DNS缓存服务器瘫痪，影响对正常请求的回应。

从DNS协议本身讲起。DNS服务器支持TCP和UDP两种协议的查询方式，但是大多数的查询都是使用UDP查询的，UDP提供无连接服务，传输速度快，可以降低服务器的负载。

特殊情况需要通过TCP方式查询，其中之一，就是DNS服务器可以设定使用TCP连接。当客户端向DNS服务器发起查询请求时，DNS回应报文里有一个TC标志位，如果TC标志位置1，就表示需要通过TCP方式查询。华为防火墙就是利用这一机制对DNSFlood攻击进行防御。

当发生DNSFlood攻击时，防火墙收到DNS请求，会代替DNS服务器响应DNS请求，并将TC标志位置1，要求DNS客户端以TCP方式发送DNS请求。

• 如果客户端是真实源，会继续以TCP方式发送DNS请求。
• 如果客户端是虚假源，则不会再以TCP方式发送DNS请求。

看一组真实客户端正常响应防火墙源探测的抓包信息：

客户端向DNS服务器以UDP方式发送查询请求。

防火墙将TC标志位置1，让客户端以TCP方式发送请求。

客户端以TCP方式发送DNS请求。

这种方式可以很好的防御针对缓存服务器的DNS请求攻击，但是在现网使用过程中，并不是所有场景都适用。在源探测过程中，防火墙会要求客户端通过TCP方式发送DNS请求，但是并不是所有的客户端都支持以TCP方式发送DNS请求，所以这种方式在使用过程中也有限制。如果有正常客户端不支持以TCP方式发送DNS请求，使用此功能时，就会影响正常业务。

HTTPFlood

常见的HTTPFlood攻击，一般指黑客通过代理或僵尸主机向目标服务器发起大量的HTTP报文，这些请求涉及数据库操作的URI或其它消耗系统资源的URI，目的是为了造成服务器资源耗尽，无法响应正常请求。

防火墙对于HTTPFlood的防御，主要依靠HTTP协议所支持的重定向方式

客户端向服务器请求www.sina.com，服务器可以返回一个命令，让客户端改为访问www.sohu.com。这种重定向的命令在HTTP协议栈中是合法的。我们防火墙的防御机制就是利用这个技术点，来探测HTTP客户端是否为真实存在的主机。

HTTP报文的正常重定向过程是这样的：

防火墙正是利用了HTTP报文的这种重定向机制，在防御HTTPFlood攻击过程中，向客户端重定向一个其他的URI。

当客户端访问search1.huawei.com的时候，防火墙重定向了一个search2.huawei.com地址给客户端让它访问：

• 如果客户端是虚假源，在收到防火墙发送的重定向地址后，不会重新发送HTTP请求。
• 如果客户端是真实源，则会对防火墙的重定向报文进行响应，并重新向search2.huawei.com地址发送请求。这样，防火墙收到search2.huawei.com请求后，即可判定这个客户端是真实源，并将这个客户端加入白名单。

虽然在整个过程中，客户端需要自动重定向两次，但是时间是很短的，不会影响客户体验

看一组真实客户端正常响应防火墙重定向请求的抓包信息：

客户端请求包含URI为“/index.html”的页面。

防火墙对请求报文进行确认，并重定向一个新的URI“/index.html?sksbjsbmfbclwjcc”给客户端。

客户端重新请求包含URI为“/index.html?sksbjsbmfbclwjcc”的页面。

防火墙对包含新URI的请求进行确认，并将地址重新定向成包含URI为“/index.html”的页面。认证通过，后续客户端可以直接和服务器进行通信。整个过程对于用户来说是透明的，重定向操作由客户端浏览器自动完成

该模式可有效阻止来自非浏览器客户端的访问，如果僵尸工具没有实现完整的HTTP协议栈，不支持自动重定向，无法通过认证。而浏览器支持自动重定向，可以通过认证。这种防御方式在使用过程中，要确认客户端是否支持重定向。

比如，常见的机顶盒就不支持自动重定向。所以在使用这种防御方式时，一定要确认所在的网络是否有机顶盒等客户端的正常业务，如果有，就不能使用此功能，否则会影响正常业务。

阈值配置

告警阈值配置要合理，如果配置过大，来攻击的时候就会防不住；如果配置过小，可能会把正常业务误判为攻击报文进行处理。

每个网络的流量模型都不同，配置阈值之前，需要有个前提准备，就是要大概了解这个网络正常情况下的每种类型报文的基本流量模型。这个值可能是管理员的一个经验值，也可以通过监测一段时间后通过学习得知。比如，我们想配置SYNFlood防御功能，配置告警阈值前，要先了解没有发生攻击的情况下网络中SYN报文的最大速率是多少，而SYNFlood防御的告警阈值一般可以配置为正常流量时的1.2～2倍。配置完告警阈值后，还要连续多观察几天，看这个阈值对正常业务是否有影响，如果有影响，要及时调整成更大的值。

源NAT

源NAT技术通过对报文的源地址进行转换，使大量私网用户可以利用少量公网IP上网，大大减少了对公网IP地址的需求。

源NAT转换的过程：

当上网流量到达防火墙时，报文的私网源IP将被转换为公网IP；当回程报文到达防火墙时，报文的公网目的IP将被转换为私网IP。整个NAT转换过程对于内、外网主机来说是完全透明的。

NAT地址池

一个虚拟的概念，它形象地把“公网IP地址的集合”比喻成一个“放IP地址的池子或容器”

防火墙在应用源NAT功能时就是从地址池中挑选出一个公网IP，然后对私网IP进行转换。挑选哪个公网IP是随机的，和配置时的顺序、IP大小等因素都没有关系。

例子创建一个NAT地址池（以eNSP中的USG5500系列为例）

nataddress-group1202.169.1.2202.169.1.5

内网用户群（10.10.2.1-10.10.2.10）最初都在一个区域内，有两个公网IP（210.1.1.10和210.1.1.11）可用于做NAT转换，由于无需对这些用户进行区分，所以可将2个公网IP放在同一地址池内。上网流量到达防火墙后，将从地址池中随机选取一个公网IP做NAT转换。

网络运行一段时间后，需要对用户进行区分，使用户群1（10.10.2.1-10.10.2.5）和用户群2（10.10.2.6-10.10.2.10）以不同的公网IP上网。由于NAT转换是随机选取公网IP的，所以2个公网IP在同一地址池内是无法满足此要求的。

此时可将2个公网IP分别放在不同的地址池内，并指定用户群1使用地址池1做NAT转换，用户群2使用地址池2做NAT转换。这样，两个用户群做NAT转换后的IP就是不同的了。

华为防火墙支持的源NAT功能如下表：

NATNo-PAT

“No-PAT”表示不进行端口转换，所以NATNo-PAT只转换IP地址，故也称为“一对一IP地址转换”。

如下组网进行演示：

在FW上配置源NAT模式，选择为no-pat；将公网IP地址202.30.1.1和202.30.1.2加入NAT地址池1；配置NAT策略，即对流量设置各种要求项，只有完全匹配上这些要求的流量才能利用NAT地址池1中的IP做NAT转换（如果要针对源IP设置NAT策略，那么应该是做源NAT转换前的IP）。

配置NATNo-PAT

#
nat address-group1 202.30.1.1 202.30.1.2
#
nat-policy interzone trust untrust outbound
policy 1
action source-nat
policy source 192.168.0.0 0.0.0.255
address-group 1 no-pat//使用地址池1做NATNo-PAT转换

:::info
安全策略和黑洞路由

安全策略检验是否允许流量通过，NAT策略检验是否对流量进行NAT转换

由于防火墙检验流量是否符合安全策略的操作发生在检查NAT策略之前，所以如果要针对源IP设置安全策略，则该IP应该是做源NAT转换前的IP。

:::

配置安全策略

#
policyinterzonetrustuntrustoutbound
policy1
actionpermit
policysource 192.168.0.0 0.0.0.255

黑洞路由是一个让路由“有来无回”的路由，它的效果就是让设备丢弃命中该路由的报文。针对地址池中的公网IP必须配置黑洞路由，目的是防止产生路由环路。

配置黑洞路由

#
iproute-static 202.30.1.1255.255.255.255 NULL0
iproute-static 202.30.1.2255.255.255.255 NULL0

从PC1上pingPC2，在FW上查看会话表和Server-map表

从会话表中可以看到PC1（192.168.0.2）的IP进行了NAT转换（中括号[]内的是NAT转换后的IP和端口），而端口没有转换。

从Server-map表中可以看到NAT类型是No-PAT、NAT转换前后的IP地址，由于端口没有转换，所以并没有显示端口信息。这里可以注意到正、反向Server-map表中的目的IP均为any，也就是说只要Server-map表没有老化，理论上任何外网主机只要知道NAT转换后的IP，都可以主动访问内网主机的公网IP。

从PC1上pingServer2，在FW再上查看会话表和Server-map表。

做NAT转换后的公网IP还是202.30.1.1，而不是202.30.1.2。这说明：做源NAT时，虽然选择哪个公网IP是随机的，但是这个公网IP由私网源IP决定，和目的IP无关。只要私网源IP不变、地址池相关配置不变，同一个私网源IP就会固定的转换为同一个公网IP。

NAPT

NAPT表示网络地址端口转换，即同时对IP地址和端口号进行转换，也可称为PAT（PAT不是只转换端口号的意思，而是IP、端口号同时转换）。NAPT是最常用的源NAT技术之一，他可以实现用少量公网IP满足大量私网用户上网的需求。

NAPT和NATNo-PAT在配置上的区别仅在于选择不同的源NAT模式：NAPT的nat-policy在指定NAT地址池时，不配置命令关键字“no-pat”，其他配置都是类似的。

NAPT和NATNo-PAT配置上的差异点

#
nat-policy interzone trust untrust outbound
policy 1
address-group 1//不配置no-pat

从PC1上pingPC2，在FW上查看会话表。可以看到源IP和源端口都做了NAT转换，而且端口号是顺序转换的。

再看Server-map表，没有显示信息？

NAPT没有Server-map表！

NAPT主要用于让大量用户上网，如果每个连接都建立Server-map表，则会占用大量的设备资源。

从PC1上pingServer2，在FW上查看会话表。我们发现NAPT也是由源IP决定转换后的公网IP，且端口顺序转换。端口从2048开始转换的现象说明：对于不同的连接来说，NAT处理过程是彼此独立的。只要五元组不完全相同，就不用担心NAT转换冲突的问题（对于现在的网络通信来说，五元组完全一致的情况发生概率非常小）。

出接口地址方式（easy-ip）

出接口地址方式是利用出接口的公网IP做源NAT转换，适用于公网IP非常少或接口动态获取IP的场景（仅中低端防火墙支持接口动态获取IP）。

easy-ip的NAT转换方式和NAPT一样，都是同时转换IP和端口。但是在具体配置上，高端防火墙和中低端防火墙是不一样的：

• 高端防火墙需要配置NAT地址池，并将出接口IP配置在地址池中。实际上就是配置NAPT功能，只不过出接口IP和NAT地址池中的IP一样了。
• 中低端防火墙不需要配置NAT地址池，而是在NAT策略中指定做easy-ip转换。

使用如下组网进行演示

easy-ip无需配置NAT地址池，只需在NAT策略中指定利用哪个接口做easy-ip。安全策略的配置可以参考上面的NATNo-PAT，easy-ip不用配置黑洞路由

配置 easy-ip

#
nat-policy interzone trust untrust outbound
 policy 1
 action source-nat
 source-address 192.168.0.0 0.0.0.255
 easy-ip GigabitEthernet0/0/3 //源 NAT 转换后的公网 IP 为接口 GE0/0/3 的 IP

分别从PC1和PC2上pingServer，查看到会话表如下所示（部分PC1的会话已老化，GE0/0/3的IP是210.10.2.1/24）。可以看到源IP和端口都做了NAT转换，且转换后的端口是顺序增大的。这说明：虽然源IP不同，但是NAT转换都走同一个流程，所以端口号顺序增大。此外，和NAPT一样，easy-ip也是没有Server-map表的。

Smart NAT

Smart NAT 为何称为“聪明的NAT”？这要从他和NAT、No-PAT、NAPT的关联性说起：

假设SmartNAT使用的地址池中包含N个IP，其中一个IP被指定为预留地址，另外N-1个地址构成地址段1（section1）。进行NAT转换时，SmartNAT会先使用section1做NAT No-PAT类型的转换，当section1中的IP都被占用后，才使用预留IP做NAPT类型的转换。

由于 eNSP 不支持高端防火墙，所以我们通过一个实际的组网来看下 Smart NAT 的实现过程。

Smart NAT 的配置和 NAT No-PAT 的配置几乎完全一致，区别只是在地址池中指定了一个 IP 作为预留 IP，下面给出关键配置：

配置 Smart NAT

#
nat address-group 1
 mode no-pat //模式要选择 no-pat
 smart-nopat 30.1.1.21 //预留一个 IP 做 NAPT
 section 1 30.1.1.20 30.1.1.20 //section 中不能包含预留 IP！
#
policy interzone trust untrust outbound
policy 1
 action permit
 policy source 10.1.1.0 0.0.0.255
 policy source 20.1.1.0 0.0.0.255
#
nat-policy interzone trust untrust outbound
policy 1
 action source-nat
 address-group 1
 policy source 10.1.1.0 0.0.0.255
 policy source 20.1.1.0 0.0.0.255 

先从 PC2 上 ping PC3，再从 PC1 上 ping PC3（请注意这个顺序），在 USG9000 上查看会 话表 （中括号[]内的是 NAT 转换后的 IP 和端口）。 可以看到 PC2（20.1.1.11）只转换了 IP， 没有转换端口，也就是说做了 NAT No-PAT 转换。而 PC1（10.1.1.11）的 IP 和端口都进行 了转换，且转换后的 IP 就是预留 IP（30.1.1.21），所以说他做了 NAPT 转换。

我们再看 Server-map 表，结果也符合 NAT No-PAT 和 NAPT 功能的特点：只有 NAT No-PAT 类型的表项，NAPT 转换没有 Server-map 表。

三元组 NAT

三元组 NAT 中的“三元”是指：源 IP、源端口和协议

三元组 NAT 功能的产生基于这样一个事实：

现今大部分网络主机都处在 NAT 设备后，而 P2P 应用（如 QQ、BT）是人们最常用的软件之一。当 NAT 遇到 P2P 的时候，产生的不是完美 的“NAT-P2P” 事实上，当有 NAT 设备存在时，如果要保证内网用户正常使用 P2P 软件，往往还需要其他 网络设备来配合。而华为高端防火墙 USG9000 系列可以完美地解决这个问题：通过使用三 元组 NAT 功能，防火墙可以在做 NAT 网关的同时支持 P2P 业务的正常交互，完全不需要其 他设备！

为了引出三元组 NAT 的特点，我们先通过下图来看看 P2P 业务的一般交互流程。PC1 和 PC2 是两台运行 P2P 业务的客户端，他们运行 P2P 应用时首先会和 P2P 服务器进行交互（登录、 认证等操作），服务器会记录客户端的地址和端口。当 PC2 需要下载文件时，服务器会将拥 有该文件的客户端的地址和端口发送给 PC2（例如 PC1 的地址和端口），然后 PC2 会向 PC1 发送请求，并从 PC1 上下载文件。

如果 PC1 是内网主机，在防火墙上做 NAT 转换，此时 P2P 服务器记录的就是 PC1 做 NAT 转换后的地址和端口。也许有人会问：PC1 做 NAT 转换后的地址和端口不会变化吗？答案是 会变化，但是 PC1 会定期向服务器发送报文（用于认证等），服务器也就记录了最新的 NAT 后地址和端口，所以可以保证 PC2 能够成功访问PC1。

• PC1没有主动访问过PC2，一般来说，防火墙不会允许PC2主动访问PC1。
• PC1访问服务器时，NAT后的地址和端口只能被服务器用来访问PC1，其他主机（例如PC2）不能利用这个地址和端口访问PC1，请求报文在防火墙上将被丢弃。

三元组NAT可以完美地解决上述两个问题，依靠的正是以下两个特点：

• 支持外网主动访问，无论内网主机是否主动访问过某个外网主机，只要外网主机知道内网主机NAT转换后的地址和端口，就可以主动向该内网主机发起访问。

• 动态对外端口一致性，内网主机做NAT转换后的地址和端口将在一段时间内保持不变，在此时间内段，内网主机固定地使用此NAT后地址和端口访问任意外网主机，任意外网主机也可以通过此NAT后地址和端口访问内网主机。

  内网主机做 NAT 转换后的地址和端口将在一段时间内保持不变，在此时间内段，内网主机固 定地使用此 NAT 后地址和端口访问任意外网主机，任意外网主机也可以通过此 NAT 后地址 和端口访问内网主机。

从实现原理角度讲，三元组NAT是通过Server-map表使外网主机可以主动访问内网主机，并保证NAT转换关系在一段时间内保持不变。下面通过一个例子来说明会更容易理解（我们还是用实际设备来组网）。

三元组NAT和NATNo-PAT在配置上的区别仅在于选择不同的源NAT模式，下面给出关键配置：

#
nat address-group 1
 mode full-cone global //做三元组 NAT 转换，global 表示 Server-map 表不限制域间关系
 section 1 30.1.1.20 30.1.1.20
#
nat-policy interzone trust untrust outbound
policy 1
action source-nat
address-group 1
policy source 20.1.1.0 0.0.0.255 

从 PC1 上 ping PC2，在会话表中可以看到源 IP 和端口都做了 NAT 转换

再看Server-map表，可以看到类型是FullCone（全圆锥），即三元组NAT的Serverv-map表（关于FullCone的内容，请见下面的附录内容）。在Server-map表没有老化前，三元组的源Server-map表项（FullConeSrc）作用是：内网主机访问任意外网主机（ANY）时，NAT转换后的地址和端口都是30.1.1.20:3536。目的Server-map表项（FullConeDst）的作用是：任意外网主机（ANY）都可以通过30.1.1.20:3536来访问内网主机20.1.1.11。通过这两条Server-map表项即实现了“外网主机可以主动访问内网主机，并保证NAT转换关系在一段时间内保持不变”的要求。

由于实验室环境限制，此处无法通过P2P应用来验证三元组NAT的另一个特点：PC1没有访问过的主机可以通过30.1.1.20:3536主动访问PC1。实际上，如果有一台P2P客户端PC3，他是可以通过30.1.1.20:3536成功访问PC1的。通过另一种方法可以验证NAT转换的固定性：在Serverv-map表没有老化前，可以用一台主机telnet30.1.1.20:3536，当然PC1要先开启Telnet服务器功能，且端口要设置为3536

根据RFC3489中的内容，FullCone（全圆锥）是4种NAT端口映射方式中的一种，其他3种分别为：RestrictedCone（受限圆锥）、PortRestrictedCone（端口受限圆锥）和Symmetric（对称型）。

• 全圆锥NAT的模型是：内网主机做NAT转换后的地址和端口在一段时间内保持不变，不会因为目的地址不同而不同，所以内网主机可以使用相同的NAT后三元组（源IP、源端口、协议）访问不同外网主机。当NAT后三元组确定后，外网主机也都可以通过该三元组访问内网用户。（题外话：之所以叫“全圆锥”，应该就是根据“一对多”的模型命名的吧。）
• 对称型NAT的模型是：内网主机会根据不同的目的地址做NAT转换，NAT转换后的地址和端口一般是不相同的。由于对不同外网主机呈现不同的三元组（源IP、源端口、协议），所以外网主机只能通过访问对应的NAT后三元组才能进入内网，即需要限定目标用户和端口，因此对称型NAT也称为五元组NAT（源IP、源端口、目的IP、目的端口、协议）。

华为防火墙除了支持全圆锥NAT，也支持对称型NAT，NAPT功能即为五元组NAT。

NAT Server 基础

学校或公司的私网通常会有一些服务器需要提供给公网用户访问。但是网络部署时，服务器地址一般都会被配置成私网地址，这样服务器就不能直接使用自身的地址来提供服务了。防火墙是不是也可以将服务器的私网地址通过NAT转换成公网地址来提供服务呢？

不过，源NAT是对私网用户访问公网的报文的源地址进行转换，而服务器对公网提供服务时，是公网用户向私网发起访问，方向正好反过来了。于是，NAT转换的目标也由报文的源地址变成了目的地址。针对服务器的地址转换，我们赋予了它

一个形象的名字——NATServer（服务器映射）。

NATServer 的配置和实现

在防火墙上配置如下命令，就能将上图中服务器的私网地址10.1.1.2映射成公网地址1.1.1.1

[FW] nat server global 1.1.1.1 inside 10.1.1.2 

但是，如果一台服务器同时存在多种协议和端口的服务项，按照上述配置会将服务器上所有服务项都发布到公网，这无疑会带来很大的安全风险。华为防火墙支持配置指定协议的NATServer，只将服务器上特定的服务项对公网发布，从而避免服务项全发布带来的风险。例如，我们可以按如下方式配置，将服务器上80端口的服务项映射为9980端口供公网用户访问。

[FW] nat server protocol tcp global 1.1.1.1 9980 inside 10.1.1.2 80

这里将80端口转换为9980端口而不是直接转换成80端口是因为，一些地区的运营商会阻断新增的80、8000、8080端口的业务，从而导致服务器无法访问。NATserver

配置完成之后，也会生成Server-map表来保存映射关系。不过与ASPFServer-map表项的动态老化不同的是，NATServer的Server-map表项是静态的，只有当NATServer配置被删除时，对应的Server-map表项才会被删除。

图中红框标注的字段就记录着服务器私网地址端口和公网地址端口的映射关系。[]内为服务器私网地址和端口、[]外为服务器公网地址和端口。我们将表项翻译成文字就是：任意客户端（any）向（->）1.1.1.1:9980发起访问时，报文的目的地址和端口都会被转换成10.1.1.2:80。具体的流程如下：

当客户端通过1.1.1.1:9980访问服务器时，防火墙收到报文的首包后，首先是查找并匹配到Server-map表项，将报文的目的地址和端口转换为10.1.1.2:80。然后根据目的地址判断出报文在哪两个安全区域间流动，报文通过域间安全策略检查后，防火墙会建立如下的会话表，并将报文转发到私网。

之后，服务器对客户端的请求做出响应。响应报文到达防火墙后匹配到上面的会话表，防火墙将报文的源地址和端口转换为1.1.1.1:9980，而后发送至公网。后续客户端继续发送给服务器的报文，防火墙都会直接根据会话表对其进行地址和端口转换，而不会再去查找Server-map表项了。

在防火墙的前后抓包，能很清楚地看到NAT Server的效果：

• 转换客户端发往服务器的报文的目的地址和端口

• 转换服务器响应客户端的报文的源地址和端口

强叔的 NAT Server 三十二字箴言

一正一反，出入自如 去反存正，自断出路
一分为二，源进源回 虚实变换，合二为一

一正一反 出入自如

入->公网到私网

出->私网到公网

[FW] nat server protocol tcp global 1.1.1.1 9980 inside 10.1.1.2 80

Nat Server, any -> 1.1.1.1:9980[10.1.1.2:80]为正向 Server-map 表项，其作用为入。在公网 用户访问服务器时对报文的目的地址做转换。

Nat Server Reverse, 10.1.1.2[1.1.1.1] -> any 为反向 Server-map 表项，其作用为出。当私网 服务器主动访问公网时，可以直接使用这个表项将报文的源地址由私网地址转换为公网地址， 而不用再单独为服务器配置源NAT 策略

去反存正 自断出路

删除反向 Server-map 表项 配置 NAT-Server 时带上 no-reverse 参数就能让生成的 Server-map 表项只有正向没有反向

[FW]nat server protocol tcp global 1.1.1.1 9980 inside 10.1.1.2 80 no-reverse

没有反向 Server-map 相当于断了服务器去公网的路 接下来演示什么时候需要自断出路

总部有一台服务器需要提供给公网用户访问，在总部防火墙配置如下 NAT Server

[FW]nat server protocol tcp global 1.1.1.1 9980 inside 192.168.1.2 80

同时 总部和分支之间通过 IPSec VPN 实现互访 总部防火墙 IPSec 的部分配置如下

#
acl number 3000 //定义需要进行 IPSec 封装的数据流
rule 5 permit ip source 192.168.1.0 0.0.0.255 destination 10.0.0.0 0.0.0.255
#
ipsec policy map1 10 manual
security acl 3000 //引用 acl，只有符合 acl3000 的数据流才会被送入 IPSec 隧道封装
proposal tran1
…

因为总部 192.168.1.0/24 网段需要访问公网，所以海配置了如下的源 NAT 策略

#
nat-policy interzone trust untrust outbound
 policy 5
 action source-nat
 policy source 192.168.1.0 mask 24
 easy-ip GigabitEthernet0/0/1 

不过这条源 NAT 策略会将 trust 区域中 192.168.1.0/24 网段发往 untrust 区域的所有报文的源地址都转换成 GE0/0/1 接口地址 1.1.1.1 那么就会影响流量不会匹配到 IPSec 隧道，这样总部就别想通过 IPSec VPN 和分布之间通信了，所以除了上面这条策略 还需要对总部访问分布的流量不做源地址转换的 NAT 策略

#
nat-policy interzone trust untrust outbound
 policy 0
 action no-nat
 policy source 192.168.1.0 mask 24
 policy destination 10.0.0.0 mask 24 

上面两条源 NAT 策略，policy0 的匹配条件要比 policy5 更加严格，所以配置完成后需要确认 策略列表中 policy0 在 policy5 之上。否则报文匹配到条件宽松的 policy5 后就直接做了源地 址转换，而不会再匹配到 policy0 了。

配置完成后，分布的员工可以访问总部服务器的私网地址 192.168.1.2 总部 192.168.1.0/24 网段员工也能和分布的 10.0.0/24 网段通信。但总部服务器却无法访问分布 10.0.0.0/24 网段资源 删除 NAT Server 配置后就能正常访问

很明显 问题出在 NAT Server 上，但总部的服务器需要提供给公网用户访问，我们不能随意将 NAT Server 配置去掉，那该如何解决这个问题

总部 Server Ping 分部 PC 时，防火墙上可以看到这样一条会话

<FW> display firewall seession table source inside 192.168.1.2

icmp VPN:public -->public 192.168.1.2:512[1.1.1.1:512]-->10.0.0.2:2048

防火墙将报文的源地址从 192.168.1.2 转变成了 1.1.1.1 但刚才配置了一条对 192.168.1.0/24 网段发往 10.0.0.0/24 网段的报文不做源地址转换的 NAT 策略，为什么源地址还是被转换了？

我们先使用 display nat-pollcy all命令来查看和确认下源 NAT 策略命中情况

确实没有报文命中源 NAT 策略

接下来 让我们取消 NAT Server 的配置 再次从总部 Server ping 分部的 PC1 查看源 NAT 策略的命中情况，这时你会发现，有报文命中源 NAT 策略

幕后黑手正是 NAT Server 生成的反向 Server-map 表项

Nat Server Reverse 192.168.1.2[1.1.1.1]->any,Zone:---

防火墙的报文处理流程中，反向 Server-map 表是比源 NAT 策略优先匹配的，报文匹配到反向 Server-map 表后 就不会再匹配源 NAT 策略了，最终生成的绘画表依然有一个源地址转换的信息（反向 Server-map 表中的源地址转换信息）报文在进入 IPSec VPN 隧道封装之前，设备还是会根据会话表将报文的源地址转换为 1.1.1.1

在配置 NAT Server 时加上 no-reverse 参数 不生成反向 Server-map 表项就可以了

[FW] nat server protocol tcp global 1.1.1.1 9980 inside 192.168.1.2 80 no-reverse

no-reverse 参数不仅限于这个场景使用

一分为二 源进源回

防火墙作为出口网关，双出口、双 ISP 接入公网时，配置 NAT Server 通常需要一分为二， 让一个私网服务器向两个 ISP 发布两个不同的公网地址供访问

一分为二的方法有两种：

第一种是将接入不同 ISP 的公网接口规划在不同的安全区域中，配置 NAT Server 时 带上 zone 参数，使同一个服务器向不同安全区域发布不同的公网地址

[FW]nat server zone untrust1 protocol tcp global 1.1.1.1 9980 inside 10.1.1.2 80

[FW]nat server zone untrust2 protocol tcp global 2.2.2.2 9980 inside 10.1.1.2 80

第二种是将接入不同 ISP 的公网接口规划在同一个安全区域中，配置 NAT Server 时带上 no-reverse 参数 使同一个服务器向同一个安全区域发布两个不同的公网地址

[FW]nat server protocol tcp global 1.1.1.1 9980 inside 10.1.1.2 80 no-reverse

[FW]nat server protocol tcp global 2.2.2.2 9980 inside 10.1.1.2 80 no-reverse

no-reverse 参数是用来除去反 向 Server-map 表项自断出路的吗，这里怎么又用到了呢 我们来看下不带 no-reverse 参数直接配置上面两条命令会发生什么？ 答案是不带 no-reverse 参数这两条命令压根就不能同时下发。

尝试逆向思考，假如两条命令能同时下发，会发生什么

将两条命令分别放在两台防火墙上配置 然后查看各自生成的 Server-map 表项

一台防火墙上的反向 Server-map 表项是将报文的源地址 10.1.1.2 转换为 1.1.1.1 另一台防火墙上的反向 Server-map 表项是将报文的源地址由 10.1.1.2 转换为 2.2.2.2 如果这两个反向 Server-map 表项同时出现在一台防火墙上会发生什么

防火墙既可以将报文的源地址由 10.1.1.2 转换为 1.1.1.1 又可以转换为 2.2.2.2

这就是两条命令不带 no-reverse 参数同时下发带来的问题，如果配置时带上 no-reverse 参数 就不会生成反向 Server-map 表项，没有了反向 Server-map 表项 上述问题也就不存在了

一分为二还会存在报文来回路径不一致问题，例如 公网用户通过防火墙发布给 ISP1 的公网地址 1.1.1.1 访问服务器 服务器的响应报文到达防火墙后，防火墙根据目的地址查找路由表，可能会将响应报文由 ISP2 发送出去，这样就会导致访问速度过慢或无法访问

为了避免这个问题，还需要在防火墙上增加一些配置，保证报文的源进源回 即请求报文从某条路径进入，响应报文依然沿着同样路径返回

USG9000 系列防火墙源进源会功能是通过在公网接口下配置 redirect-reverse 命令来实现

例如上图接入 IPS1 的公网接口 GE1/0/1 的源进源回配置如下

[FW]interface GigabitEthernet 1/0/1

[FW-GigabitEthernet1/0/1]redirect-reverse next-hop 1.1.1.254

配置完成后，如果请求报文从 GE1/0/1 进入，则响应报文也强制从 GE1/0/1 发出，而不再是通过查找路由来确定接口

USG2000/5000/ 6000 系列防火墙源进源回功能配置思路与 USG9000 系列相同 配置命令为

reverse-route next-hop next-hop-address

虚实变换 合二为一

双机热备

在双机热备组网中，两台防火墙并不是直接使用 GE0/0/1 接口的实 IP 地址与公网通信,而是将 GE0/0/1 接口假如一个 VRRP 备份组，使用 VRRP 备份组的虚拟 IP 地址与公网通信，配置虚拟 IP 地址同时,防火墙会为其生成一个虚 MAC 地址

虚实对 NAT Server 的影响

当 NAT Server 公网地址与公网接口的地址在同一个网段时，防火墙会发送 NAT Server 公网地址的免费 ARP 请求报文 使用如下组网进行演示

NAT Server 的配置：

[FW]nat server protocol tcp galobal 1.1.1.1 9980 inside 10.1.1.2 80

在图示处抓包，可以看到防火墙发送的 NAT Server 公网地址的免费 ARP 请求报文，报文中携带的 1.1.1.1 的 MAC 地址为 0000-00e0-bb01，正是公网接口 GE0/0/1 的 MAC 地址

在 eNSP 上模拟双机热备 并在 FW1（主设备）上配置 NAT Server

[FW]nat server protocol tvp global 1.1.1.1 9980 inside 10.1.1..2 80

命令下发 设备就打印如下的 IP 地址冲突日志

2014-05-11 10:02:22 FW1 %%01ARP/4/DUP_IPADDR(l): Receive an ARP packet with duplicate
ip address 1.1.1.1 from GigabitEthernet0/0/1, source MAC is 0000-003a-f701! 

日志中显示冲突源的 MAC 地址为 0000-003a-f701，这个正是 FW2 的 GE0/0/1 接口的 MAC

:::tips
FW1 上配置了 NAT Server 后，由于公网 地址为 1.1.1.1 和 GE0/0/1 接口的地址（1.1.1.2/24)在同一个网段，FW1 会发送 1.1.1.1 的免费 ARP 请求报文，报文中携带的 1.1.1.1 的 MAC 地址为 GE0/0/1 接口的 MAC 0000-0006-1901 同时，因为 FW1 和 FW2 处于双机热备状态，FW1 上 NAT Server 的配置会同步到 FW2 上，而 FW2 GE0/0/1 接口的地址（1.1.1.3/24）和 NAT Server 公网地址也在同一个网段，这样 FW2 也会发送 1.1.1.1 的免费 ARP 请求报文，报文中携带的 1.1.1.1 的 MAC 地址为 GE0/0/1 接口的 MAC 0000-003a-f701 于是 同一广播域中两个 MAC 地址对应这同一个 IP 地址 1.1.1.1 产生了 IP 地址冲突

同时,由于 FW1 和 FW2 同时发送免费 ARP 请求报文，上行设备学习到的 1.1.1.1 的 MAC 也会在 0000-0006-1901 和 0000-003a-f701 之间不停切换，如下图就是 Client 上查看的 ARP 表项

:::

这样 从 Client 上访问 1.1.1.1 时，Client 的网卡会时而用 0006 （MAC 地址，这里简略到中间部分）来封装报文，则报文会被发往 FW1（主设备）业务访问正常，如果用 003a 来封装报文，则报文会被发往 FW2（备设备 ）由于 FW2 作为备设备时上不处理业务的，报文到达 FW2 后就会被丢弃，于是就会出现业务时通时不通的情况

在配置命令中加上 vrrp 关键字就能解决这个问题 按如下命令重新配置：

[FW1]nat server protocol tcp global 1.1.1.1 9980 inside 10.1.1.2 80 vrrp 1

设备上不再打印 IP 地址冲突日志了,在防火墙和上行交换机之间抓包我们会发现,只有主用防火墙会发送免费 ARP 报文，且报文中携带的 1.1.1.1 的 MAC 地址变成了 0000-5e00-0101 VRRP 备份组 1 的虚 MAC 地址 Client 访问 1.1.1.1 时，网卡会使用 0000-5e00-0101 来封装报文，这样就能保证报文永远都是向主用设备转发了，是为虚实变换之间，合二为一

双向 NAT

如果需要同时改变报文的源地址和目的地址，就可以配置”源 NAT|NAT server“。华为防火墙称此类配置为双向 NAT，这里要注意，双向 NAT 不是一个单独的功能，他仅仅是源 NAT 和 NAT Server 的组合，组合的含义是针对同一条流（例如外网主机访问内网服务器的流量 ）在其经过防火墙时同时转换报文的源地址和目的地址，

:::tips
如果理解成

”防火墙同时配置了源 NAT 和 NAT Server 就是双向 NAT“

是错误的

:::

因为源 NAT 和 NAT Server 可能是为不同流配置的

之前介绍源 NAT 功能时，都是按照内网用户访问外网资源的思路进行组网设计和验证二代，实际上，源 NAT 还可以根据报文的源地址和目的地址所在的安全区域进行分类

域间 NAT

报文的源地址和目的地址属于不同的安全区域，按照转换报文的方向 又可以分为以下两类：

Nat Inbound（外网访问内网）：

报文由低安全级别的安全区域向高安全区域方向传输时，基于源地址进行的转换，一般来说 NAT inbound 都会和 NAT Server 配合使用

NAT Outbound（内网访问外网）

报文由高安全级别的安全其余向低安全级别的安全区域方向传输时，基于源地址进行的转换，之前介绍的“内网用户访问外网资源”场景大多使用 NAT Outbound

域内 NAT

报文的源地址和目的地址属于相同的安全区域，一般来说，域内 NAT 都会和 NAT Server 配合使用，单独配置域内 NAT 情况少见

当域间 NAT 或域内 NAT 和 NAT Server 一起配合使用时，就实现了双向 NAT，当然，上述内容的一个大前提就是 ：合理设置安全区域的级别并规划网络 内网设备属于 Trust 域（高级别）内网服务器属于 DMZ 域（中级别）外网设备属于 Untrust（低级别）

双向 NAT 从技术和实现原理上讲无特别之处，但是他和应用场景有着强相关性，究竟什么时候需要配置双向 NAT

NAT Inbound+NAT Server

下为常见场景：

外网 PC 访问内网服务器，防火墙做服务器网关，这时一般会用 NAT Server，但现在要讲如何在这个场景中应用双向 NAT 以及为什么这么做

Server 以公网 IP 对外提供服务,防火墙上配置 NAT Server，同时防火墙上配置 NAT Inbound 令 PC 以私网 IP 访问 Server

配置 NAT Inbound+NAT Server

#
nat address-group 1 10.1.1.20 10.1.1.25 //地址池中的 IP 为私网 IP ，且和 server 的私网 IP 同网段
nat server 0 global 210.1.1.15 inside 10.1.1.3
#
nat-policy interzone dmz untrust inbound
policy 1
 action source-nat
 policy destination 10.1.1.3 0 //由于防火墙先做 NAT Server 转换，再做源 NAT 转换，所以此处的目的IP 是 NAT Server 转换后的 IP
 address-group

这里 NAT Server 的配置和以前见过的类似，但是源 NAT 配置和以前见过的不一样，以前地址池中配置的都是公网地址这次配置的是私网地址

通过下图看报文地址转换过程

PC 访问 Server 的流量经过防火墙时，目的地址（server 的公网地址）通过 NAT Server 转换为私网地址，源地址（PC 的公网地址）通过 NAT Inbound 也转换为私网地址，且和 Server 的私网地址同网段，这样就同时转换了报文的源地址和目的地址，完成双向转换

从 PC 上 ping server 通过防火墙上的会话表和 Server-map 表可以更清楚的看到双向 NAT 转换：PC 的地址通过 NAT Inbound 转换为私网地址，而 Server 的地址也按照 NAT Server 的 Server-map 表转换为私网地址

那么为什么要配置 NAT Inbound 呢，如果不配置 NAT Ibound 行不行？

不配置 NAT Inbound 并不影响 PC 访问 Server，那配置 NAT Inbound 有什么好处？好处就是 Server 上可以不用设置网关，当然 前提条件是地址池需要和 Server 的私网地址同网段，当 Server 回应 PC 时，Server 发现自己的地址和目的地址在同一网段，这时 server 就不会去查录音，而是发送 ARP 广播报文询问目的地址对应的 MAC 地址，由于目的地址是地址池中的地址，所以他没有对应的 MAC 地址，但是防火墙此时将自己与 Server 直连接口的 MAC 地址发给 Server，告诉 Server 把回应报文给我吧，所以回应报文将转发到防火墙上，由于 Server 回应报文是通过二层转发，而不是三层转发，所以 server 上不用配置网关

少量机器可能感觉不太 出来，数量多了如果配置网关就需要大量更改，此时就会发现 NAT Inbound 的方便了

如果对之前的组网做改变，增加一个 trust 区域，该域内的 PC2 要访问 Server 时，我们该如何配置双向 NAT 呢？和之前比，报文的源地址所在安全域发生了变化，原来是 Untrust 域到 DMZ 域的报文（Inbound 方向），现在变成了 Trust 域到 DMZ 域的报文（Outbound 方向）所以双向 NAT 也变化为 NAT Outbound+NAT Server，它的转换原理和 NAT Inbound+NAT Server 完全一样，只不过源 NAT 的转换方向发生了改变

域内 NAT+NAT Server

域内 NAT 的场景多见小型网络，如下图点 PC 和 Server 通过交换机与防火墙相连，管理员在规划网络时”偷懒“，将 PC 和 Server 置于同一安全区域，并分配相同网段地址

此时 如果希望 PC 像外网用户一样通过公网地址访问 Server，就要在防火墙上配置 NAT Server，如果只配置了 NAT Server 报文到达防火墙后转换目的地址，Server 回应报文时发现自己都地址和目的地址在同一网段，这就和之前分析的组网是同样情况了，Server 通过二层转发报文，回应报文经交换机直接转发到 PC，不会经过防火墙转发

如果希望提高内网的安全性，让回应报文也经过防火墙，就需要配置域内 NAT，下面列出了关键的配置步骤，地址池中的地址可以上公网地址，也可以是私网地址，关键是不能和 Server 的私网地址也在同一网段，域内 NAT 的配置和遇见 NAT 几乎完全一样，只不过牵着应用在域内做 NAT 转换，后者应用在域间做 NAT 转换

配置域内 NAT+NAT Server

#
nat address-group 1 210.1.1.20 210.1.1.20
nat server 0 global 210.1.1.15 inside 10.1.1.3
#
nat-policy zone trust //注意是域内 NAT
policy 1
 action source-nat
 policy destination 10.1.1.3 0 //此处的目的 IP 是 NAT Server 转换后的IP
 address-group 1 

从 PC 上 ping Server 通过防火墙上的会话表和 Server-map 表可以看到 PC 的地址通过域内 NAT 转换为公网地址，Server 的地址按照 NAT Server 的 Server-map 表转换为私网地址，双向 NAT 转换后，Server 回复报文时发现自己的地址和目的地址不在同一网段，此时就需要查路由，通过三层转发报文，所以回应报文需要防火墙转发

如果在上面组网的基础上做变化，将 PC 和 Server 分开，通过不同的接口和防火墙相连，此时应该如何配置双向 NAT 呢？ 在这个组网中所有报文都需要经过防火墙转发，只配置 NAT Server 是可以的，如果要配置双向 NAT 那么就是域内 NAT+NAT Server 具体配置方法和上面类似

双向 NAT 原理并不复杂，关键是 NAT 转换的方向和转换后地址的作用，而不要纠结于转换后是公网地址还是私网地址，双向 NAT 并不是必配的功能，但是灵活应用双向 NAT 可以起到简化网络配置，方便网络管理点作用

防火墙如何建立会话

如今的数据通信网络已经是全 IP 时代，防火墙处理的也都是 IP 报文。根据 TCP/IP 协族模型，在IP 协议中，我们常用的协议有 TCP、UDP 和 ICMP 协议。那么下面我们就别来看一下，对于 TCP、UDP 以及 ICMP 协议的报文，防火墙是如何建立会话的

TCP

建立一个 TCP 连接,通信双方需要三次握手

判断一个 TCP 连接点主要标志就是 SYN 报文，我们也罢 SYN 报文称为 TCP 连接的首包,对于 TCP 协议，防火墙只有收到 SYN 报文 并且 SYN 报文通过了包括安全策略在内的各项安全机制检查后，才会建立会话，后续的 TCP 报文匹配会话直接转发，如果防火墙没有收到 SYN 报文，只收到 SYN+ACK 或 ACK 等后续报文，是不会创建会话点，并且会将这些报文丢弃。

下面在 eNSP 上在防火墙上模拟一个典型点 TCP 协议的会话：HTTP 会话，网络拓扑如 下：

PC 访问 Web 服务器，然后在防火墙上使用 display firewall session tablle verbose 命令可以看到会话正常建立，这里使用了 verbose 参数，可以看到会话更多信息

会话中“<–”和“–>”这两个方向上的报文统计信息非常重要， 可以帮助我们定位网络故障。通常情况下，我们查看会话时发现只有“–>”方向有报文的统 计信息，“<–”方向上的统计信息都是 0，那就说明 PC 发往 Web 服务器的报文顺利通过了 防火墙，而 Web 服务器回应给 PC 的报文没有通过防火墙，双方的通信是不正常的。有可能 是防火墙丢弃了 Web 服务器回应给 PC 的报文、或者是防火墙与 Web 服务器之间的网络出 现故障、或者是 Web 服务器本身出现故障。这样我们就缩小了故障的范围，有利于快速定位 故障。当然，凡事都有例外，在特殊的网络环境中，如果其中一个方向的报文统计信息是 0， 双方的通信也有可能是正常的，这种特殊的网络环境是什么呢？

如果防火墙没有收到 SYN 报文，只收到 SYN+ACK 或 ACK 等后续报文，是不会创建会话的，并且会将这些报文丢弃，在正常情况下这样处理是没有问题的，但是在报文来回路径不一致的环境中就会出现问题

如上图 内部网络访问外部网络的报文直接通过路由器到达外部网络，而外部网络的回应报文，先经过路由器转发到防火墙，由防火墙处理后再转发到路由器，最后由路由器发送到内部网络，也就是防火墙无法收到 SYN 报文，只收到了 SYN+ACK 报文，这种通信双方交互的报文不同时经过防火墙的情况，叫做报文来回路径不一致，在这种网络环境中，防火墙收到 SYN+ACK 报文后，由于没有响应会话，就会丢弃 SYN+ACK 报文，导致内部网络和外部网络之间的通信中断。 此时可以关闭防火墙的状态检测功能，关闭状态检测后 对于 TCP 协议除了 SYN 报文外，SYN+ACK、ACK 报文就都可以建立会话了，这样就不会导致通信中断

下面使用 eNSP 来模拟一个报文来回路径不一致的网络环境，我们让 PC 访问 Web 服务器的报文通过路由器直接到达 Web 服务器，让 Web 服务器回应给 PC 的报文将会转发到防火墙，然后再发送到 PC。

拓扑如下：

先不关闭状态检测，让 PC 访问 Web 服务器，发现无法成功访问，在防火墙上也无法看到会话信息。

此时在防火墙上使用 display firewall statistic system discard 命令查看丢包情况，发现存在 Session miss 丢包

这表示防火墙因为无法找到会话将报文丢弃，因为防火墙只收到了服务器回应的 SYN+ACK 报文，没有收到 SYN 报文，也就没有相应的会话，所以 SYN+ACK 报文被丢弃。

接下来使用 undo firewall session link-state check 命令关闭状态检测功能，然后再让 PC 访问 Web 服务器，发现可能访问成功，在防火墙上也可以查看到会话信息：

在会话信息中 <–方向统计信息是 0，只有–>方向存在统计信息，这就说明只有服务器回应的 SYN+ACK 报文经过了防火墙，由此我们得出结论，关闭状态检测功能后，防火墙收到 SYN+ACK 报文后也会建立会话，PC 和 Web 服务器之间的通信不会中断

UDP

UDP 不同与于 TCP 协议 , 是没有连接状态的协议,对于 UDP 协议，防火墙收到 UDP 报文后，无论状态检测功能是开启还是关闭状态，只要 UDP 报文通过了包括安全策略在内的各项安全机制的检查，防火墙都会建立会话

ICMP

然后是 ICMP 协议，提到 ICMP 协议 就会想到 ping，ping 用来测试网络中另一台设备是否可达，是我们在日常维护中经常会用到的操作，执行 ping 操作的一方会发送 ping 回显请求报文（Echo request），收到该请求报文后，响应一方会发送 Ping 回显应答报文（Echo reply）

对于 ping 报文 在开启状态检测功能时 防火墙只有收到 ping 回显请求报文，并且 Ping 回显请求报文通过了包括安全策略在内的各项安全机制的检查后，才会建立会话；如果防火墙没有收到 ping 回显请求报文，只收到了 ping 回显应答报文，是不会创建会话的，并且会将 ping 回显应答报文丢弃，在关闭状态检测功能时，防火墙收到 ping 回显请求报文和 ping 回显应答报文，都会创建会话，下面是在报文来回路径不一致的网络环境中，防火墙上关闭了状态检测功能后，Ping 回显应答报文生成的会话信息：

而对于其他类型的 ICMP 报文，无论状态检测功能是开启还是关闭，只要这些报文通过了包括安全策略在内的各项安全机制的检查，防火墙都会转发报文，不建立会话。

最后 总结如下表

另外还有一些特殊的报文，防火墙转发这些报文时不会创建会话，这些特殊的报文包括：

当安全策略遇上 OSPF

本篇验证的是防火墙本身参与到 OSPF 路由计算的场景，即验证防火墙接口所在安全区域与 Local 区域之间试过需要开启安全策略，而防火墙本身不参与 OSPF 路由计算，只是二层转发 OSPF 路由报文的场景中，如果防火墙的接口属于不同的安全区域，则需要开启安全区域之间的安全策略，允许 OSPF 路由报文通过。

使用一台 USG9000 防火墙和两台路由器搭建一个简单的网络环境，网络拓扑如下图：

根据下表中的数据，在 USG9000 上配置接口的 IP 地址,将接口加入安全区域,开启 OSPF 功能，以及在路由器 R1 和 R2 上配置接口的 IP 地址,开启 OSPF 功能

默认情况下，防火墙上没有开启 GE1/1/9 接口所在的 Untrust 区域和 local 区域之间的安全策略，这两个区域之间不允许报文通过，我们在防火墙上使用 display ospf peer 命令查看 OSPF 的邻接关系

在路由器 R1 上使用 display ospf peer 命令查看 OSPF 的邻接关系：

在 USG9000 和 R1 上看到的 OSPF 邻接状态都为 ExStart，根据下面的 OSPF 邻接关系建立过程示意图，发现 OSPF 邻接关系没建立起来，因为 USG9000 和 R1 之间没有成功交换 DD （Database Description） 报文

此时，怀疑可能是 USG9000 丢弃 DD 报文，在 USG9000 上使用 display firewall statistic system discarded 命令查看丢包信息

上面的信息表示缺省包过滤将报文丢弃，而且被丢弃报文的个数还在不断增长，说明 OSPF 模块在不断尝试发送 DD 报文，但都被安全策略模块丢弃了。

接下来在 USG9000 上开启 Local 区域和 Untrust 区域之间的安全策略，允许 OSPF 报文通过，注意，因为 USG9000 既要发送 DD 报文又要接收 DD 报文，所以 Inbound 和 Outbound 方向上的安全策略都要开启。如下：

为了精确匹配 OSPF 协议，使用了系统提供的 OSPF 服务集，如果防火墙中没有提供这个服务集，可以自己创建一个，协议号设置为 89

然后分别在 USG9000 和 R1 上使用 display ospf peer 命令查看 OSPF 的邻接关系（可能要等待一会）或者可以使用 reset ospf process 重启 OSPF 进程

此时可以看到 OSPF 邻接建立成功，同时 USG9000 上已经存在了通过 OSPF 路由协议学习到的去往 50.1.1.0 这个网段的路由：

对于防火墙 USG9000 来说，需要开启接口所在安全区域和 local 区域之间的安全策略，允许 OSPF 报文通过，这样防火墙才能和相连的设备正常建立邻接关系，实际上，我们可以从另外一个角度来考虑这个问题。单播报文和组播报文。

对于防火墙来说，一般情况下，单播报文是要经过安全策略的检查，所以需要开启安全策略允许报文通过；而组播报文不经过安全策略的检查，也就不需要开启相应的安全策略。

在 OSPF 中哪些报文是单播，哪些是组播？

可以在接口上执行 ospf network-type 命令来修改 OSPF 的网络类型

从表中可以看出，网络类型上 Broadcast 类型时，OSPF 报文中的 DD 报文和 LSR 报文是单播报文，需要开启安全策略；网络类型是 P2P 时，OSPF 报文是组播报文，因此无需开启安全策略。NBMA 和 P2MP 类型也是同理。

上述结论基于华为防火墙 USG9000 V3R1 版本，不适用于其他型号防火墙产品。

揭秘华为防火墙 NAT 地址复用专利技术

提到多对多，多对一到 NAT 就不能回避公网地址利用率的问题

华为防火墙一个公网 IP 突破了 65535 端口限制,理论上能无限制进行 NAT 转换

在源 NAT 节中，提到：防火墙在应用源 NAT 功能时就是从地址池中挑选一个公网 IP,然后对私网 IP 进行转换,挑选哪个公网 IP 是随机的,和配置时的顺序,IP 大小等因素都没关系,那么在进行源 NAT 时，是怎么样从地址池中挑选公网 IP 地址资源进行分配呢？

这要引入 Hash 算法概念

就是把一种任意长度的信息进行压缩映射，成为某一固定长度的信息，例如把 3000 个私网 IP 映射成 100 个公网 IP,也就是从地址池挑选出公网 IP 地址资源进行分配的过程,资料中也偶尔会提到的基于源地址 Hash。

Hash 的具体规则或者算法是什么呢？这个灵活可以自己设定，但现在我们使用取模运算

思路如下：

内网用户的源 IP 地址已经可以全部被分配了对应的地址池中的公网 IP 地址资源,并且保证额每个内网的 IP 地址在转换时每次访问外部网络时始终转换为同一个公网 IP 地址,按照上述运算后,一部分内网用户就会被分配相同的公网 IP 地址资源，下一步，我们来研究如何分配端口资源

下面端口分配先从防火墙的实现原理讲起，定性区分端口分配带来的影响

在源 NAT 一节中，我们已介绍了 NAPT 情况建立的会话表

例如 内网 10.1.1.1 和 10.1.1.2 用户分别 ping 220.180.20.50 服务器，在 USG 上通过公网地址 202.169.1.1 进行 NAT 转换，查询会话表显示如下：

[USG9000] display firewall session table
Current total sessions: 2
Slot: 5 CPU: 1
icmp VPN: public --> public 10.1.1.1:1280[202.169.1.1:10298] --> 220.180.20.50:2048
icmp VPN: public --> public 10.1.1.2:1280[202.169.1.1:6103] --> 220.180.20.50:2048 

由于内网不同用户的 IP 地址和端口必不相同,仅使用"源地址+源端口"二元租信息在 USG 上即可标识一条数据流,来建立正向 NAT 地址转换。而进行反向地址还原时，使用”源地址+源端口+目的地址+目的端口+协议“五元祖信息唯一标识一条数据流

那么根据会话表实现机制，只要内网不同用户访问”目的地址+目的端口+协议“三元祖中任一参数不同时，即使将地址中同一公网地址的同一端口同时分配给内网多个用户时，也不会产生冲突

示例如下：

只要内网不同用户访问”目的地址+目的端口+协议"三元组中的任一参数不同时，唯一的 NAT 地址和端口可以反复利用，不受 65535 端口的限制，此时无论端口如何分配，都不会产生问题。

那么在地址池只有一个公网 IP 情况下,如果访问相同点"目的地址+目的短裤+协议"三元组时怎么办?

在内网不同用户访问相同"目的地址+目的端口+协议"三元组时,不能被分配给相同点 NAT 地址和端口资源，这是因为一旦完全相同，访问的目的主机会发现出现同样的“源地址+源端口”访问本主机的同一“目的地址+端口+协议”，目的主机无法正确回应甚至可能会判定为受到攻击。

因此 保证内网不同用户、访问相同的“目的地址+目的端口+协议”三元组时，不能被分配到相同地址都相同端口资源是关键，这就要引入冲突检测机制。

其实在分配端口的法则上，仍然使用 Hash 算法，在内存占用合理的情况下 尽可能保证被分配到相同公网地址的用户，其被分配的端口尽量不一致，简化思路如下：

这就保证了 不同内网用户访问相同的“目的地址+目的 端口+协议”三元组时，不会被分配到相同的 NAT 地址的端口资源，而且会话表是会实时老化的，被分配过的端口会在会话表老化后重新利用，因此概率上端口也不会受到限制

除非最极端情况发生：超过 64k 的内网用户，同一时刻、向外网同一目的主机的同一端口、采用同样协议发起链接。

配置 NAT 时为什么要同时配置黑洞路由

首先用 eNSP 模拟一个典型的源 NAT 环境：

NAT 地址池地址是 202.1.1.10，防火墙与路由器互联接口地址的掩码是 30 位，与 NAT 地址池地址不在同一网段，防火墙上配置了一条缺省录音，下一挑上 202.1.1.2 这样就能把私网 PC 访问公网 Server 的报文送到路由器，为了保证公网 Server 的回程报文能够顺利到达防火墙，路由器上还要配置一条到 NAT 地址池地址的录音，另外防火墙上 NAT 策略和安全策略也都配置完成。

正常情况下，私网 PC 访问公网上的服务器 Server 生成会话表，源地址也进行了转换

此时 如果公网上的一台 PC，主动访问防火墙上的 NAT 地址池地址，会发生什么呢？

在公网 PC 上执行 ping 202.1.1.10 发现不能 ping 通

显然这是正常结果，因为 NAT 地址池只有在转换私网地址的时候才会用到，也就是说，私网 PC 必须先发起访问请求，防火墙收到该请求后才会为其转换地址，NAT 地址池地址并不对外提供任何单独的服务，所以当公网 PC 主动访问 NAT 地址池地址时，报文到达防火墙后，无法匹配会话表，防火墙肯定就会把报文丢弃了

实际情况得在防火墙点 GE0/0/1 接口抓包，然后再次在公网 PC 上执行 ping 202.1.1.10 命令，这次使用-c 参数，只发送一个 ping 报文

GE0/0/1 抓包信息如下

经过分析发现，报文的 TTL 值逐一递减，直到变为 1，TTL 是报文的生存时间，每经过一台设备的转发，TTL 的值减 1，当为 0 时，就会被设备丢弃。

这说明公网 PC 主动访问 NAT 地址池地址的报文在防火墙和路由器之间相互转发，直到 TTL 变成 0 后，被最后收到该报文的那台设备丢弃

过程梳理：

·1·路由器收到公网 PC 访问 NAT 地址池地址的报文后，发现目的地址不是自己的直连网段，因此查找录音，发送到防火墙。

·2·防火墙收到报文后，该报文不属于私网访问公网到回程报文，无法匹配到会话表，同时目的地址也不是自己的直连网段（防火墙没有意识到该报文的目的地址是自己的 NAT 地址池地址）只能根据缺省路由来转发，因为报文从同一接口入和出，相当于在同一个安全区域流动，缺省情况下也不受安全策略控制，就这样报文又从 GE0/0/1 接口送出去

·3·路由器收到报文后，查找录音，还是发送防火墙，如此反复

下面看配置黑洞路由的情况，首先在防火墙上配置一条目的地址是 NAT 地址池地址的黑洞路由，为了避免这条路由影响其他业务，将掩码成 32 位，精确匹配 202.1.1.10 这个地址：

[FW]ip route-static 202.1.10 32 NULL 0

然后在防火墙 GE0/0/1 接口上开启抓包，在公网 PC 上执行 ping 202.1.1.10 -c 1 命令，还是只发送一个 ping 报文，查看抓包信息

只抓到一个 ICMP 报文，说明防火墙收到路由器发送过来的报文后，匹配到了黑洞路由，直接将报文丢弃了，此时就不会在防火墙和路由器之间产生路由环路，即使防火墙收到再多的同类报文，都会送到黑洞中。并且这条黑洞路由不会影响正常业务，私网 PC 还是可以正常访问公网 Server

当防火墙上 NAT 地址池地址和公网接口地址不在同一网段时，必须配置黑洞路由，避免在防火墙和路由器之间产生路由环路

那么如果 NAT 地址池地址和公网接口地址在同一网段时，还会有这个问题吗？

将防火墙和路由器互联的两个接口的掩码修改为 24 位，这样接口地址和 NAT 地址池地址就在同一网段了，然后去掉黑洞路由的配置，在防火墙 GE0/0/1 接口抓包，在公网 PC 执行 ping 202.1.1.10 -c 1 命令 查看抓包信息

只抓到了三个 ARP 报文和一个 ICMP 报文，公网 PC 访问 NAT 地址池地址的报文没有在防火墙和路由之间相互转发

梳理过程：

·1·路由器收到公网 PC 访问 NAT 地址池地址的报文后，发现目的地址属于自己的直连网段，发送 ARP 请求，防火墙会回应这个 ARP 请求，前两个 ARP 报文就是来完成了这一交互过程的，然后路由器使用防火墙告知 1MAC 地址封装报文，发送至防火墙

·2·防火墙收到报文后，发现报文的目的地址和自己的 GE0/0/1 接口在同一网段，直接发送 ARP 请求报文（第三个 ARP 报文）寻找该地址的 MAC 地址（防火墙依然没有意识到该报文的目的地址是自己的 NAT 地址池地址）但是网络中其他设备都没有配置这个地址，肯定就不会回应，最终防火墙将报文丢弃

在这种情况下不会产生路由环路，但是如果公网上的不法分子发起大量访问时，防火墙将发送大量 ARP 请求报文，消耗系统资源，所以当防火墙上 NAT 地址池地址和公网接口地址在同一网段时，建议也配置黑洞路由，避免防火墙发送 ARP 请求报文，节省防火墙系统资源

下面是配置黑洞路由后的抓包信息，可以看到，防火墙没有再发送 ARP 请求报文

另一种极端情况，在配置源 NAT 时，可以直接把公网接口地址作为转换后地址（easy-ip 方式）也可以把公网接口地址配置成地址池地址，这样 NAT 转换使用的地址和公网接口地址就是同一个地址，这种情况下，需要配置黑洞路由吗？

防火墙收到公网 PC 的报文后，发现是访问自身的报文，这就取决于公网接口所属安全区域和 local 安全区域之间的安全策略，安全策略允许通过就处理，安全策略不允许通过就丢弃，不会产生路由环路，也不需要配置黑洞路由

NAT Server 也存在路由环路问题，不过前提条件较为特殊，下面是一个典型的 NAT Server 组网环境

如果我们在防火墙上配置了一条粗犷型的 NAT Server，将私网 Server 全部发布到公网，如

[FW]nat server global 202.1.1.20 inside 192.168.0.20

公网 PC 访问 202.1.1.20 的报文，目的地址都会被转换成 192.168.0.20，然后发送给私网 Server，这个时候自然不会产生路由环路

如果配置一条精细化 NAT Server 只把特定端口发布到公网，如：

[FW]nat server protocol tcp 202.1.1.20 80 inside 192.168.0.20 80

此时如果公网 PC 不按常理出牌，没有访问 202.1.1.20 的 80 端口，而是使用 ping 命令访问 202.1.1.20，防火墙收到该报文后，既无法匹配 Server-map 表，也无法匹配会话表，就只能查找路由转发，从 GE0/0/1 接口送出去，而路由器收到报文后，还是要送到防火墙，这样依然会产生路由环路

当防火墙上配置了特定协议和端口的 NAT Server 并且 NAT Server 的 Global 地址和公网接口地址不在同一网段时，必须配置黑洞路由，避免在防火墙和路由器之间产生路由环路

如果 NAT Server 的 Global 地址和公网接口地址在同一网段，防火墙收到公网 PC 的 ping 报文后，会发送 ARP 请求报文，这个过程就和前面讲过的 NAT 情况是一样的，当防火墙上配置了特定协议和端口的 NAT Server 并且 NAT Server 的 Global 地址和公网接口地址在同一网段时，建议也配置黑洞路由，避免防火墙发送 ARP 请求报文，节省防火墙的系统资源

同样，我们配置 NAT Server 时，也可以把公网接口地址配置成 Global 地址，此时防火墙收到公网 PC 的报文后，如果能匹配上 Server-map 表，就转换目的地址，转发到私网，如果不能匹配上 Server-map 表，就会认为是访问自身的报文，由公网接口所属安全区域和 local 安全区域之间的安全策略决定如何处理，不会产生路由环路，也不需要配置黑洞路由。

总结

对于源 NAT

·如果 NAT 地址池地址与公网接口地址不在同一网段，必须配置黑洞路由

·如果 NAT 地址池地址与公网接口地址在同一网段，建议也配置黑洞路由

对于配置特定协议和端口的 NAT Server

·如果 NAT Server 的 Global 地址与公网接口地址不在同一网段，必须配置黑洞路由

·如果 NAT Server 的 Global 地址与公网接口地址在同一网段，建议也配置黑洞路由

:::tips
除了防止路由环路、节省设备的系统资源，其实黑洞路由还有一个作用，那就是在防火墙上 引入到 OSPF 中，发布给路由器。 我们知道，当 NAT 地址池地址或 NAT Server 的 Global 地址与防火墙和路由器互联接口的地 址不在同一网段时，需要在路由器上配置到 NAT 地址池地址或 NAT Server 的 Global 地址的 静态路由，保证路由器可以把去往 NAT 地址池地址或 NAT Server 的 Global 地址的报文发送 到防火墙。 如果防火墙和路由器之间运行 OSPF 协议，那么就可以通过 OSPF 协议来学习路由，减少手 动配置的工作量。但是 NAT 地址池地址和 NAT Server 的 Global 地址不同于接口地址，无法 在 OSPF 中通过 network 的方式发布出去，那么路由器如何才能学习到路由呢？ 此时就可以通过在防火墙的 OSPF 中引入静态路由的方式，把黑洞路由引入到 OSPF 中，然 后通过 OSPF 发布给路由器。这样，路由器就知道了去往 NAT 地址池地址或 NAT Server 的 Global 地址的报文都要发送到防火墙上（注意，是发送到防火墙，而不是发送到黑洞中）。 以 NAT Server 的组网为例，NAT Server 的 Global 地址和公网接口地址不在同一网段，防火 墙和路由器都运行 OSPF 协议，在防火墙上的 OSPF 中引入静态路由：

:::

#
ospf 100
import-route static
area 0.0.0.0
 network 202.1.1.0 0.0.0.3
#

:::tips
这时路由器就可以学习到去往 NAT Server 的 Global 地址的路由：

:::

VPN 技术简介

VPN 指在公网上建立一个私有、专用、虚拟通信网络，在企业网络中 VPN 广泛应用于分支机构和出差员工连接公司总部网络，VPN 网络和 VON 技术通常是如何分类呢？

根据建设单位不同分类

这种分类根据 VPN 网络端点设备（关键设备）由运营商提供，还是由企业自己提供来划分

租用运营商 VPN 专线搭建企业 VPN 网络：

目前主要指租用运营商 MPLS VPN 专线比如联通、电信都提供 MPLS VPN 专线服务。跟传统的租用传输专线（如租用 E1、SDH 专线）相比，MPLS VPN 专线的优势主要在于线路租用成本低

用户自建企业 VPN 网络：

目前最常用的就是基于 Internet 建立企业 VPN 网络，具体技术包括 GRE、L2TP、IPSec、SSL VPN 等。这种方案企业只需要支付设备购买费用和上网费用，没有 VPN 专线租用费用；另外企业在网络控制方面有更多主动权，更方便企业进行网络调整

根据组网方式不同分类

远程访问 VPN：

适合出差员工 VPN 拨号接入的场景，员工可以在任何能够接入公网的地方，通过远程拨号接入企业内网，从而访问内网资源。

局域网到局域网的 VPN：

它适用于公司两个异地机构的局域网互连

根据应用场景不同分类

远程访问 VPN：

Access VPN 面向出差员工，允许出差员工跨越公用网络远程接入公司内部网络

Intranet VPN（企业内部虚拟专网）：

Intranet VPN 通过公用网络进行企业内部各个网络的互连

Extranet VPN（扩展的企业内部虚拟专网）：

Extranet VPN 是指利用 VPN 将企业网延申

至合作伙伴处，使不同企业通过公网构筑 VPN。Intranet VPN 和 Extranet VPN 的不同点在于访问公司总部网络资源的权限有区别

按照 VPN 技术实现的网络层次进行分类

基于数据链路层的 VPN：

L2TP、L2F、PPTP 其中 L2F 和 PPTP 已经基本上被 L2TP 替代了

基于网络层的 VPN：

GRE、IPSec

基于应用层的 VPN：

SSL

基于 Internet 的 VPN 技术有一个共同点就是必须解决 VPN 网络的安全问题：

出差员工地理位置不固定，所处位置不受企业其他信息安全措施保护，需要对出差员工进行严格的接入认证，并且对其可以访问的资源和权限进行精确控制，接入认证涉及身份认证技术

合作伙伴需要根据业务开展情况，灵活授权，限制合作伙伴可以访问的网络范围，可以传输的数据类型，此时推荐对合作伙伴进行身份认证，通过策略配置对权限限制

另外以上这些在数据传输过程中都必须是安全的，设计数据加密和数据验证技术

VPN 几个关键技术点

隧道技术

隧道技术是 VPN 的基本技术，类似点到点连接技术，基本过程就是在数据进入源 VPN 网关后，将数据“封装”后通过公司传输到目的 VPN 网关后再对数据“解封装”。“封装/解封装”过程本身就可以为原始报文提供安全防护功能，所以被封装的数据包在互联网上传递时所经过的逻辑路径被称为“隧道”不同的 VPN 技术封装/解封装的过程完全不同

身份认证技术

主要用于移动办公的用户远程接入的情况，通过对用户的身份进行认证，确保接入内部网络的用户是合法用户，而非恶意用户。

不同的 VPN 技术能提供的用户身份认证方法不同：

GRE 不支持身份认证技术

L2TP 依赖 PPP 提供的认证（CHAP、PAP、EAP）接入用户的用户名和密码本地认证也可以通过 EADIUS 服务器认证，认证通过以后再给用户分配内部 IP 地址，通过此 IP 地址对用户进行授权和管理

IPSec 通过 IKEv2 拨号时，支持进行 EAP 认证，接入用户的用户名和密码可以本地认证可以通过 RADIUS 服务器认证，认证通过以后再给用户分配内部的 IP 地址，通过此 IP 地址对用户进行授权和管理，另外 IPSec 还支持数据源认证

SSL VPN：支持本地认证，证书认证和服务器认证，主要是对服务器进行身份曲儿，曲儿 Web 网页的合法性

加密技术

加密技术就是把能读懂的报文变成无法读懂的报文，即明文->密文，这样即便黑客获取报文也无法知道真实含义，加密对象有数据报文和协议报文，能实现两种报文都加密的安全协议安全系数更高。

GRE 和 L2TP 协议本身不提供加密技术，所以通常结合 IPSe 协议一起使用，使用 IPSec 的加密技术

IPSec：支持数据报文和协议报文加密，IPSec 一般采用对称密钥算法加密数据，对称加密算法采用相同的密钥加密和解密数据

对称加密算法示意图

SSL VPN：支持对数据进行完整性验证和数据源验证。SSL VPN 采用公钥体制，利用 Hash 算法生成摘要，再用私钥加密摘要生成数字签名。利用公钥解密，利用公钥和私钥的一一关系可以对数据源进行认证

总结一下 GRE、L2TP、IPSec 和 SSL VPN 常用安全技术和使用场景：

GRE

背景：早年互联网没有这项技术时，被 Internet 互联的私有网络面临以下几个痛苦

私有 IP 网络之间无法直接通过 Internet 互通

私有网络中都是私有地址，而在 Internet 上传输的报文必须使用公网地址

异种网络（IPX、AppleTalk）之间无法通过 Internet 直接进行通信

IPX 和 IP 本就不是一种网络协议，因此 IP 网络不转发 IPX 报文

私网之间部署的动态路由无法跨越 Internet

1994 年 GRE 协议出现 被 IETF 纳入后 RFC 标号为 RFC1701 和 RFC1702

GRE（General Routing Encapsulation）通用路由封装协议，GRE 用的就是当下流行的“马甲“技术，既然私有网络发出的报文因为种种原因不能在 Internet 上传输，那么给这些报文穿上 Internet 识别的”马甲“（GRE 封装）再让它在 Internet 上传输，对于 Internet 而言，它只认”马甲“不认人，这种”马甲“技术在网络中就叫封装

任何一种网络封装技术其基本的构成要素都可以分为 3 个部分：乘客协议、封装协议、运输协议

乘客协议

为了便于理解，用邮政系统打比方，乘客协议就是我们自己写的信，信的语言可以是任何语言，具体由写信人和读信人自己负责。

封装协议

封装协议可以理解为信封，可能是平信、挂号或者 EMS，对应多种封装协议

运输协议

即信的运输方式，可以陆运，海运或者空运，对应不同的运输协议。

再来看看 GRE 用到哪些协议

GRE 能够承载的协议包括 IP 协议、IPX 协议、GRE 所使用的运输协议是 IP 协议

GRE 的封装过程可以分为两步：第一步是在私有数据添加 GRE 头；第二步是在 GRE 头前面加上新的 IP 头。加上新的 IP 头以后就意味这个私有网络的报文在经过层层封装以后就可以在 Internet 上传输了。

上述封装操作是通过一个逻辑接口来实现的，这个逻辑接口就是 Tunnel 接口（隧道）由于 Tunnel 接口是一个通用的隧道接口，所以 GRE 协议在使用这个接口的时候，会要求将这个接口的封装协议设置为 GRE 协议

下面将结合 Tunnel 接口介绍一下防火墙对 GRE 流量的转发过程

·1·企业的私网流量到达防火墙的入接口，防火墙查询路由表对此流量进行转发

·2·防火墙根据路由查找结果，将此流量引导到 Tunnel 接口进行 GRE 封装

·3·封装后的 GRE 报文再次查找路由进行流量转发

·4·防火墙根据路由查找结果，找到出接口，并将流量发送到 Internet

那隧道对端是如何解封装呢？

首先在隧道对端接收到报文以后，先根据报文目的地址判断是不是发给自己的，在明确是发给自己的后，再去判断这个报文是不是 GRE 报文，在封装原理那幅图可以看到封装后的 GRE 报文会由一个新的 IP 头，这个新的 IP 头中有个 Protocol 字段，字段中标识了内层协议类型，如果这个 Protocol 字段是 47，就表示这个报文是 GRE 报文

GRE 隧道的配置可以分为两个步骤

·1·配置 Tunnel 接口的封装参数（配置数据以 Firewall_A 为例）

interface Tunnel 1
ip address 1.1.1.1 24
tunnel-protocol gre
source 202.38.167.1
destination 202.38.163.1 

首先设置 Tunnel 接口的封装类型为 GRE，然后指定 GRE 隧道的源和目的

GRE 隧道中容易产生疑惑的地方在配置 Tunnel 接口的 IP 地址 那么

Tunnel 接口的 IP 地址是否必须配置？

隧道两端的 Tunnel 接口 IP 地址是否有所关联？

Tunnel 接口使用的是公网 IP 地址还是私网 IP 地址？

首先 Tunnel 接口的 IP 地址必须配置，如果不配置 IP 地址，Tunnel 接口就无法 UP 起来，其次，从 GRE 的封装过程来看，Tunnel 接口的 IP 地址并没有参与报文封装，所以隧道两端的 Tunnel 接口没有任何关联，既然 Tunnel 接口不参与封装，所以配置成私网就可以了

配置路由，将要进行 GRE 封装的流量引到 Tunnel 接口

把流量引入到 GRE 隧道有两种方法，一种是静态路由，一种是动态路由

静态路由配置

ip route-static 192.168.2.0 24 Tunnel 1

动态路由配置

如果私网内部使用的是动态路由（如 OSPF）则只要把私网地址和 Tunnel 接口地址一起通过 OSPF 发布出去

ospf 1
area 0
network 1.1.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255

需要注意的地方是，如果，GRE 隧道对应的公网接口也使用了 OSPF，那我们就需要用一个新的 OSPF 进程来发布私网地址和 Tunnel 接口地址

那么假设有恶意用户伪装发送 GRE 报文怎么办呢？

防火墙配置了 GRE 隧道，并不是说防火墙收到所有的 GRE 报文都会进行处理，它只处理与本防火墙建立 GRE 隧道的对端设备发过来的 GRE 报文。就是建立 GRE 隧道的两台设备要设置一个”密钥‘，这个密钥就是身份凭证，密钥信息被封装在 GRE 报文的头部，当一端收到一个 GRE 报文以后，都会检查该密钥，只有密钥一致时，才认为是隧道对端发过来的 GRE 报文。“身份校验”不通过，该 GRE 报文会被丢弃

参考下图

其中 GRE 报文头中 Key 字段为 1，表示用户设置了身份验证功能，下面的 GRE key：0x0001e240 是用户配置的密钥值

虽然身份校验机制可以保证 GRE 隧道两端可以实现互信，但是如果报文在 Internet 传输途中被其他用户恶意篡改，又怎么办呢？ 这里可以用到 GRE 头中的另一个字段 checksum。GRE 封装报文时，会根据报文信息计算校验和，并将这个校验和插入到 checksum 字段中。当隧道对端收到该报文时，对端也会根据报文信息计算校验和，并与报文中携带的校验和进行比较，如果一致，则接受，不一致则丢弃，参考下图

checksum 为 1，表示启用校验和功能，下面 checksum：0x6dbd 是校验和对应的值

GRE 的安全机制可以实现隧道两端的互信，并保证报文传输的完整性

但是隧道对端设备出现故障，本端如何感知呢？

GRE 隧道是无状态类型隧道，无状态即隧道本端并不维护与对端的状态，假如隧道对端出现故障，那隧道本端是感受不到的，为了解决这个问题，GRE 隧道提供了一种保活机制（keepalive）GRE 隧道对端出现问题，则隧道源的 Tunnel 接口状态会被置为 Down，即本端关闭 GRE 隧道，避免了因对端不可达而造成的数据黑洞，GRE 的 Keepalive 功能是单向的，对端是否支持或启用 Keepalive 功能不影响本端的 Keepalive 功能，实际配置时，建议两边都配置保活功能。

GRE 技术不带有安全加密功能，没有加密功能的 GRE 报文只能说是穿了透明的马甲，所要传输的数据比尔看得清清楚楚，所以在实际使用中很少单纯使用 GRE，而是经常与 IPSec 技术联用，由于 IPSec 技术具备很强的加密功能，解决了 GRE 的安全性问题，也就是经常听到的 GRE over IPSec 技术

就是在 GRE 将报文封装后再经过 IPSec 封装

L2TP VPN

诞生及演进

在传统的基于 PSTN/ISDN 的 L2TP VPN 中，运营商在 PSTN/ISDN 和 IP 网络之间部署 LAC （在 VPDN 里称为 NAS，Network Access Server），集中为多个企业用户提供 L2TP VPN 专 线服务，配套提供认证和计费功能。当分支机构和出差员工拨打 L2TP VPN 专用接入号时， 接入 modem 通过 PPP 协议与 LAC 建立 PPP 会话，同时启动认证和计费。认证通过后 LAC 向 LNS 发起 L2TP 隧道和会话协商，企业总部的 LNS 出于安全考虑，再次认证接入用户身 份，认证通过后分支机构和出差员工就可以访问总部网络了

LAC 和 LNS 是 L2TP 协议里的概念，NAS 是 VPDN 里的概念，在 L2TP VPN 中 LAC 实际就是 NAS。

随着 IP 网络的普及，PSTN/ISDN 网络逐渐退出数据通信领域，个人和企业都可以自由通过以太网直接接入 Internet，此时 L2TP VPN 也开始向前发展

现 L2TP VPN 常用场景如下图；

L2TP VPN 的发展

第一步：PPP 落户以太网，拨号网络向以太网演进的必经之路，不是专门为了 L2TP VPN 设计，但 L2TP VPN 是最大受益者，分支 机构用户安装 PPPoE Client，在以太网上出发 PPPoE 拨号，在 PPPoEClient 和 LAC（PPPoE Server）之间建立 PPPoE 会话，LAC 和 LNS 之间的 L2TP VPN 建立过程没有变化

第二步：L2TP 延伸到用户 PC：这种场景下，PC 可以通过系统自带的 L2TP 客户端或第三方 L2TP 客户端软件直接拨号与 LNS 建立 L2TP VPN。L2TP Client 摒弃 LAC 直接跟总部直接建立合作关系

这两种场景跟初始 L2TP VPN 场景相比有一个共同特征，就是企业借用运营商管道自建 VPN，避开了运营商 VPN 专线业务收费。

为了区分这两种 L2TP VPN

前者（基于 LAC 拨号的 L2TP VPN）被称为 NAS-Initiated VPN

后者（客户端直接拨号的 VPN）被称为 Client-Initiated VPN

L2TP Client-Initiated VPN

如今最常见的是 PPPoE 客户端，其次是 VPN 客户端，VPN 客户端的作用就是帮助用户在 PC 或 PAD 或手机上出发建立一条直通公司总部网络的隧道，实现用户自由访问总部网络的医院，当然用户能轻松进入隧道也必须可以自由离开隧道切换到直接访问 Internet

要借助 L2TP 客户端进入公司网络，首先要通过 LNS 的身份检查（用户名，密码，主机名，隧道验证等等）LNS 为通过验证的用户发放特别通行证（公司内部 IP 地址）Client-Initiated VPN 配置中体现的思路如下：

本地认证配置：

VT 接口是用于二层协议通信的逻辑接口，如 PPP 和 L2TP 协议通信，PPP 和 Ethernet 协议通信都会用到它，所以在 L2TP VPN 中要开启 VT 接口所在安全区域跟 L2TP 物理接口所在安全区域之间的包过滤，保证 PPP 和 L2TP 协议通信畅通无阻

结合抓包情况详解 Client-Initiated VPN 建立过程：

·1·建立 L2TP 隧道（控制连接）：3 条消息协商进入隧道时机

L2TP Client 和 LNS 通过交互三条消息协商隧道 IP/UDP 端口（LNS 用 1701 端口响应 Client 隧道建立请求）/主机名称/L2TP 的版本/隧道验证（Client 不支持隧道验证时 LNS 的隧道验证要关闭，例如 Win7 操作系统）

下表仅给出隧道 ID 协商过程：

·2·建立 L2TP 会话：3 条消息唤醒 LNS

L2TP Client 和 LNS 通过交互三条消息协商 Session ID，建立 L2TP 会话

ZLB 表示目前空闲，没有消息要发送

Session ID 协商过程：

·3·创建 PPP 连接：身份验证，发放特别通行证

1.LCP 协商

LCP 协商是两个方向分开协商的，主要协商 MRU 大小。

MRU 是 PPP 的数据链路层参数，类似以太网中的 MTU，如果 PPP 链路一端设备发送的报文在和大于对端的 MRU，这个报文在传送时就会被分片

2.PPP 验证

验证方式包括 CHAP/PAP/EAP（高端防火墙不支持），CHAP 或 PAP 可以在本地认证，也可在 AAA 服务器上认证：EAP 只能在 AAA 服务器上进行认证，EAP 认证比较复杂，我们等到 IPSec 部分再详解，这里只给最常用的 CHAP 验证过程

经典的三次握手过程：

LNS（或 AAA 服务器）上配置的用户名和密码是用来验证 Client 的，要求”本人“和”签证“完全一致，即要求 L2TP Client 和 LNS 上配置的用户名和密码完全一致

如果在LNS上配置的签证为Username（没有domain），则L2TP Client登录的用户名也要是Username
如果在LNS上配置的签证为fullusername（username@default或username@domain）则L2TP Client登录的用户名也要是username@default或username@domain

那么划分 domian 有何意义

对于大企业来说，会按照部分来划分多个 domain，LNS（或 AAA 服务器）都支持根据 domain 给不同部分创建不同的地址池，也就是不同部门的网段可以通过地址池规划分开，这样方便后续部署不同的访问控制策略

3.IPCP 协商 成功后分配 IP 地址

分配给 Client 的 IP 地址是 10.21.80.2 后续交互的报文都是由 10.21.80.2-Client 的私网地址发出的

VT 接口地址和地址池地址如何规划？

VT 接口和地址池地址跟其他内网主机地址一样，都应该遵循内网 IP 地址规划原则，建议为 VT 口和地址池规划独立网段，且二者的地址不要重叠

总结 Client-Initiated VPN 特点

L2TP VPN 跟 GRE VPN 有很大不同 ，GRE VPN 没有隧道协商过程，是没有控制连接的隧道，是没有状态的隧道，所以也无法查看隧道，检查隧道状态，但 L2TP VPN 是有控制连接的隧道，可以查看到隧道和会话（IPSec VPN 表现的更好）

对于 Client-Initiated VPN 来说 Client 和 LNS 之间存在一条 L2TP 隧道，隧道中只有一条 L2TP 会话，PPP 连接就承载在此 L2TP 会话上（这点跟 NAS-Initiated VPN 不同）

·4·数据封装传输

本例为两个 Client 之间通信，所以私有 IP 地址为两个内网地址

Client 的报文到达总部没有问题了，那么总部服务器到 Client 的回程报文是如何进入隧道返回 Client 的？

查看 LNS 路由表，发现了一个有趣的现象：LNS 为获得私网 IP 地址的 Client 自动下发了一条主机路由。

这条自动生成的主机路由协议类型为 UNR（User Network Route）下一跳为 Client 本身的地址，出接口是 LoopBakc0，这条路由就是 LNS 进隧道的入口，指引去往 Client 的报文进入隧道

在实际环境中有多个 Client 同时穿过隧道访问总部网络，如果 Client 还想访问其他的 Client，L2TP 能满足，吗？

LNS 是连接多个隧道的中转站，通过 LNS 来转发，两个 Client 之间也可访问，前提是双方要知道 LNS 为对方配置的 IP 地址

L2TP NAS-Initiated VPN

Client-Initiated VPN 可以让企业出差员工通过隧道来去自如访问网络，但分支机构只能通过拨号网络接入 Internet，即便拨号网络演进到以太网，也只解决了本地接入 Internet 的问题，无法访问总部网络

但 LAC 的出现解决了这个问题，一方面 LAC 作为 PPPoE Server 分支机构作为 PPPoE Client 与 LAC 建立 PPPoE 连接，让 PPP 跑在以太网上，另一方面，LAC 作为 LNS 的中介，为分支机构提供隧道的入口，在分支机构用户看，通过 LAC 就可以到达总部网络

因为在 VPDN 里 LAC 有一个别名叫 NAS ，所以这种 L2TP VPN 也称为 NAS-Initiated VPN

为了复习一下 PPPoE 的相关知识，我们用一台防火墙作为 PPPoE Client，模拟 PC 的 PPPoE Client：

·1·拨号口对 VT 口的呼唤：建立 PPPoE 连接

PPP 屈尊落户以太网变为 PPPoE 后，为了在以太网上模拟 PPP 的拨号过程，PPPoE 发明 了两个虚拟接口——Dialer 接口和 VT 接口。Dialer 接口用于 PPPoE Client 侧，VT 接口用于 PPPoE Server（即 LAC）侧，在这两个接口上配置 PPPoE 相关参数。

通过抓包来分析 PPPoE 连接建立过程

重点介绍 PPPoE 发现阶段的协商过程，PPPoE Client 和 PPPoE Server 之间通过交互 PADI、PADO、PADR 和 PADS 报文，确定对方以太网地址和 PPPoE 会话 ID：

·2· 建立 L2TP 隧道：3 条消息协商进入隧道时机

LAC 和 LNS 通过交互三条消息协商 L2TP 隧道，这个过程我们在“Client-Initiated VPN”一 篇中已经介绍过了，这里再复习一遍。首先来看一下 LAC 和 LNS 的具体配置：

抓包信息如下

隧道 ID 协商过程：

·3·建立 L2TP 会话，三条消息唤醒 LNS

LAC 和 LNS 通过交互三条消息协商 Session ID，建立 L2TP 会话。同样，我们再复习一遍这 个过程。

Session ID 协商过程：

·4&5·LNS 冷静接受 LAC：LNS 认证 分配 IP 地址

1.LNS 认证&二次认证（可选）

LAC 将用户信息发给 LNS 进行验证，但 LNS 认识到 LAC 中介的三种面目，对此 LNS 有三种态度

· LAC 代理认证：相信 LAC 是可靠的，直接对 LAC 发来的用户信息进行验证

· 强制 CHAP 认证：不相信 LAC，要求重新对用户进行资格审查（强制重新对用户进行 CHAP 认证）

· LCP 重协商：不仅不相信 LAC，还对前面签订的业务合同不满，要求跟用户重新洽谈（重新发起 LCP 协商，协商 MRU 参数和认证方式）

后两种方式统称为 LNS 二次认证，若 LNS 配置二次认证而 PPPoE Client 不支持二次认证 将会导致 L2TP VPN 无法建立

两种二次认证的共同特征是 LNS 都绕过了 LAC 直接验证 PPPoE Client 提供的用户信息，可以为 VPN 业务提供了更高的安全保障

2.分配 IP 地址

通过 PPP IPCP 协商，LNS 为 PPPoE Client 分配 IP 地址

关于地址池地址的规划问题，在“Client-Initiated VPN”讲过。同样，建议把 地址池地址和总部网络地址规划为不同的网段。如果地址池地址和总部网络地址配置为同一 网段，则必须在 LNS 连接总部网络的接口上开启 ARP 代理功能，并且开启 L2TP 虚拟转发 功能，保证 LNS 可以对总部网络服务器发出的 ARP 请求进行应答。 假设 LNS 连接总部网络的接口是 GigabitEthernet0/0/1，开启 ARP 代理功能和 L2TP 虚拟转 发功能的配置如下：

interface GigabitEthernet0/0/1
ip address 192.168.0.1 255.255.255.0
arp-proxy enable //开启 ARP 代理
virtual-l2tpforward enable //开启 L2TP 虚拟转发

总结 NAS-Initiated VPN 特点

在 NAS-Initiated VPN 场景中，一对 LAC 和 LNS 的连接可存在多条隧道；一条隧道中可承载多条会话，接入用户 1 与 LNS 之间建立 PPP 连接 1 和 L2TP 会话 1，接入用户 2 与 LNS 之间建立 PPP 连接 2 和 L2TP 会话 2

当一个用户拨号后，触发 LAC 和 LNS 之间建立隧道，只要此用户尚未下线，则其余用户拨号时，会在已有隧道基础上建立会话，而非重新出发建立隧道

·6·一路畅通：数据封装传输

PPPoE Client 访问总部服务器的报文到达 LAC 后，LAC 为报文穿上三层”马甲“，即 L2TP 头/UDP 头和公网 IP 头，然后发送到 LNS。LNS 收到报文后，脱去三层马甲将报文转发至服务器

报文封装和解封装过程：

分支机构员工使用 PPPoE Client 就可以畅通无阻访问总部网络。但是 从总部服务器到 PPPoE Client 的回程报文是如何进入隧道返回的呢？还记得我们在 “Client-Initiated VPN”一篇中介绍过的 UNR 路由吧，NAS-Initiated VPN 也是这样处理的。 LNS 会为获得 IP 地址的 PPPoE Client 自动下发了一条 UNR 路由，下一跳为 PPPoE Client 本身的地址，出接口是 InLoopBack0，这条路由将指引回程报文进入隧道。回程报文进入隧 道后被封装上公网 IP 地址，然后 LNS 将会以该公网 IP 地址为目的地址再次查找路由，将封 装后的回程报文送往 LAC

L2TP LAC-Auto-Initiated VPN

LAC-Auto-Initiated VPN 也叫做 LAC 自动拨号 VPN，顾名思义，在 LAC 上配置完成后，LAC 会自动向 LNS 发起拨号，建立 L2TP 隧道和会话，不需要分支机构用户拨号来触发。对于分 支机构用户来说，访问总部网络就跟访问自己所在的分支机构网络一样，完全感觉不到自己 是在远程接入。但是这种方式下 LNS 只对 LAC 进行认证，分支机构用户只要能连接 LAC 即 可以使用 L2TP 隧道接入总部，与 NAS-Initiated VPN 相比安全性要差一些

LAC-Auto-Initiated VPN 的配置也不复杂，以下面这个组网为例：

LAC 和 LNS 上的配置如下：

LAC-Auto-Initiated VPN 的建立过程与 Client-Initiated VPN 类似，不过在前者中，LAC 取代了 Client-Initiated VPN 中 L2TP Client 的角色

各个阶段的建立过程与 Client-Initiated VPN 的建立过程大同小异，需要注意的是 在阶段 3 中，LNS 只对 LAC 进行验证，验证通过后为 LAC 的 VT 接口分配 IP 地址，而不是为分支机构用户分配 IP 地址，虽然 LNS 不为分支机构分配 IP 地址，但是并不代表分支机构的 IP 地址可以随意配置

为了保证分支机构网络与总部网络之间正常访问，需要为分支机构网络和总部网络规划各自独立的私网网段，二者网段地址不能重叠

总结 LAC-Auto-Initiated VPN 特点：

LAC-Auto-Initiated VPN 场景中，LAC 和 LNS 之间建立一条永久隧道，且仅承载一条永久的 L2TP 会话和 PPP 连接，L2TP 会话和 PPP 连接只存在于 LAC 和 LNS 之间

LAC-Auto-Initiated VPN 的 PPP 封装和 L2TP 封装仅限于 LAC 和 LNS 之间的报文交互：

需要重点关注的是回程报文如何进入隧道，与 Client-Initiated VPN 以及 NAS-Initiated VPN 不同，在 LAC-Auto-Initiated VPN 中，LNS 只下发了一条目的地址为 LAC 的 VT 接口地址的 UNR 路由，并没有去往分支机构的路由，对此 LNS 只对分配出去的 IP 地址负责，所以保证可以到达对端 LAC 的 VT 接口，分支机构网络地址不是 LNS 分配的。

如何解决这个问题？最简单的方法就是在 LNS 手动配置一条去往分支机构的网络静态路由，指引回程报文进入隧道：

ip route-static 172.16.0.0 255.255.255.0 Virtual-Template 1

除了配置静态路由，还可以在 LAC 上配置源 NAT，把分支机构访问总部网络报文的源地址转化成 VT 接口的地址，即 easy-IP 方式的源 NAT，LNS 收到回程报文后，发现目的地址是 LAC 的 VT 接口的 IP 地址，就会按照 UNR 路由进入隧道转发

下面以实际组网为例，介绍 LAC 上配置源 NAT 后，分支机构用户访问总部服务器时的报文封装与解封装的过程

·1·LAC 收到分支机构用户访问总部服务器的原始报文后，根据目的地址查找路由，命中我们手动配置的静态路由，将报文发送至 VT 接口。

·2·LAC 在 VT 接口对原始报文进行 NAT 转换，将源地址转换成 VT 接口地址，然后为报文封装 PPP 头、L2TP 头和公网地址，LAC 根据公网目的地址查找路由，将封装后的报文发送至 LNS

·3·LNS 收到报文后，剥离调 PPP 头、L2TP 头，根据目的地址查找路由（此处为直连路由），然后将报文发送至总部服务器

·4·LNS 收到总部服务器的回程报文呢后，根据目的地址查找路由，命中 LNS 自动下发的 UNR 路由，将报文发送至 VT 接口

·5·报文在 VT 接口封装 PPP 头、L2TP 头和公网地址，LNS 根据公网目的地址查找路由，将封装后的报文发送至 LAC

·6·LAC 收到报文后，剥离 PPP 头、L2TP 头，将报文的目的地址转换成分支机构用户地址，然后将报文发送至分支机构用户

在 LAC 上配置 easy-IP 方式源 NAT 示例如下（假设在 LAC 上连接分支机构网络的接口属于 Trust 区域，VT 接口属于 Untrust 区域）

nat-policy interzone trust untrust outbound
policy 1
 action source-nat
 policy source 172.16.0.0 0.0.0.255
easy-ip Virtual-Template 1 

三种 L2TP VPN 总结

IPSec VPN

背景：

随着 GRE 和 L2TP 的广泛应用，在总部和各个分部之间部署了 GRE 和 L2TP 无论是 GRE 还是 L2TP，建立 的隧道都没有任何安全加密措施 。 IPSec（IP Security）。作为新一代的 VPN 技术，IPSec 可以在 Internet 上建立安全稳定的专用线路。与 GRE 和 L2TP 相比，IPSec 更 加安全，能够保证总部与分部之间消息的安全传输。

IPSec 巧妙借用了密码 学门派所擅长的易容障眼之法，融会到自创的 AH（Authentication Header，验证头）和 ESP （Encapsulating Security Payload，封装安全载荷） 既可改头换面瞒天过海， 也能验明正身完璧归赵。即便消息被截获了也没人能看懂，被篡改了也能及时发现。

加密

IPSec在传递消息之前，先使用加密算法和加密密钥；另一方收到消息后，使用相同的加密算法和加密密钥，逆向解密。

例总部和分部使用相同密钥来加密和解密，这种方式也称作对称加密算法，主要包括DES、3DES和AES。

验证

一方传递消息之前，先使用验证算法和验证密钥对信息进行处理，得到签字画押的文书——签名。随后将前面协消息一起发出，收信者使用相同验证算法和验证密钥对消息进行处理，得到前面，然后比对两端的前面，如果相同则证明消息没有被篡改。

除了对消息的完整性进行验证，IPSec 还可以对消息的来源进行验证，即验明消息的正身，
保证消息来自真实的发送者。

通常情况下，验证和加密配合使用，加密后的报文经过验证算法处理生成签名，常用的验证算法有MD5和SHA系列。

IPSec 的两大绝技中，AH 只能用来验证，没有加密的功能，而 ESP 同时具有加密和验证的
功能，AH 和 ESP 可以单独使用也可以配合使用。

安全封装

IPSec设计了两种封装模式：

隧道模式

该模式下，AH头或ESP头被插到原始IP头之前，另外生成一个新的报文头放到AH头或ESP头之前：

隧道模式使用新的报文头来封装消息，可以保护一个网络的消息，适用于两个网关之间的通信。

传输模式

该模式下，AH头或ESP头被插入到IP头与传输层协议头之间：

传输模式不改变报文头，隧道的源和目的地址就是最终通信双方的源和目的地址，通信双方智能保护自己发出的消息，不能保护一个网络的消息，所以该模式只适用于两台主机之间通信。

安全联盟

IPSec中通信双方建立的连接叫做安全联盟（SA|Security Association）。

使用相同的封装模式、加密算法、加密密钥、验证算法、验证密钥、相互信任亲密无间。

安全联盟是单向的逻辑连接，为了使每个方向都得到保护，双方的每个方向（出|入）都要建立安全联盟。

为了区分不同方向的安全联盟，IPSec为每个安全联盟都打上了唯一的标识符，这个标识符叫做SPI（Security Parameter Index）

建立安全联盟最直接的方式就是分别在通信双方上手动设定好封装模式、加密算法、加密密钥、验证算法、验证密钥。

手动部署IPSec隧道

为了让加密、验证、安全联盟的配置关系更清晰，IPSec为手工方式定义了四个步骤：

1-定义需要保护的数据流——只有双方的消息才受保护

2-配置IPSec安全提议——封装模式、ESP、加密算法和验证算法均要在其中设置

3-配置手工方式的IPSec安全策略——指定双方公网地址、安全联盟标识符SPI、加密密钥和验证密钥

4-应用IPSec安全策略

[NOTE!]

除了上述配置外，防火墙安全测也需要配置，允许总部和分部建立安全联盟，以及允许双方私网互访。

部署完成后，总部内部网络向分部内部网络发出 ping 消息，分部内部网络回复 ping 消息，
发现两个方向的 ping 消息都已经被 IPSec 安全联盟保护。两个方向上 IPSec 安全联盟的标识符 SPI 分别为 0x3039（十进制 12345）以及 0xd431（十进制 54321），与上文配置相符。

分析报文的内容，发现 ping 消息已经被加密，面目全非无法辨识

为了对比 ESP 和 AH 的作用，又使用 IPSec 中的另一绝技 AH 来建立安全联盟。AH
只有验证功能，没有加密的功能，能够从查到的消息中看到私网报文头和 ping 消息真容。

因此，要实现加密，还是要使用ESP，或AH和ESP配合使用。