华为Eudemon防火墙从接口IP到ACL包过滤完整配置链路

简介：这是一份聚焦华为Eudemon防火墙配置的实操型资料，面向网络工程师、企业IT运维及华为安全技术学习者，解决从接口接入、路由打通到安全策略落地的典型配置需求。文档以Eudemon连接Trust、DMZ与Untrust三个安全区域为场景，完整覆盖接口IP与缺省路由配置、安全区域及所属接口划分、NAT地址池与ACL规则联动、多区域包过滤策略配置等关键环节；所有操作按步骤给出CLI命令与参数说明，附带配置前后逻辑说明，便于读者在实际设备或模拟器中对照练习。资源包共1个文件，格式为PDF，整体约35KB，内容紧凑、方便随时查阅与离线学习。目前已有194人学习下载，适合正在备考华为安全认证或需要快速上手Eudemon防火墙项目的读者参考，可直接借鉴其配置框架与排错思路，也可作为实际部署前的快速梳理。

1. 华为 Eudemon 防火墙配置：从接口到包过滤的一条完整线

刚接手华为 Eudemon 防火墙的网工，最容易踩的坑就是「照着三层交换机配完接口，发现业务还是不通」。原因很简单：防火墙的转发逻辑里，接口 IP 只是第一步，后面还跟着安全区域、NAT 地址池、ACL 规则这一整条链路，少一环都白搭。这份配置分享的价值，在于它把顺序讲得明明白白——先让网络层互通，再把接口划进 Trust、DMZ、Untrust 三个区域，最后才轮到 NAT 和包过滤。适合正在做华为防火墙项目、或者备考华为认证需要动手做实验的人，照着敲一遍，基本能摸清 Eudemon 的配置套路。

2. 接口与路由配置：三个物理口撑起 Trust、DMZ、Untrust

2.1 接口 IP 与链路层参数：先让网络层「能见面」

Eudemon 防火墙本身没有太多需要单独配置的链路层参数，多数场景下直接用默认的 Ethernet 接口参数就行，重点是把网络层 IP 规划好。这份资料里的拓扑很典型：三个接口各接一个安全区域——Ethernet0/0/0 接 Trust 内网，Ethernet1/0/0 接 Untrust 外网，Ethernet2/0/0 接 DMZ 服务器区。

[Eudemon] interface ethernet 0/0/0 [Eudemon-Ethernet0/0/0] ip address 10.110.1.11 255.255.255.0 [Eudemon-Ethernet0/0/0] quit [Eudemon] interface ethernet 1/0/0 [Eudemon-Ethernet1/0/0] ip address 202.38.160.1 255.255.0.0 [Eudemon-Ethernet1/0/0] quit [Eudemon] interface ethernet 2/0/0 [Eudemon-Ethernet2/0/0] ip address 10.110.5.11 255.255.255.0 [Eudemon-Ethernet2/0/0] quit

三段命令的逻辑是一样的：进入接口视图，配 IP 和掩码，退出来继续配下一个口。注意外网接口用的是 255.255.0.0 这个 /16 掩码，说明运营商给的是一个 B 段公网地址范围，而不是单个 IP。实际项目里需要跟运营商确认清楚到底给了多少地址，掩码写窄了会丢路由，写宽了可能让防火墙认为某些不该直连的地址在本地，影响转发判断。

配完接口建议立刻用display ip interface brief检查一遍，确认三个接口的物理状态和协议状态都是 Up。这个习惯很多老手都有——接口配错或者网线没插好，后面配置做得再漂亮也白搭。

2.2 缺省路由与回程路由：路由表的两个方向

接口 IP 配好之后，防火墙自己还不知道怎么把数据包送出去。这里需要两条路由：一条是去外网的缺省路由，一条是回内网网段的明细路由。

[Eudemon] ip route-static 0.0.0.0 0.0.0.0 202.38.160.15 [Eudemon] ip route-static 10.110.1.0 255.255.255.0 10.110.1.2

第一跳写0.0.0.0 0.0.0.0，意思是所有未知目的地址的流量都扔给 202.38.160.15，也就是运营商侧网关。注意这里的目的地址是外网网关，不是防火墙自己的外网口 IP。第二跳是回程路由，把 Trust 内网 10.110.1.0/24 的流量指向 10.110.1.2，常见做法是内网还有一台三层交换机或者核心交换机承担网关角色，防火墙把去内网的流量交给它。

很多人在这里会犯迷糊：防火墙自己就是 10.110.1.11，为什么还要写一条去 10.110.1.0/24 的路由？因为 10.110.1.2 是内网三层设备的地址，如果内网还存在其它网段（比如 10.110.2.0/24），防火墙不写明细路由就不知道怎么送回去。项目里如果内网只有一个网段且全部二层直连，这条路由可以不配，但写上更稳妥，尤其内网还挂着三层设备的时候。

2.3 验证网络连通性：从 ping 网关到 ping 远端

路由配完，先别急着做区域和 NAT，把三层连通性验证一遍。这一步不过关，后面所有配置出了问题都很难定位。

[Eudemon] ping 202.38.160.15 [Eudemon] ping 10.110.1.2 [Eudemon] display ip routing-table

第一条确认外网链路通不通，第二条确认和 Trust 侧三层设备能不能通信，第三条看路由表里缺省路由和明细路由有没有同时存在。在这个阶段，Eudemon 的安全区域还没有划分，接口处于「裸奔」状态，ping 通常能通。如果 ping 不通外网网关，先查物理链路，再查接口状态，最后看路由表——大部分三层不通的问题，按这个顺序排查都能找到原因。

3. 安全区域划分：把接口放进三个「信任等级」的框

3.1 为什么必须用区域模型而非直接下发 ACL

Eudemon 防火墙的区域模型，本质是把接口按照信任程度分组，然后在区域之间定义策略。相比直接在接口上挂 ACL，区域模型的优势在于：策略的方向性一目了然——Trust 到 Untrust、Untrust 到 DMZ，每个方向的过滤规则独立管理，不会出现「这个 ACL 到底管哪个方向」的混乱。

华为 Eudemon 系统保留的安全区域有三个：Trust 优先级最高，DMZ 次之，Untrust 最低。默认情况下，所有区域之间的流量都是拒绝的。这块逻辑跟华为三层交换机上的 ACL 差别很大——交换机上 ACL 不主动配置就不会拦截，但防火墙默认就是「全关」，必须显式放行才能通。刚转过来做防火墙的人，最容易在这里懵：接口 IP 配好、路由也通，但业务就是不通，原因就是区域还没有划，或者划了但没放行。

3.2 区域归属配置：三条 add interface 命令

把接口加入区域的命令很简单，每个区域只需要一条 add interface：

[Eudemon] firewall zone trust [Eudemon-zone-trust] add interface ethernet 0/0/0 [Eudemon-zone-trust] quit [Eudemon] firewall zone dmz [Eudemon-zone-dmz] add interface ethernet 2/0/0 [Eudemon-zone-dmz] quit [Eudemon] firewall zone untrust [Eudemon-zone-untrust] add interface ethernet 1/0/0 [Eudemon-zone-untrust] quit

这段配置做的事情非常直白：进入对应区域视图，把接口绑进去。注意quit不是随便敲的，它决定了你当前在哪个视图下敲命令。配区域的时候最容易犯的错是在错误的视图下敲命令——以为自己在接口视图，结果命令行提示符还是系统视图，命令直接报错。

配置完成后可以用display firewall zone查看各区域下挂了哪些接口，确认没有把一个接口重复加入多个区域。一个接口只能属于一个区域，重复添加会报错。少数项目里会把管理口单独划到一个 zone 或者放进 Trust，这个看具体安全要求，但生产环境不建议让管理口和业务口混在同一个区域。

3.3 区域默认行为与后续配置的依赖关系

区域划分完成之后，Eudemon 的安全机制开始生效：Trust 区域的主机访问外网，默认是不通的，因为区域间的默认策略是 deny。这就是为什么这份资料把 NAT 和包过滤放在区域划分之后——没有区域，NAT 就不知道把哪个方向的流量做转换；没有放行策略，转换完的流量也过不去。

在华为的区域模型里，firewall interzone trust untrust这类命令表示「在 Trust 和 Untrust 之间的通道上做配置」，它是双向概念，但后面跟的outbound或inbound明确了具体方向。这里的方向判断是整个配置里最容易翻车的地方，我在后面包过滤章节会单独讲。做过华为三层交换机项目的人上手会快一些，陈旧的「接口下挂 ACL」思路在这里需要调整成「区域间定义策略」的思维。

4. NAT 多对多转换：地址池 + ACL + 区域方向的组合

4.1 NAT 地址池与 ACL 的配合逻辑

Eudemon 的多对多 NAT，简单说就是把内网一批私有 IP 映射到地址池里的一批公网 IP。地址池定义一个范围，ACL 决定哪些流量可以占用地址池里的地址，两者缺一不可。

[Eudemon] nat address-group 1 202.110.1.241 202.110.1.254 [Eudemon] acl number 2010 [Eudemon-acl-basic-2010] rule 0 permit source 10.110.1.0 0.0.0.255 [Eudemon-acl-basic-2010] rule 1 deny any [Eudemon-acl-basic-2010] quit

nat address-group 1里的1是地址池编号，后面跟起始和结束地址，一共 14 个公网地址。ACL 2010 是基本 ACL，只能匹配源地址，rule 0 permit source 10.110.1.0 0.0.0.255放行整个内网网段，rule 1 deny any把其它网段全部挡住。

注意 ACL 规则是顺序匹配的，rule 0在前面，所以同一条数据流只要命中 permit 就不会继续往下匹配了。如果把deny any放在前面，内网所有流量都会被拒掉，NAT 也就失去了意义。这个顺序习惯在配置任何 ACL 时都要保持：先写精确的允许规则，再写兜底的拒绝规则。

4.2 区域间方向上的 nat outbound

地址池和 ACL 准备好了，接下来是把它们绑定到 Trust 到 Untrust 的方向上：

[Eudemon] firewall interzone trust untrust [Eudemon-interzone-trust-untrust] nat outbound 2010 address-group 1

nat outbound 2010 address-group 1的含义是：在从 Trust 区域向外（Untrust 区域）的流量方向上，对匹配 ACL 2010 的数据流执行地址转换，转换后的源地址从地址池 1 里挑选。这个outbound是相对 Trust 区域来说的——从 Trust 出去叫 outbound，从 Untrust 进来叫 inbound。

理解了这个方向，后面配包过滤才不会混乱。NAT 转换发生在区域交界处，数据包从内网接口进来，先被识别为 Trust 区域的流量，再在向 Untrust 转发的过程中被改写源地址。如果内网主机想访问 DMZ 区域服务器，那是 Trust 到 DMZ 的另一个通道，需要单独配置 NAT 或者干脆不做 NAT，直接靠路由转发。

4.3 验证 NAT 转换效果与反向隔离

配置完成后的验证分两个方向：

第一，Trust 区域内任意主机（比如 10.110.1.1）能通过防火墙访问外部网络，能 ping 通公网用户 202.12.7.7。这证明 NAT 转换成功——如果 NAT 没生效，内网私有地址的数据包到达公网后回不来，ping 必然超时。

第二，反向测试：公网用户 202.12.7.7 不能主动访问 Trust 区域内的主机，ping 10.110.1.1 应该是超时的。这个结果是 NAT 的副作用——内网地址在公网上不可达，外部主动发起的连接没有对应的转换会话，自然进不来。这个特性对很多企业的价值很大，等于白送了一层安全防护。

验证 NAT 会话可以用display nat session查看，能看到源地址、转换后的地址和会话状态。常见做法是找一个内网主机持续往外 ping，另一个终端同时盯 NAT 会话表，看私网地址是不是被正确替换成地址池里的公网地址。

5. 包过滤配置与四个高频避坑点

5.1 两种 ACL 风格的选择

包过滤的核心工具是 ACL，但 Eudemon 上 ACL 分两种：基本 ACL（2000-2999）只能匹配源地址，高级 ACL（3000-3999）可以匹配源、目的、协议、端口。上一章里 NAT 用的 2010 是基本型，包过滤这种需要精确控制协议和端口的场景，通常用高级 ACL。

[Eudemon] acl number 3101 [Eudemon-acl-adv-3101] rule permit ip source 10.110.1.0 0.0.0.255 destination any [Eudemon-acl-adv-3101] rule deny ip [Eudemon-acl-adv-3101] quit [Eudemon] acl number 3102 [Eudemon-acl-adv-3102] rule permit ip source 202.12.7.7 0 destination 10.110.5.100 0 [Eudemon-acl-adv-3102] rule permit ip source 202.12.7.7 0 destination 10.110.5.101 0 [Eudemon-acl-adv-3102] rule deny ip [Eudemon-acl-adv-3102] quit

ACL 3101 放行整个内网网段访问任意目标，主要用于 Trust 区域对外访问；ACL 3102 只允许公网特定主机 202.12.7.7 访问 DMZ 里的两台服务器（10.110.5.100 和 10.110.5.101），其它外部访问一律拒绝。

这里有一个容易被忽略的细节：ACL 3102 里没有写端口，意味着这台公网主机可以访问 DMZ 服务器的所有端口，包括 SSH、数据库端口等。示例环境里这么写没问题，但生产环境建议把端口收紧，比如限定destination-port eq ftp或者destination-port eq www，避免把服务器管理端口也暴露出去。

5.2 packet-filter 的区域与方向绑定

ACL 只是规则本身，真正让它生效的是packet-filter命令。这条命令必须指定两件事：在哪个区域间生效，以及哪个方向生效。

[Eudemon] firewall interzone trust untrust [Eudemon-Interzone-trust-untrust] packet-filter 3101 outbound [Eudemon] firewall interzone trust dmz [Eudemon-Interzone-trust-dmz] packet-filter 3101 outbound [Eudemon] firewall interzone untrust dmz [Eudemon-Interzone-untrust-dmz] packet-filter 3102 inbound

三行配置对应三个方向的过滤策略：Trust 到 Untrust 的流量匹配 3101，Trust 到 DMZ 的流量也匹配 3101，Untrust 到 DMZ 的流量匹配 3102。最后一条里的inbound要特别注意——它指的是从 Untrust 区域进入 DMZ 的方向，即外网主动访问 DMZ 服务器时，包过滤规则看的是inbound方向的 3102。

这个inbound/outbound的语义，是华为防火墙配置里最容易让人崩溃的地方。我的判断习惯是：把自己想象成数据包，站在防火墙内部看，从当前区域往外走的叫 outbound，从对面区域往当前区域来的叫 inbound。配错了最直观的现象就是该通的不通，不该通的反而通了。

5.3 避坑记录：四个高频问题

坑一：接口名拼写错误，命令直接报错。现象：interface ethernet 1/0/0敲进去，系统提示Error: Unrecognized command，换了 0/0/0 又正常，以为是接口坏了。原因：console 下手敲接口名，Ethernet拼成了Etherent，或者大小写混用导致系统不识别。解决：先执行display interface brief看系统实际认的接口名，再照着敲，不要凭记忆打。

坑二：基本 ACL 和高级 ACL 混用，匹配逻辑失效。现象：用编号 2010 的 ACL 想限制内网访问 DMZ 的 FTP 端口，配置能敲进去，但包过滤不生效，所有内网访问都被放行或者全部被拒。原因：基本 ACL 只能匹配源地址，根本不看目的端口，你写的端口规则被系统忽略或者直接报错。解决：需要匹配协议和端口时，必须用 3000-3999 的高级 ACL，比如 3101、3102 就是对的编号段。

坑三：packet-filter 方向写反，业务访问异常。现象：按「外网访问 DMZ」的需求配置了 3102 的inbound，结果发现 DMZ 服务器访问外网也被拦截了。原因：把inbound理解成了「对外网进入的流量做过滤」，但实际上 3102 里只放行了 202.12.7.7 到两台服务器的访问，DMZ 服务器发起的外访连接匹配不到 permit 规则，被规则拒绝。解决：先想清楚数据流的起点和终点，再用「站在当前区域看方向」的方式确认inbound/outbound，最后用display packet-filter核对生效位置。

坑四：ACL 里 deny 规则位置太靠前，把正常业务也拦了。现象：3101 规则里写的是rule deny ip在前，rule permit ip在后，结果 Trust 区域内网访问外部网络完全不通。原因：ACL 是顺序匹配的，第一条 deny 把所有流量都拒了，后面的 permit 根本没机会执行。解决：调整规则顺序，permit 写在前面，deny 写在最后。修改时可以用rule编号控制位置，或者删掉重写。

以上四条，前两条是「手误」层面，后两条是「理解」层面。手误靠细心和习惯解决，理解层面靠方向感解决。配完顺手执行display acl 3101看一遍实际生效的规则顺序，能省下大量排障时间。

6. 验证与排障：把「看似通」变成「确认通」

配置做完，进入验证环节。有人觉得 ping 通万事大吉，但防火墙场景下「通」和「确认通」是两码事——不仅要通，还要确认是从哪条策略通的，以及不该通的是不是真的被拦住了。

验证命令集中在三个视图下：查会话用display firewall session table，查 NAT 转换用display nat session，查包过滤规则用display acl和display packet-filter。建议按这个顺序做一轮完整测试：

第二项和第四项看起来像「不通」，但恰恰是策略生效的证据。很多人测试到这里会怀疑自己配置错了，实际上这正是包过滤在做它该做的事。验证时不要只盯着一台机器测，找两台不同区域的主机来回打，效果更直观。

遇到通不了的情况，用debugging ip packet-filter打开包过滤调试信息，能直接看到数据包被哪条规则丢弃，比猜效率高得多。排除完记得用undo debugging ip packet-filter关掉调试，否则日志会被刷爆。从做防火墙项目开始，我养成的习惯是每次改完策略，不管改多小，都强制走一遍这条测试清单——内网出去一包到底，外网进来一条一条验证。这个习惯救过我很多回，配置刷上去看着没问题，实际上漏了一条 ACL 或者方向写反，测试清单一跑就现原形。希望这些经验帮你少走点弯路。

本文还有配套的精品资源，点击获取