干网络这一行越往后越会发现“访问控制”其实是贯穿所有业务的一条主线。不管是刚入行的新人还是带项目的老人手里的工具翻来覆去就是那么几样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包过滤规则列表决定哪些流量允许通过、哪些拒绝三层网关、接口入方向或出方向NAT地址转换内网私网地址与公网地址之间的映射隐藏内部结构出口网关、防火墙AAA认证、授权、计费管理接入者身份、权限和使用记录网络设备管理、远程接入、园区认证GRE通用路由封装建立隧道承载组播、路由协议或异构网络流量设备间隧道接口IPSec加密与认证保证跨网络传输的机密性、完整性、防重放隧道两端网关、业务加密场景从这张表能看出它们并不完全在一个层次。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它让多个内网地址共用同一个公网地址靠不同的源端口来区分会话这也是家用宽带路由器最常见的形态适合大量内网用户访问互联网。用一张表对比会清晰很多类型地址映射关系优点适用场景静态 NAT一对一固定配置简单允许外部主动访问内部服务器映射动态 NAT池内临时分配地址利用率较好中小规模出网NAPT/端口复用多个内网共用一个公网地址最节省公网地址大批用户访问互联网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 80NAT 不是简单的“转换一次就结束”设备会维护一张会话表记录源地址、源端口、目的地址、目的端口、协议以及转换后的信息。后续回程流量靠这张表反向还原所以会话表是 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 Admin123 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.252GRE 的优点是把复杂网络关系简化成一条直连链路但它有两个天生短板不加密也不做真实性验证。攻击者如果抓取到封装后的数据是可以直接看到内层原始流量的。所以 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或者在公网接口上合理设置分片策略。第二个是中间路径如果还存在 NATESP 报文可能会被改写导致哈希校验失败。要启用 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 典型故障速查表现象可能原因排查方向内网能 ping 通但业务端口不通ACL 只放行了 ICMP没放行 TCP/UDP 端口查看 ACL 命中计数补充对应服务规则出网上网时好时坏NAT 地址池耗尽或端口老化时间过长查看会话表检查公网地址池使用率外部端口映射不通内网服务器的网关配置错误或 ALG 未生效查看端口映射状态测试内网直连访问小包通大包不通MTU 或分片问题导致的 IPSec 报文丢失调整 MTU查看丢包点IPSec 隧道建立失败IKE 参数不一致、预共享密钥错误、对端不可达查看阶段一和阶段二协商状态核对算法与密钥SSH 登录设备失败AAA 认证方案配置错误、RADIUS 服务器不通检查认证方案绑定、服务器连通性、本地逃生账号加密隧道建立了但业务没走隧道路由指向错误或 NAT 把隧道流量改写检查路由表确认 NAT 的 ACL 范围这张表是我做排错时经常对照的版本。它不是标准答案更像是一张检查清单好处是能帮你在大脑短路时快速锁定方向。日常维护里还有一个习惯值得养成把设备上那些查看状态的命令集中抄成一张速查卡。ACL 看命中NAT 看会话IPSec 看安全联盟AAA 看认证失败日志。每类技术的关键状态就那一两条命令看懂了它们大部分问题都能在五分钟内定位到大致范围。6.4 一点实操建议说实话这五种技术单独拿出来都不算难难的是组合在一起之后一条流量到底经历了什么。我个人建议学习时不要一上来就找复杂的拓扑先把最简单的两个站点用一台公共网络模拟器跑通再做叠加。你可以先只配 ACL观察放行和拒绝的区别再加 NAT看地址变化然后加 GRE看隧道能不能把路由协议带过去最后加 IPSec看加密前后抓包结果有什么不同。这个顺序每走一步你都会更清楚地理解后面一个技术到底解决了什么问题。等到配置熟练了再试着把故障注入进去。比如故意改错两端的预共享密钥观察阶段一失败时的报错信息或者故意让 NAT 覆盖了 GRE 流量看隧道起不来有什么现象。这些故障实测带来的记忆比看十遍文档都牢固。