企业官网建设流程全解析

干网络这一行，越往后越会发现“访问控制”其实是贯穿所有业务的一条主线。不管是刚入行的新人，还是带项目的老人，手里的工具翻来覆去就是那么几样：ACL 管放行，NAT 管地址改写，AAA 管身份和权限，IPSec 和 GRE 管跨区域传输。我在准备某主流网络设备厂商的初级认证时，也经常把这五样东西放在一起复习。别小看这些基础功能，真正写配置的时候，它们往往是连环套在一起的。这篇文章就把我自己在学习、排错中积累的理解整理出来，给同样正准备认证或者刚接项目的朋友做个参考。

1. 先理清一条主线：五种技术其实都围绕“访问控制”

1.1 一次正常访问，中间到底经历了什么

很多人背命令的时候觉得每一章都懂，一遇到综合故障就懵，原因在于没有把“数据包经过一台设备时到底会被谁处理”这个问题想清楚。举个例子：你在办公区访问数据中心的一台服务器，源地址可能是 192.168.1.10，目的地址可能是 172.16.0.10。数据包从你的电脑出发，先后经过接入交换机、汇聚交换机、出口路由器，最远可能还要穿过中间互联网络才到服务器。

这一路上有哪些检查点？接入交换机可能用 ACL 限制过哪些 VLAN 可以互访；出口路由器上可能配置了 NAT，把你私网地址转换成公网地址；设备自身的管理接口上可能开了 AAA 认证，运维人员登录时要验证身份；如果分支和总部之间要通过加密隧道传输业务，那还要涉及 GRE、IPSec 以及和它们配套的感兴趣流量识别。所以所谓“访问控制”并不是某一个功能，而是一整套规则：谁来、从哪里来、带什么协议、想去哪里、允不允许、要不要做地址改写、还要不要记录一次访问的日志。

理解这个流程之后，你再去看那五类技术，就会发现它们像是流水线上的不同工序。ACL 负责“决定能不能过”，NAT 负责“改头换面”，AAA 负责“确认你是谁、能做什么”，GRE 负责“把业务包装进另一个信封”，IPSec 负责“给信封加锁和封条”。一个完整的企业网络方案，经常是这几种技术按顺序配合出现的。

1.2 一张表盘点五种技术的分工

从这张表能看出，它们并不完全在一个层次。ACL 和 AAA 更像是“策略控制面”，NAT 是“地址转换面”，GRE 和 IPSec 是“承载与加密面”。把它们放在同一门课里学，是因为实际项目中几乎一定会组合使用。比如分支互访既要跑 OSPF，又要求数据加密，那就得先建 GRE 隧道让路由协议跑起来，再用 IPSec 保护隧道里封装后的流量；而 IPSec 识别哪些流量需要保护，恰恰又是由 ACL 来圈定的。

1.3 自己学习和梳理的建议

我不太建议背命令，背了也进不了脑子。你可以拿一张白纸，画一条从内网用户到外部服务器的水平线，然后在每个设备的位置标上可能经过的技术，比如“ACL 在接口上会遇到”“NAT 在出口会转换”“回程流量会走会话表”。这张图画完，各技术之间的先后顺序就出来了。之后再用模拟器搭一个小网络，把这张图实现一遍，比单纯看文档有用得多。

2. ACL：最基础也最容易翻车的访问控制

2.1 一条规则有三个核心

ACL 全称是访问控制列表，本质上就是一个由若干条匹配规则组成的列表。每一条规则里主要有三部分：匹配条件、动作、规则编号。匹配条件常见的是五元组，也就是源 IP、目的 IP、协议类型、源端口、目的端口；动作就是 permit 或 deny；规则编号决定了匹配顺序，设备会从编号小的规则开始查，找到第一条匹配的规则就执行对应动作，后续规则不再检查。

这里面有一个特别关键的隐藏规则：各种 ACL 末尾都带一条隐式拒绝，即所有没被显式允许的流量默认都会被丢掉。这意味着你把 ACL 应用到接口之后，如果没有写允许规则，业务就会直接断掉。很多初学者第一次配 ACL 时先把“拒绝”写上去，然后发现全网不通，就是这个原因。

通配符掩码也是新手容易绕晕的地方。它有别于子网掩码，0 表示必须严格匹配的位，1 表示不关心的位。比如 192.0.2.0 0.0.0.255，表示匹配 192.0.2.0 网段内所有地址；而 192.0.2.1 0.0.0.0 表示只匹配这个具体地址。想不清楚的时候，就先写子网掩码的反码，再用两个地址做一次与运算验证。

2.2 基本 ACL 与高级 ACL 怎么选

多数设备上 ACL 会分成基本、高级和二层等类型。基本 ACL 一般只匹配源地址，适合用来按网段做粗粒度限制，比如禁止某个测试网段访问公司内部网络。高级 ACL 可以匹配源地址、目的地址、协议、端口，适合精确控制服务，比如只允许研发网段访问服务器的 80 端口，其余访问全部拒绝。

选择的基本原则是：能精确到服务就用高级 ACL，只做网段隔离就用基本 ACL。不要为了“看起来专业”动不动就上高级 ACL，规则一多，匹配顺序和排错成本都会上涨。

下面是一个高级 ACL 配置示例，目的就是允许 192.0.2.0/24 网段访问服务器 198.51.100.10 的 HTTP 服务，拒绝其他来源访问该服务器：

acl number 3000 rule 5 permit tcp source 192.0.2.0 0.0.0.255 destination 198.51.100.10 0.0.0.0 destination-port eq 80 rule 10 deny ip source any destination 198.51.100.10 0.0.0.0

然后把 ACL 应用在服务器网关设备的接口上：

interface GigabitEthernet0/0/1 traffic-filter inbound acl 3000

这里要注意方向。所谓 inbound 和 outbound，是以设备接口为参照物的：数据包进入这个接口时匹配 inbound，离开这个接口时匹配 outbound。在配置前先问自己一句：我想让这个 ACL 在流量进来的那一刻拦，还是在流量要出去的那一刻拦？方向错了，ACL 基本等于没配。

2.3 ACL 的匹配顺序和隐含规则

规则编号越大越晚匹配，所以不要随手乱编。建议按 5、10、15 这种方式留出插入空隙。以后在中间插规则时，不需要重排所有编号。

还需要注意一点：如果 ACL 里有 deny 规则，也有 permit 规则，二者无所谓谁在前，关键看编号。但人的阅读习惯往往会把“明确拒绝”放在最显眼的位置，这容易造成安全风险。比如你要允许业务网段访问某个端口，又不想让测试网段访问同一端口，正确做法是先把测试网段拒绝。

我在项目里遇到过一种情况，就是 ACL 规则看着没问题，但业务还是不通。排查到最后发现，ICMP 流量被放行了，而真正需要访问的 TCP 端口没有放行。因为很多人习惯先用 ping 验证网络通，再开业务验证应用，结果测试时发现 ping 通就以为是通的。所以配置 ACL 时要特别注意：放行 ICMP 不等于放行业务端口。

2.4 ACL 排错心得

ACL 排错第一步不是猜，而是看命中计数。设备上可以用查看 ACL 统计信息的方式，看每条规则下面有没有计数增长。如果拒绝规则的计数在涨，说明流量确实被匹配到了，那问题很可能不在 ACL 本身，而在后续的 NAT 或路由。如果所有规则计数都是零，那就要检查 ACL 有没有应用错接口，或者流量走的路径根本不是这个设备。

另外，很多厂商设备默认会在接口上应用 ACL 后立即生效，并且不会提醒你“这会导致断网”。我的习惯是先在模拟器上模拟，或者在业务低峰期配置，并且配置前把现有管理通道比如 SSH 的网段先放行进去，防止把自己锁在外面。

3. NAT：地址转换里藏着安全收敛逻辑

3.1 NAT 不只是为了省地址

NAT 很容易被理解成“私网地址转公网地址”，但实际项目里它承担的职责比这个要宽。IPv4 地址资源确实有限，企业内部大量使用 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 这类私有地址，这些地址无法在公网上路由，必须通过 NAT 在出口设备上转换，这是最直观的需求。

但 NAT 还有一个常被忽略的作用：把内部网络结构隐藏起来。外部看到的是一个出口公网地址，内部具体有哪些主机、哪些服务，并不直接暴露。这种“收敛”效果让攻击者在信息收集阶段就多了一层障碍。当然，NAT 不是防火墙，它不管流量是否恶意，它只负责改写地址。

用日常的例子来类比，很多企业办公楼前台有一部总机电话，内部员工分机号各不相同，但对外只公布总机号码。外部打进来，由前台转接，内部打出去，显示号码也都是总机。NAT 干的事就跟这部总机差不多，它让一大批内网用户共享少量公网资源，同时对外保持统一形象。

3.2 三种常见 NAT 形态

常见的有三类。静态 NAT 是一对一固定转换，适合对外提供服务器的场景，比如把公网地址 203.0.113.10 固定映射给内网服务器 10.0.0.10。动态 NAT 是从地址池里临时分配一个公网地址给内网用户，适合公网地址比内网用户多但不常变化的场景。端口复用 NAT 也常被称为 NAPT 或 Easy IP，它让多个内网地址共用同一个公网地址，靠不同的源端口来区分会话，这也是家用宽带路由器最常见的形态，适合大量内网用户访问互联网。

用一张表对比会清晰很多：

3.3 配置示例与 ACL 配合

出方向 NAT 通常会和 ACL 一起用。ACL 负责圈定哪些网段的流量需要做转换，NAT 再对这个集合执行地址转换。比如公司内网有办公网段和管理网段，办公网段上互联网，管理网段不允许直接上网，那 ACL 里就只放办公网段。

acl number 2000 rule 5 permit source 192.0.2.0 0.0.0.255 interface GigabitEthernet0/0/0 ip address 203.0.113.1 255.255.255.0 nat outbound 2000

入方向的端口映射同样常见。比如把公网地址的 8080 端口映射到内网 10.0.0.10 的 80 端口：

interface GigabitEthernet0/0/0 nat server protocol tcp global 203.0.113.1 8080 inside 10.0.0.10 80

NAT 不是简单的“转换一次就结束”，设备会维护一张会话表，记录源地址、源端口、目的地址、目的端口、协议以及转换后的信息。后续回程流量靠这张表反向还原，所以会话表是 NAT 排错的核心。

3.4 NAT 的坑

常见坑第一个是地址池耗尽。如果你看到内网用户间歇性访问不了外网，多半是 NAT 地址池或者端口资源耗尽。查看会话表后，能看到大量 ESTABLISHED 状态的老会话占用资源，可以适当缩短老化时间，或者增加公网地址池。

第二个坑是回流问题。内网用户想通过公网地址访问内部服务器时，很多设备默认不处理这种流量。因为请求从内网进入，源地址是私网地址，目的地址是公网地址，需要额外的 NAT 规则和路由配合。我一般会让内网用户直接用服务器内网地址访问，避免折腾。

第三个坑是部分协议需要额外的应用层网关支持。比如传统 FTP 在 TCP 21 控制端口协商数据端口，NAT 如果不理解 FTP 协议，就会导致数据连接建立失败。SIP 语音、H.323 视频等也存在类似问题。遇到“端口映射做了但业务还是不通”，先想想是不是应用层协议需要 ALG 辅助。

不要把 NAT 当成防火墙。它能隐藏内部地址，但不会检查应用层内容，也不会主动拦截攻击流量。安全策略还是要靠 ACL、防火墙规则和 AAA 这些机制来共同完成。

4. AAA：把“谁能进来”从口令升级为统一策略

4.1 AAA 到底拆成哪三件事

AAA 是三个词的缩写：Authentication（认证）、Authorization（授权）、Accounting（计费）。很多人在认证这一环上反复纠结，却忽略授权和计费，这是不对的。认证回答“你是谁”，授权回答“你能干什么”，计费回答“你干了什么、干了多久”。真正管理严格的网络环境里，这三个环节缺一不可。

比如一台核心交换机，不是所有工程师都能登上最高权限。认证阶段确认你是合法账号，授权阶段决定你是只读级别还是管理级别，计费阶段记录你什么时候登录、执行了什么操作。这样一旦出问题，可以回溯。

本地 AAA 就是设备自己维护用户名密码，适合管理规模小、就三五个人维护几台设备的场景。规模大了之后，账号分散在各台设备上会非常痛苦，改一次密码要登录所有设备，所以要用远程认证服务器。设备把认证请求发给服务器，服务器返回通过或拒绝，这个过程会用到 RADIUS 或 TACACS+ 这类协议。RADIUS 把认证和授权合并在一起报文里，实现简单；TACACS+ 把三者分离，安全性和灵活度更高，但协议生态相对小众。

4.2 本地 AAA 配置示例

一个常见配置思路是：先建立本地用户，再配置认证方案，指定使用本地认证，然后把这个方案绑定到登录域，最后让远程登录相关接口走 AAA 认证。

aaa authentication-scheme login_auth authentication-mode local domain default authentication-scheme login_auth local-user admin password irreversible-cipher Admin@123 local-user admin privilege level 15 local-user admin service-type terminal telnet ssh http

然后在线路 vty 上启用认证方式：

user-interface vty 0 4 authentication-mode aaa protocol inbound ssh

这里有一个非常重要的细节：如果不小心把 AAA 和远程登录配置弄坏，你可能会彻底失去这台设备的远程管理能力。所以强烈建议保留一个本地逃生账号，放在本地认证库里，并且这个账号不要受到远程认证方案影响。简单说，认证方案里可以把本地认证放在后备位置，一旦 RADIUS 服务器不可达，仍然允许本地账号登录。

4.3 对接 RADIUS 服务器时的关键参数

对接远程认证服务器时，常见参数包括服务器地址、端口、共享密钥、源接口或源地址。配置完成后一定要做一次测试，看设备能否和服务器通信。很多时候故障就出在共享密钥两边不一致，而不是认证逻辑有问题。

授权环节里，服务器可以下发用户级别和 ACL 编号。比如运维 A 登录设备后只能执行查看命令，运维 B 可以进入全局配置模式，这些可以通过服务器返回的属性实现。这样账号权限统一管理，不需要在每台设备上重复配置。

计费环节容易被忽视。它解决的问题是“出了事能不能查”。有些合规比较严格的项目，要求管理员每次登录和操作记录都留痕。此时计费服务器会收到设备发来的开始计费、结束计费报文，里面包含用户名、来源地址、登录时间、登出时间等信息。虽然配置成本不高，但对审计帮助很大。

我之前遇到过一个问题，远端 AAA 配置好后，某个账号总是登录失败，但在服务器上测试密码又是对的。最后查下来发现是设备端配置的域和服务器下发的域不一致，认证请求被路由到不存在的域里。所以做 AAA 排错时，先确认用户名格式里带的域名、设备上创建的域、服务器配置的域三者完全一致。

5. IPSec 和 GRE：跨区域传输该怎么保护

5.1 GRE 先把“通”的问题解决

GRE 是一种非常朴素的隧道封装技术。它做的事情不复杂：把原始报文整个包裹起来，外面再加上一个 GRE 头和一个新的 IP 头，然后在传输网络中按普通 IP 包转发。由于原始报文被完整封装，GRE 可以承载很多普通 IP 路由不好处理的东西，比如组播广播流量、某些非 IP 协议，以及我们最常用的场景：在分支和总部之间传递 OSPF 等动态路由协议。

举个例子，两个异地站点各自有一台网关设备，它们之间没有专线，只有公共网络。如果想让两边内网网段通过 OSPF 自动学习路由，直接跑是走不通的，因为 OSPF 的组播报文在公网上不一定受支持。此时可以在两台网关之间建一条 GRE 隧道，把 OSPF 报文封装进普通的单播 IP 包里，看起来就像是两台网关直连了一条虚拟网线。

interface Tunnel0/0/1 tunnel-protocol gre source 203.0.113.1 destination 203.0.113.2 ip address 10.255.0.1 255.255.255.252

GRE 的优点是把复杂网络关系简化成一条直连链路，但它有两个天生短板：不加密，也不做真实性验证。攻击者如果抓取到封装后的数据，是可以直接看到内层原始流量的。所以 GRE 通常只解决“通不通”，不解决“安不安全”。

5.2 IPSec 负责“安不安全”

IPSec 的目标是给 IP 层通信提供三样东西：机密性、完整性、真实性校验，顺带还能做防重放保护。机密性靠加密算法对数据加密；完整性靠摘要算法验证数据有没有被篡改；真实性靠认证密钥保证通信双方确实是对方。这样一来，即便数据在传输途中被截获，也无法看到明文内容，更无法伪造合法报文。

IPSec 有两种承载协议：AH 只做认证，不做加密，现在用得越来越少；ESP 既能加密又能认证，是实际部署中的主流选择。模式上又分传输模式和隧道模式：传输模式只保护 IP 载荷部分，适合主机与网关之间；隧道模式会把整个原始 IP 包封装起来再加密，适合网关到网关之间。跨区域站点互联几乎都是用隧道模式。

IPSec 的协商过程常被叫做 IKE。第一阶段先在两端建立一条受保护的协商通道，完成对端身份确认和密钥材料交换；第二阶段再在这条协商通道上快速建立用于保护业务流量的安全联盟。我刚开始学的时候总觉得这两个阶段很容易混。简单理解就是：阶段一是双方先互相验明正身，谈好用什么加密方式来保护后面的对话；阶段二是用这个安全通道正式商定，具体业务数据该用什么算法、什么密钥来保护。

下面是一个典型的 IPSec 策略配置骨架：

acl number 3000 rule 5 permit gre source 203.0.113.1 0.0.0.0 destination 203.0.113.2 0.0.0.0 ike proposal 1 encryption-algorithm aes-256 dh group14 authentication-method pre-share integrity-algorithm hmac-sha256 ipsec proposal p1 esp authentication-algorithm sha2-256 esp encryption-algorithm aes-256 ipsec policy policy1 10 isakmp security acl 3000 ike-proposal 1 ipsec-proposal p1

配置里那段 ACL 有个专门叫法，叫“感兴趣流量”。它不是在拦截流量，而是告诉 IPSec：只有匹配到这些规则的流量，才值得为它建立安全联盟并加密。如果感兴趣流量定义过宽，会把不必要的数据也拉进隧道；定义过窄，则业务流量根本不会被加密保护。每次说 IPSec 之前我都建议大家先把这一段 ACL 看明白，因为它把 ACL、IPSec 和实际业务串在了一起。

5.3 GRE over IPSec：为什么把两者放在一起

单独看 GRE 和 IPSec，各自都有明显的局限。GRE 能跑组播、能跑动态路由协议，但不安全；IPSec 能加密认证，但对组播、动态路由的支持很差。于是实际项目中出现了“GRE over IPSec”的组合：先建 GRE 隧道，让所有需要互通的网段通过 GRE 形成逻辑直连，让动态路由协议可以通过隧道工作；再用 IPSec 保护这段 GRE 流量，让封装后的报文加密传输。

配置顺序和逻辑并不复杂。第一步把 GRE 隧道建立起来，隧道源和隧道目的用两端的公网地址；第二步在 GRE 上配置隧道 IP 地址；第三步用 ACL 把 GRE 协议流量定义为感兴趣流量；第四步对接 IPSec 策略。因为 IPSec 保护的是 GRE 隧道封装后的流量，所以报文外层是 GRE，再外层才是 IPSec 加密头。

操作中有几个比较隐蔽的坑。第一个是 MTU。隧道加上 GRE 头和 IPSec 头之后，报文总长度会变大，容易超出链路 MTU 导致分片丢失。现象就是“小包通、大包不通”，比如 ping 带小包正常，传文件就卡。应对办法是调整隧道接口 MTU，或者在公网接口上合理设置分片策略。第二个是中间路径如果还存在 NAT，ESP 报文可能会被改写，导致哈希校验失败。要启用 NAT-T，让 IPSec 报文先封装成 UDP 再传输。第三个是两端的 IKE 参数必须一致，很多隧道起不来就是因为两端加密算法选得不一样。

这套组合本质上是企业站点间做安全互联的通用思路，但并不是所有场景都需要。如果只是传输不敏感数据的普通业务，用 GRE 就够了；如果希望更贴近应用层做精细化控制，成熟产品里还有更新一代的加密技术可选。知道 GRE over IPSec 存在，并知道它解决了什么问题，比单纯背配置命令重要得多。

6. 综合小案例：把五种技术串在一个分支互联场景里

6.1 场景说明与目标

先假设一个非常典型的场景。某公司在总部和分支各有一台出口网关，总部内网网段是 192.0.2.0/24，分支内网网段是 198.51.100.0/24，两边通过公共网络互联，没有专线。分支有一台财务系统服务器 198.51.100.10，总部财务部门网段 192.0.2.0/24 需要访问它，其他总部网段不能访问。同时，总部和分支的出口网关之间希望跑一段加密隧道，让财务系统和办公系统的通信都不裸奔。运维人员平时通过 SSH 登录两台网关，登录方式统一走 AAA 认证。

这个场景几乎是五种技术的全家桶：ACL 控制谁可以访问财务服务器，NAT 负责总部网段出网，AAA 统一管理运维登录，GRE 承载跨越公共网络的路由，IPSec 把所有封装后的业务流量加密起来。目标很明确：该通的通，不该通的拒绝，所有远程管理有据可查，所有敏感数据不能被中间人窃听。

6.2 配置顺序建议与分步验证

我自己的建议是分五步走，每步完成一个小验证再继续。

第一步先把底层物理链路调通，确认总部和分支的公网地址都能互相 ping 通。这一步如果都不通，后面所有隧道都是空中楼阁。第二步配置 GRE 隧道和隧道间静态路由，验证隧道接口能起来，并且通过隧道能 ping 通对端隧道 IP。第三步配置 OSPF 或者其他动态路由，让总部和分支内网网段出现在彼此路由表里。第四步在 GRE 之上叠加 IPSec，定义感兴趣流量，验证安全联盟建立成功。第五步再回到业务侧，配置 ACL 和 NAT，注意让需要进隧道的流量不要被 NAT 改写，然后配置 AAA 开启远程认证。

每一步都有对应的验证命令。GRE 隧道起来没有，看隧道接口状态和安全联盟是否建立；NAT 是否生效，看会话表和地址转换记录；AAA 登录是否正常，直接开一个 SSH 会话试一次。用这种顺序来实施，一旦出问题，范围会被控制得很小，不会出现“全都不通但不知道谁的问题”这种局面。

特别提醒一点：NAT 和 IPSec 是冲突高发区。如果总部网段的流量在进入 GRE 隧道之前被 NAT 把源地址改写了，对端收到报文后回程地址就对不上，IPSec 的感兴趣流量也可能匹配失败。所以在同时使用 NAT 和 IPSec 的场景里，通常需要让去往隧道对端网段的流量绕过 NAT。这就是项目里经常说的“聪明流量别乱转”，操作本质是调整 NAT 的 ACL 匹配范围。

6.3 典型故障速查表

这张表是我做排错时经常对照的版本。它不是标准答案，更像是一张检查清单，好处是能帮你在大脑短路时快速锁定方向。

日常维护里还有一个习惯值得养成：把设备上那些查看状态的命令集中抄成一张速查卡。ACL 看命中，NAT 看会话，IPSec 看安全联盟，AAA 看认证失败日志。每类技术的关键状态就那一两条命令，看懂了它们，大部分问题都能在五分钟内定位到大致范围。

6.4 一点实操建议

说实话，这五种技术单独拿出来都不算难，难的是组合在一起之后，一条流量到底经历了什么。我个人建议学习时不要一上来就找复杂的拓扑，先把最简单的两个站点用一台公共网络模拟器跑通，再做叠加。你可以先只配 ACL，观察放行和拒绝的区别；再加 NAT，看地址变化；然后加 GRE，看隧道能不能把路由协议带过去；最后加 IPSec，看加密前后抓包结果有什么不同。这个顺序每走一步，你都会更清楚地理解后面一个技术到底解决了什么问题。

等到配置熟练了，再试着把故障注入进去。比如故意改错两端的预共享密钥，观察阶段一失败时的报错信息；或者故意让 NAT 覆盖了 GRE 流量，看隧道起不来有什么现象。这些故障实测带来的记忆，比看十遍文档都牢固。