做边界防护的同行大多遇到过这种尴尬手上一台中低端路由式设备功能表里既没有像样的区域防火墙模块也没预算上专门的策略平台但业务方要求很明确——外面不能随便进来里面出去要留痕、要能追溯。这种时候 CBAC 和认证代理这两个老功能往往能救场。CBACContext-Based Access Control基于上下文的访问控制解决的是单向放行和状态跟踪的问题认证代理Authentication Proxy解决的是谁能出网、出网前先证明自己是谁的问题。两个东西单独看都不算强但组合起来能在一台普通设备上拼出一套够用的边界访问控制。这篇就把这两项技术的机制、坑点和实操配置拆开讲清楚适合手上有存量设备要加固、又不想大改网络架构的朋友参考也适合想搞明白状态化过滤到底怎么工作的新手打底。1. 先把概念摆正CBAC 与认证代理各自站什么位置1.1 从无状态 ACL 的三块短板说起传统扩展 ACL 的判断依据是五元组源地址、目的地址、协议、源端口、目的端口。设备收到一个包查表、匹配、放行或丢弃结束。它不记得上一个包也不知道这个包是不是某个会话的一部分。这个特性带来三个直接后果。第一个后果是入向必须写得很宽。内部终端访问外网 Web 服务出去的包源端口是随机的 5 万开外的高位端口目的端口 80。回程包的源端口变成 80目的端口是那个随机高位。如果只写permit tcp any any eq 80回程包根本匹配不上因为它的目的端口不是 80。于是很多人图省事写成permit tcp any any established靠 TCP 头里的 ACK/RST 标志位来判断。这个写法的问题在于任何人手工构造一个带 ACK 标志的包就能穿过等于把门锁换成了一块布。第二个后果是多通道协议必然残废。FTP 主动模式、H.323、SIP 这类协议控制信道里协商出来的数据端口是随机的ACL 事先根本不知道要开哪个口。你只能预先开一大段端口范围安全管理瞬间形同虚设。第三个后果是审计断档。无状态 ACL 只能告诉你这条规则放行过多少字节说不出谁在什么时间访问了什么。真出事要回溯什么都拿不出来。CBAC 就是针对这三点设计的。它在设备内部维护一张会话表出向流量经过时把五元组记下来回程包到来时比对会话表命中就放行并刷新计时器。表里没有的、或者状态不对的一律丢。这套机制让入向 ACL 可以被收紧到极致——只留真正需要对外开放的那几条剩下的全部靠动态打开。1.2 CBAC 的状态化检测到底是什么很多人把 CBAC 简单理解成会记会话的 ACL这个说法对了一半。CBAC 的核心竞争力在应用层检测Application Inspection也就是它不只记五元组还会往 TCP 载荷里看一眼。以 FTP 为例。主动模式下客户端说PORT 10.10.10.20,200,100意思是你来连我的 51200 端口。CBAC 的 FTP 检测模块解析这条命令把10.10.10.20:51200这个组合记进会话表当服务端确实从 20 端口发起连接时设备认得出这是刚才那次协商的结果于是放行。被动模式同理会解析227 Entering Passive Mode的回应内容。整个过程对用户完全无感ACL 里也不需要预先开一堆高位端口。这里有个关键认知CBAC 的上下文二字指的就是这种跨包、跨协议的关联信息。它维护的不只是连接状态还有协议内部的协商上下文。这也解释了为什么 CBAC 只能覆盖它认识的那批协议——不认识的应用它只能按 TCP/UDP 的通用方式处理多通道协商部分就帮不上忙了。设备上常见的检测规则大致分几类通用传输层tcp、udp、icmp、基础应用http、ftp、smtp、esmtp、dns、tftp、rpc、sqlnet、多媒体类h323、sip、rtsp、skinny、mgcp、realaudio、vdolive、streamworks、远程访问类rcmd、netshow。选哪些挂上去取决于内网实际跑什么业务这一点后面细讲。注意CBAC 只做单向检测也就是只在流量进入设备的那个接口方向上挂规则。很多新手在内外两个接口各挂一条规则结果会话表被重复记录性能掉一半还查不出原因。1.3 认证代理不是防火墙它是通行条的发放机先把名词澄清本文里的认证代理专指设备上的 Authentication Proxy 这一个功能模块跟其他语境下的代理没有任何关系。它的职责边界很窄——在用户访问网络之前先截获他的 HTTP 请求逼他做一次身份认证认证通过后自动下发一条临时 ACL 给他放行。流程可以这么理解。没有身份证的人走到闸机前闸机不开但会弹出一个登记窗口。你在窗口里填账号密码后台去 AAA 服务器核验核验通过闸机给你发一张有时效的临时卡卡到期自动作废。整个过程里闸机本身不判断你是谁判断的是后台。这套机制的价值在于把网络访问权和身份绑在了一起。传统做法是按 IP 段划分权限某个网段能访问什么、不能访问什么写死在 ACL 里。问题是 IP 不认人同一台笔记本换个人用、换个位置插网线权限就跟着变了。认证代理把放行依据从你从哪来换成你是谁这是质的差别。但也别高估它。认证代理的三个天然限制必须清楚只能拦 HTTP用户不开浏览器就永远触发不了认证依赖 AAA 服务器可用服务器挂了等于谁都上不去下发的是 ACL粒度到端口和地址为止做不到应用层识别。所以它适合做准入门槛不适合做精细管控。2. 方案选型什么场景下这两项技术才值得上2.1 三类真正合适的落点第一类分支机构的出口设备加固。分支规模不大几十到一两百人一台设备既要路由又要做边界。上专门的防火墙平台成本不划算但直接把内网暴露出去又过不了安全评审。这种情况把 CBAC 挂上入向 ACL 收成白名单出向靠状态检测放行是性价比最高的做法。第二类访客网络与办公网络共用出口。访客要上网但不能碰内网。按 IP 段硬切又太死板访客换个房间、换台设备 IP 就变了。这时候用认证代理做一层准入访客拿到账号才能出去认证后下发的 ACL 里只放通公网地址内网段全部拒绝管理上清爽很多。第三类临时人员、外包团队的限时接入。这类需求的特点是短期、可控、要留痕。认证代理的 auth-cache-time 加上 AAA 侧的计费记录正好能满足什么时候来的、用了多久、访问了什么的追溯要求。比起专门拉一条隔离线路成本差着数量级。反过来说有三种情况不建议硬上一是内网跑着大量 CBAC 不认识的私有协议尤其是自研的多通道协议检测帮不上忙还占资源二是并发会话数超过设备会话表上限的勉强开起来只会频繁丢包三是对加密流量占比极高的环境CBAC 看不到载荷应用层检测等于白搭不如直接上七层设备。2.2 与几种常见替代方案的横向对比对比维度CBAC反射 ACL区域防火墙专用策略平台状态跟踪完整会话表仅 TCP 反向条目完整状态机完整状态机应用层检测支持常见协议不支持支持较广支持最广多通道协议FTP/H.323/SIP 等可处理需手工预开端口可处理可处理配置复杂度中命令分散低中高高资源开销中会话表占内存低中高适用设备档次中低端可用低端可用中高端独立硬件典型短板协议覆盖有限无应用层能力授权成本部署周期长这张表想说明的核心是CBAC 的定位在反射 ACL和区域防火墙之间。它比反射 ACL 多了应用层能力比区域防火墙少了策略模型和可视化。选它不是为了追求功能全而是为了在现有设备、现有预算的前提下把安全性从几乎裸奔拉到及格线以上。2.3 上线前必须先确认的四个硬约束约束一硬件平台是否支持。不是所有设备都带这项功能尤其是低端型号或者精简版系统镜像。敲ip inspect ?看有没有回显是最快的判断方法。约束二会话表内存余量。每条会话记录在内存里占约 160 到 200 字节不同版本有差异按经验估算即可。假设内网 500 人人均 30 条并发会话就是 15000 条占 3MB 左右。听起来不多但别忘了设备还要跑路由表、NAT 表、ARP 表。上线前用show memory看一眼剩余量留出至少 30% 的余量比较稳妥。约束三NAT 与检测的处理顺序。这是最容易翻车的地方。调试动态条目时一定要用show ip inspect sessions之类的命令确认里面记的地址是转换前还是转换后。如果 ACL 里写的是转换前地址而会话表里是转换后地址两边对不上就会莫名其妙丢包。约束四AAA 服务器的可达性与备份路径。认证代理没有 AAA 就是一堆废命令。上线前必须配置local作为兜底认证方式并实测一遍服务器断开的情况下本地账号能不能登进去。这条不做好出故障的时候你连设备都进不去。3. CBAC 核心机制拆解与配置落地3.1 检测规则、ACL、接口三者的配合关系CBAC 的配置逻辑可以浓缩成一句话规则在接口上挂一边ACL 在接口上挂另一边。具体来说内部接口的入方向挂ip inspect 规则名 in负责记录出向会话外部接口的入方向挂一条扩展 ACL负责拦掉所有非期望流量。当内部主机发起连接包先经过内部接口被检测规则捕获记入会话表然后转发出去。回程包到达外部接口先过 ACL——ACL 里当然没有这条放行条目包本来会被丢——但设备在查 ACL 之前会先查会话表发现这条属于已建立的会话于是动态插入一条临时放行条目包顺利通过。这个顺序解释了为什么外部接口的 ACL 可以写成默认拒绝。也解释了一个常见误区不要在外部接口的入向 ACL 里给回程流量单独写放行条目。写了不但浪费规则还会让动态条目的作用被掩盖出问题的时候很难判断到底是静态规则放行的还是状态检测放行的。另外一个细节是检测规则挂在接口的in方向指的是从该接口进入设备的流量。所以内部接口挂in外部接口不需要挂ip inspect ... in。这个方向搞反了会话表里什么都看不到。3.2 一份可直接抄的配置模板以下语法为通用形式不同版本的命令字可能略有差异下发前先用帮助命令确认一遍再执行。! 第一步定义检测规则集按业务实际需要挂协议 ip inspect name CBAC_OUT tcp ip inspect name CBAC_OUT udp ip inspect name CBAC_OUT icmp ip inspect name CBAC_OUT dns ip inspect name CBAC_OUT http ip inspect name CBAC_OUT ftp ip inspect name CBAC_OUT smtp ip inspect name CBAC_OUT esmtp ip inspect name CBAC_OUT sqlnet ! 第二步内部接口挂检测规则方向为 in interface GigabitEthernet0/0 description Inside ip address 10.10.10.1 255.255.255.0 ip inspect CBAC_OUT in ! 第三步外部接口挂入向 ACL白名单式 interface GigabitEthernet0/1 description Outside ip address 203.0.113.1 255.255.255.0 ip access-group 101 in ! 第四步ACL 内容只放行必须对外开放的服务 access-list 101 permit tcp any host 203.0.113.1 eq 25 access-list 101 permit tcp any host 203.0.113.1 eq 443 access-list 101 deny ip any any log逐段解释。第一步的规则集里tcp和udp是打底项负责通用状态跟踪icmp让内网发起的 ping 能收到回应dns处理域名查询http除了跟踪连接外还带 Java applet 阻断能力ftp负责处理 PORT/PASV 协商smtp和esmtp支持邮件协议里的扩展命令sqlnet是数据库客户端常用的。第二步的ip inspect CBAC_OUT in一行就够不用写out。第三步的 ACL 里我故意只开了 25 和 443 两个口其余全拒。最后那条deny ip any any log很重要——log关键字会在日志里留下被丢弃的包信息这是排查问题的第一手材料也是安全审计的基本盘。不过要注意日志量流量大的时候log会刷屏可以改成log-input或者干脆先不加等稳定运行几天后再决定。3.3 超时参数怎么算、怎么调CBAC 的超时参数决定了会话在会话表里存活多久调得太短业务频繁断调得太长表项堆积。默认值如下表参数默认值命令调优建议TCP 空闲超时3600 秒ip inspect tcp idle-time长连接业务多的调大UDP 空闲超时30 秒ip inspect udp idle-time视频类业务需单独评估DNS 超时5 秒ip inspect dns-timeout一般不用改TCP FIN 等待5 秒ip inspect tcp finwait-time保持默认TCP SYN 等待30 秒ip inspect tcp synwait-time跨广域网可适当调大半开会话上限高水位500ip inspect max-incomplete high按终端数重算半开会话上限低水位400ip inspect max-incomplete low高的 80% 左右半开连接的两个水位值需要重点算一下。所谓半开会话指的是 SYN 发出去了但三次握手没完成的、或者正在等待关闭的连接。高水位是触发丢弃的阈值低水位是恢复接收的阈值两个值之间留出一段缓冲区避免高水位附近反复震荡。假设内网有 300 台终端每台平均同时打开 8 个连接其中约 10% 处于握手阶段那么瞬时半开会话大约是 300 × 8 × 0.1 240 条。默认的高水位 500 看起来够用但如果遇到开机高峰、批量软件同时启动瞬时值可能翻三倍到 700 以上这时候就会触发丢弃表现为部分终端上网断断续续。经验做法是按峰值估算值 × 1.5设高水位低水位取高水位的 80%。上例中高水位设 1050低水位设 840。! 按终端规模调整半开会话阈值 ip inspect max-incomplete high 1050 ip inspect max-incomplete low 840 ! 单主机半开连接限制防单点扫描 ip inspect tcp max-incomplete host 50 block-time 0最后那条block-time 0表示不限时阻断配合host 50意味着单个 IP 超过 50 条半开会话就拒绝新连接。这个值在办公网里设 50 差不多了如果内部有做压力测试的开发同事记得提前给他们的测试机加例外不然会被投诉上不了网。3.4 应用层检测的那些特殊之处HTTP 检测。除了跟踪连接http检测还有个容易被忽略的能力阻断 Java applet。配法是ip inspect name CBAC_OUT http java-list 50然后 ACL 50 里定义允许加载 applet 的源地址。这个功能在十年前很有用现在 Java applet 基本绝迹但如果你接手的是老系统可能还真能用上能挡掉一批通过 applet 载荷绕过 ACL 的老攻击手法。FTP 检测。前面说过它解析 PORT/PASV 命令。这里有个坑如果内网同时有多个客户端访问同一台 FTP 服务器主动模式下服务器会从 20 端口反向连接各个客户端的数据端口CBAC 靠控制会话的关联信息来区分。实测中没有出过问题但如果中间隔了一层 NAT客户端地址被转换了数据通道的地址可能会对不上表现为能登录、能 ls但 get 卡死。这种时候优先检查是不是 NAT 转换点位于检测点之前。多媒体协议。H.323、SIP 这类协议的信令里带 SDP 描述写着 RTP 的收发地址和端口。CBAC 会解析这些内容并预先开洞。麻烦在于某些终端不按规范填地址填了个私有地址或者 0.0.0.0检测模块就懵了。遇到这种设备与其跟它较劲不如把相关终端所在的网段单独划出来用静态 ACL 处理别硬上检测。UDP 的近似会话问题。UDP 无连接CBAC 只能靠五元组加空闲计时器来假装维护会话。默认 30 秒的空闲超时对 DNS、NTP、SNMP 这类短交互完全够用但对长时 UDP 流比如某些视频会议、组播应用就不行了——30 秒一到条目被回收后续的包再来就是新连接回程照样被 ACL 挡住。解决办法是针对特定业务把udp idle-time调大但这是全局参数会影响所有 UDP 应用所以要权衡。更稳妥的做法是对该业务单独定义一条检测规则只挂在相关接口上。4. 认证代理的完整落地流程4.1 三段式认证流程拆开看认证代理的动作可以拆成三个阶段每个阶段对应不同的失败模式理解清楚才能查得动问题。第一阶段是截获。用户浏览器向任意地址发 HTTP 请求设备在入口处发现这个源地址还没有通过认证于是把请求劫持下来返回一个设备自己生成的登录页面。注意这个页面是设备渲染的不是用户想访问的网站。如果用户访问的是 HTTPS截获会失败——因为 TLS 握手在设备看来是一堆加密字节它没法在中间插入登录页。这是认证代理只能拦 HTTP 的根本原因也是实际部署中最大的痛点。第二阶段是核验。用户在页面上填账号密码设备拿着这组凭证去 AAA 服务器可能是 RADIUS 也可能是 TACACS核验或者退回本地用户库核验。核验结果连同用户属性一起返回属性里可能包含这个用户属于哪个组、允许访问什么。第三阶段是放行。核验通过后设备根据 AAA 返回的属性或者本地配置的 ACL 模板生成一条临时 ACL 绑定到该源 IP同时记录一条缓存条目告诉后续流量这个地址已经认证过了别再拦。缓存的存活时间由auth-cache-time控制到期自动删除当然也可以手工清。这套流程有个隐含前提用户的源 IP 在整个会话期间不能变。如果中间有 DHCP 租期到期重新分配、或者有地址转换导致源地址变化认证状态就会丢失用户被要求重新认证体验很差。所以认证代理最好部署在地址相对固定的网段或者配合较长的 DHCP 租期。4.2 AAA 侧与登录页面的准备AAA 配置是整个功能的地基顺序不能乱。先启用 AAA 框架再定义认证和授权的方法列表最后配置服务器。! 启用 AAA aaa new-model ! 认证方法列表先服务器后本地兜底 aaa authentication login default group radius local aaa authentication login CONSOLE local ! 授权方法列表认证代理专用的关键字 aaa authorization auth-proxy default group radius local ! 服务器配置 radius-server host 10.10.10.50 auth-port 1645 acct-port 1646 key 替换成你的密钥 radius-server retransmit 3 radius-server timeout 5这里有两个细节值得说。第一aaa authentication login CONSOLE local这行必须单独定义并应用到控制台线路。因为默认方法列表改成group radius local之后如果 RADIUS 服务器挂了、本地账号又没配控制台登录也会走默认列表容易出现服务器不通、自己也进不去的死锁。单独给控制台定义一个纯本地的方法列表是保命的操作。第二aaa authorization auth-proxy这个关键字是认证代理专属的不要写成aaa authorization network两者作用范围不同写错了功能直接不生效而且不报错特别难查。AAA 返回的属性里最有用的是acl属性和inacl属性——服务器可以直接告诉设备给这个用户下发哪条 ACL。这样权限管理就集中在服务器侧设备配置不用动人员变动时改服务器就行。如果服务器不支持或者不想用也可以在设备本地用ip auth-proxy name关联一个 ACL 模板走本地逻辑。4.3 配置模板与逐行注解! 定义认证代理规则名称 AP_HTTP触发协议 http ip auth-proxy name AP_HTTP http ! 认证缓存时间单位分钟默认 60 ip auth-proxy auth-cache-time 30 ! 空闲超时单位分钟超时后回收动态条目 ip auth-proxy inactivity-timer 60 ! 接口上启用注意只需要在入口接口启用 interface GigabitEthernet0/0 description Inside ip address 10.10.10.1 255.255.255.0 ip auth-proxy AP_HTTP ip access-group 110 in ! ACL 定义需要认证的流量放进来其余拒绝 access-list 110 deny tcp any host 10.10.10.1 eq 80 access-list 110 permit tcp any any eq 80 access-list 110 permit tcp any any eq 443 access-list 110 deny ip any any log解释一下这几行。ip auth-proxy name AP_HTTP http里的http是触发协议意思是看到 HTTP 请求就去检查认证状态。auth-cache-time 30表示认证后 30 分钟内不再重复要求认证这个值太短用户频繁登录太长则权限回收不及时30 分钟是个折中。inactivity-timer 60表示 60 分钟没有流量就回收动态条目适合人员流动性大的场景。ACL 110 里第一条deny tcp any host 10.10.10.1 eq 80是个易被忽略的写法。它的目的是阻止用户访问设备自身的 Web 管理界面。认证代理工作时如果用户能直接打开设备的 Web 页面就有可能绕过认证页面。虽然实际上认证代理一般会先拦截但显式拒绝一次更保险。后面的permit tcp any any eq 80和eq 443是放行需要认证的流量。这里要注意放行的意思是允许流量进入认证流程不是直接放行最终能不能出去取决于认证结果。很多人第一次配的时候看到 permit 就以为通了结果用户还是上不了网其实是被认证流程挡住了这是正常的。4.4 动态条目的生成、继承与回收认证通过之后设备会在内部生成一条 ACL 条目形如permit ip host 10.10.10.20 any绑定到那个源地址上。这条条目不是写在配置里的重启就没了用show ip access-lists能看到但带特殊标记。继承关系上有个细节动态 ACL 会继承触发它的那条 ACL 的位置。也就是说如果 ACL 110 里permit tcp any any eq 80是第 2 条那么认证后生成的动态条目会插在第 2 条附近而不是附在最末尾。这个特性可能导致意料之外的结果——如果中间有 deny 规则夹着动态条目可能被挡住。我的做法是把认证代理相关的 ACL 单独编号别跟其他策略混在一个列表里减少相互干扰。回收有三条路径。一是inactivity-timer到期自动回收二是auth-cache-time到期后重新要求认证但注意这两者不是一回事前者管流量记录后者管认证凭证缓存三是手工清除用clear ip auth-proxy cache或者针对单个地址clear ip auth-proxy cache 10.10.10.20。测试阶段会频繁用到手工清除记熟这条命令能省不少时间。还有一个常见误解认证代理下发的 ACL 和 CBAC 的动态条目是两套东西。前者管谁能访问网络后者管回程流量能不能进来。两者叠加使用时认证通过的用户还要经过 CBAC 的状态检测才能正常通信少一环都不行。4.5 与 CBAC 联动的正确顺序两个功能同时启用时处理顺序是这样的内部接口收到包 → 先匹配ip access-group的静态 ACL → 再过认证代理判断有没有认证 → 认证通过后进入 CBAC 检测记入会话表 → 转发出去。回程包进来 → 外部接口 ACL → CBAC 会话表命中 → 放行。这个顺序决定了两件事。第一认证代理的 ACL 一定要写在 CBAC 检测之前也就是挂在内部接口的ip access-group上如果把认证相关判断放到外部接口回程流量已经被拒绝在门外了。第二认证代理生成的动态 ACL 只影响入向策略不影响 CBAC 的会话记录所以两个功能的超时参数要分别调别指望调一个另一个跟着变。实际配置里我习惯把认证代理放在内部接口CBAC 也挂内部接口两个一起生效interface GigabitEthernet0/0 ip address 10.10.10.1 255.255.255.0 ip access-group 110 in ip inspect CBAC_OUT in ip auth-proxy AP_HTTP三行命令看起来简单但任意一行写错方向整个功能链就断了排查的时候一定先确认这三行都在而且都在同一个接口的in方向。5. 常见问题与排查技巧实录5.1 用户能上网但回程不通先查方向再查顺序这个症状最容易出现在刚配完的时候内部主机 ping 得出去但收不到回应或者 TCP 三次握手只完成了前两步。八成是检测规则挂错了方向或者挂在了错误的接口上。排查顺序我总结成三步。第一步show ip inspect interfaces看规则有没有真正挂上去、挂的是哪个方向。第二步show ip inspect sessions看会话表里有没有记录。如果没有记录说明出向流量根本没被检测到重点查接口方向如果有记录但回程还是被丢那就去看外部接口 ACL 的日志确认丢包原因。第三步show ip inspect statistics看被丢弃的包计数如果这个数字在持续增长说明检测模块在主动丢包多半是半开会话超限或者协议检测失败。有个很隐蔽的坑接口上同时配了ip inspect X in和ip inspect X out。方向写多了不会报错但会话表会出现重复记录性能直接腰斩而且show命令的输出看起来还挺正常。有一次帮人排查一个网速慢但 ping 正常的问题最后发现就是多写了一行out删掉之后恢复正常。5.2 认证页面反复弹缓存和地址变化的连环坑用户在登录页填完账号密码页面跳一下又弹回登录页。这个问题的成因有好几种按出现频率排序。最常见的是auth-cache-time设成了 0 或者特别小的值。有些版本的默认值跟文档不一致配完一定要用show ip auth-proxy config之类的命令确认实际生效值别信文档。第二种是用户地址在变。笔记本从无线切到有线、DHCP 重新拿地址都会导致认证状态丢失。这种没法彻底解决只能优化延长 DHCP 租期、把无线和有线划到同一个网段、或者配置更长的缓存时间。第三种是 AAA 服务器返回的属性不完整。服务器只返回了认证成功没返回授权属性设备不知道该给这个用户下发什么 ACL于是认为认证没完成重新弹页面。排查方法是打开 AAA 调试看返回的属性列表里有没有 acl 相关的字段。调试命令会输出大量日志生产环境慎用必须在维护窗口做。第四种是登录页面的地址不可达。设备弹出的登录页指向自己的某个接口地址如果这个地址用户访问不到比如路由不通、或者被 ACL 挡了页面加载失败用户会觉得认证没成功。这个用手机连上去实测一次就能发现比在设备上查半天快。5.3 长连接被莫名切断超时参数与空闲判定用户反馈下载大文件到 90% 断了、数据库连接半小时不用就断、视频会议开着开着掉线。这类问题的根子是超时参数和业务特征不匹配。CBAC 判定会话是否空闲依据是有没有包经过而不是连接是否还有意义。一个 FTP 大文件传输数据通道一直在传没包才怪理论上不会超时。但如果业务是长轮询或者心跳间隔很长比如某些监控系统 5 分钟才发一个包而tcp idle-time被调到了 300 秒那必然断。调优的方法是先抓现状用show ip inspect sessions反复采样看目标业务的会话在表里存活多久。然后把这个时间跟业务方的实际需求对一下再定参数。我一般会把长连接业务的空闲超时调到业务心跳间隔的 3 倍以上留足冗余。UDP 类业务更要小心。默认 30 秒的空闲超时对视频会议这种持续发包的没问题但对每隔 1 分钟发一次状态包的物联网设备就完蛋了。这类设备在办公网里越来越多遇到连不上又查不出原因的先怀疑 UDP 超时。5.4 排查速查表现象优先怀疑快速验证命令处理动作出向通、回程丢检测方向挂错show ip inspect interfaces确认只在 in 方向挂一次会话表无记录规则未生效show ip inspect sessions检查接口是否挂了规则网速异常慢重复挂规则show ip inspect statistics删除多余的 out 方向配置部分终端断网半开会话超限show ip inspect statistics调高 high/low 水位FTP 能登录不能传数据通道未开show ip inspect sessions detail检查 NAT 与检测的先后认证页反复弹缓存时间过短show ip auth-proxy config调大 auth-cache-time认证后仍不通动态 ACL 被挡show ip access-lists单独编号避免规则交叉AAA 超时服务器不可达本地测试认证配 local 兜底并检查路由6. 上线前的验证清单与几次被教育的经历6.1 我自己必做的一套验证动作配置敲完不等于能上线我一般会走一遍固定流程大概二十分钟能挡掉八成的低级错误。先做基础连通验证从内网选三台不同网段的机器分别 ping 外网、访问 HTTP、访问 HTTPS、做一次 DNS 查询。四项全过说明状态检测的基本链路是通的。再做反向验证从外网主动向内网发起连接确认全部被拒并且在日志里能看到拒绝记录。这一步是证明入向真的收紧了很多人只测正向不测反向结果上线后才发现某条宽松规则忘了删。然后是极限验证找一台机器跑并发连接测试把半开会话数推上去观察show ip inspect statistics里的丢弃计数。如果一推就丢说明水位设低了当场调。这个测试最好在业务低峰做别影响别人。最后是故障演练把 AAA 服务器网线拔了看本地账号能不能登进设备、认证代理会不会把所有人挡在外面。理想的结果是本地兜底生效、已认证的用户不受影响因为缓存还在、新用户暂时上不去但有明确提示。如果演练结果是全体断网那就得重新设计降级方案。注意所有验证动作都要在变更窗口内做并且提前准备好回滚脚本。CBAC 和认证代理的配置散落在接口、ACL、全局配置三处回滚的时候很容易漏建议提前把原始配置完整导出备份。6.2 踩过的几个印象深刻的坑第一个坑跟日志有关。有次上线后设备 CPU 冲到 70%查了半天发现是外部接口 ACL 最后那条deny ip any any log惹的祸——外网扫描流量太大每秒几千个包全部写日志直接把设备拖垮。后来改成先不记日志只计数需要的时候再用show ip access-lists看命中次数配合抓包定位。这个教训是log 关键字在边界接口上要慎用尤其是暴露在公网的接口。第二个坑跟 NAT 顺序有关。某次部署完内网访问外网一切正常但外网访问内网的一台服务器不通。查了半天发现服务器放在 DMZ地址经过两次转换而 CBAC 的会话表里记录的是转换后的地址静态 ACL 里写的是转换前的两边对不上。最后的解决办法是在 DMZ 接口上单独定义一套检测规则跟内网的分开避免地址语义混乱。这件事让我记住一个原则一个检测规则集只服务一种地址语义别混用。第三个坑跟认证代理的登录页有关。设备默认生成的页面是英文的而且样式很简陋用户看到第一反应是这是不是钓鱼网站好几个人直接关掉不填。后来在设备上挂了个自定义页面加了单位和用途说明认证成功率立刻上来了。这件事说明技术方案再正确用户不认也是白搭登录页的用户体验也是安全方案的一部分。第四个坑是参数默认值的版本差异。同一套配置在两个不同版本的系统上跑出来的效果不一样主要是udp idle-time的默认值不同导致的。后来养成了习惯所有关键超时参数一律显式配置不依赖默认值。这样配置迁移的时候行为一致也方便日后对比排查。如果这套东西你已经跑起来了后面还可以往两个方向延伸一是把认证代理跟 802.1X 结合起来有线无线统一准入二是把 CBAC 的会话数据导出做流量基线异常连接一眼就能看出来。这两块我还在摸索等有成熟经验了再单独整理。
做边界防护的同行大多遇到过这种尴尬手上一台中低端路由式设备功能表里既没有像样的区域防火墙模块也没预算上专门的策略平台但业务方要求很明确——外面不能随便进来里面出去要留痕、要能追溯。这种时候 CBAC 和认证代理这两个老功能往往能救场。CBACContext-Based Access Control基于上下文的访问控制解决的是单向放行和状态跟踪的问题认证代理Authentication Proxy解决的是谁能出网、出网前先证明自己是谁的问题。两个东西单独看都不算强但组合起来能在一台普通设备上拼出一套够用的边界访问控制。这篇就把这两项技术的机制、坑点和实操配置拆开讲清楚适合手上有存量设备要加固、又不想大改网络架构的朋友参考也适合想搞明白状态化过滤到底怎么工作的新手打底。1. 先把概念摆正CBAC 与认证代理各自站什么位置1.1 从无状态 ACL 的三块短板说起传统扩展 ACL 的判断依据是五元组源地址、目的地址、协议、源端口、目的端口。设备收到一个包查表、匹配、放行或丢弃结束。它不记得上一个包也不知道这个包是不是某个会话的一部分。这个特性带来三个直接后果。第一个后果是入向必须写得很宽。内部终端访问外网 Web 服务出去的包源端口是随机的 5 万开外的高位端口目的端口 80。回程包的源端口变成 80目的端口是那个随机高位。如果只写permit tcp any any eq 80回程包根本匹配不上因为它的目的端口不是 80。于是很多人图省事写成permit tcp any any established靠 TCP 头里的 ACK/RST 标志位来判断。这个写法的问题在于任何人手工构造一个带 ACK 标志的包就能穿过等于把门锁换成了一块布。第二个后果是多通道协议必然残废。FTP 主动模式、H.323、SIP 这类协议控制信道里协商出来的数据端口是随机的ACL 事先根本不知道要开哪个口。你只能预先开一大段端口范围安全管理瞬间形同虚设。第三个后果是审计断档。无状态 ACL 只能告诉你这条规则放行过多少字节说不出谁在什么时间访问了什么。真出事要回溯什么都拿不出来。CBAC 就是针对这三点设计的。它在设备内部维护一张会话表出向流量经过时把五元组记下来回程包到来时比对会话表命中就放行并刷新计时器。表里没有的、或者状态不对的一律丢。这套机制让入向 ACL 可以被收紧到极致——只留真正需要对外开放的那几条剩下的全部靠动态打开。1.2 CBAC 的状态化检测到底是什么很多人把 CBAC 简单理解成会记会话的 ACL这个说法对了一半。CBAC 的核心竞争力在应用层检测Application Inspection也就是它不只记五元组还会往 TCP 载荷里看一眼。以 FTP 为例。主动模式下客户端说PORT 10.10.10.20,200,100意思是你来连我的 51200 端口。CBAC 的 FTP 检测模块解析这条命令把10.10.10.20:51200这个组合记进会话表当服务端确实从 20 端口发起连接时设备认得出这是刚才那次协商的结果于是放行。被动模式同理会解析227 Entering Passive Mode的回应内容。整个过程对用户完全无感ACL 里也不需要预先开一堆高位端口。这里有个关键认知CBAC 的上下文二字指的就是这种跨包、跨协议的关联信息。它维护的不只是连接状态还有协议内部的协商上下文。这也解释了为什么 CBAC 只能覆盖它认识的那批协议——不认识的应用它只能按 TCP/UDP 的通用方式处理多通道协商部分就帮不上忙了。设备上常见的检测规则大致分几类通用传输层tcp、udp、icmp、基础应用http、ftp、smtp、esmtp、dns、tftp、rpc、sqlnet、多媒体类h323、sip、rtsp、skinny、mgcp、realaudio、vdolive、streamworks、远程访问类rcmd、netshow。选哪些挂上去取决于内网实际跑什么业务这一点后面细讲。注意CBAC 只做单向检测也就是只在流量进入设备的那个接口方向上挂规则。很多新手在内外两个接口各挂一条规则结果会话表被重复记录性能掉一半还查不出原因。1.3 认证代理不是防火墙它是通行条的发放机先把名词澄清本文里的认证代理专指设备上的 Authentication Proxy 这一个功能模块跟其他语境下的代理没有任何关系。它的职责边界很窄——在用户访问网络之前先截获他的 HTTP 请求逼他做一次身份认证认证通过后自动下发一条临时 ACL 给他放行。流程可以这么理解。没有身份证的人走到闸机前闸机不开但会弹出一个登记窗口。你在窗口里填账号密码后台去 AAA 服务器核验核验通过闸机给你发一张有时效的临时卡卡到期自动作废。整个过程里闸机本身不判断你是谁判断的是后台。这套机制的价值在于把网络访问权和身份绑在了一起。传统做法是按 IP 段划分权限某个网段能访问什么、不能访问什么写死在 ACL 里。问题是 IP 不认人同一台笔记本换个人用、换个位置插网线权限就跟着变了。认证代理把放行依据从你从哪来换成你是谁这是质的差别。但也别高估它。认证代理的三个天然限制必须清楚只能拦 HTTP用户不开浏览器就永远触发不了认证依赖 AAA 服务器可用服务器挂了等于谁都上不去下发的是 ACL粒度到端口和地址为止做不到应用层识别。所以它适合做准入门槛不适合做精细管控。2. 方案选型什么场景下这两项技术才值得上2.1 三类真正合适的落点第一类分支机构的出口设备加固。分支规模不大几十到一两百人一台设备既要路由又要做边界。上专门的防火墙平台成本不划算但直接把内网暴露出去又过不了安全评审。这种情况把 CBAC 挂上入向 ACL 收成白名单出向靠状态检测放行是性价比最高的做法。第二类访客网络与办公网络共用出口。访客要上网但不能碰内网。按 IP 段硬切又太死板访客换个房间、换台设备 IP 就变了。这时候用认证代理做一层准入访客拿到账号才能出去认证后下发的 ACL 里只放通公网地址内网段全部拒绝管理上清爽很多。第三类临时人员、外包团队的限时接入。这类需求的特点是短期、可控、要留痕。认证代理的 auth-cache-time 加上 AAA 侧的计费记录正好能满足什么时候来的、用了多久、访问了什么的追溯要求。比起专门拉一条隔离线路成本差着数量级。反过来说有三种情况不建议硬上一是内网跑着大量 CBAC 不认识的私有协议尤其是自研的多通道协议检测帮不上忙还占资源二是并发会话数超过设备会话表上限的勉强开起来只会频繁丢包三是对加密流量占比极高的环境CBAC 看不到载荷应用层检测等于白搭不如直接上七层设备。2.2 与几种常见替代方案的横向对比对比维度CBAC反射 ACL区域防火墙专用策略平台状态跟踪完整会话表仅 TCP 反向条目完整状态机完整状态机应用层检测支持常见协议不支持支持较广支持最广多通道协议FTP/H.323/SIP 等可处理需手工预开端口可处理可处理配置复杂度中命令分散低中高高资源开销中会话表占内存低中高适用设备档次中低端可用低端可用中高端独立硬件典型短板协议覆盖有限无应用层能力授权成本部署周期长这张表想说明的核心是CBAC 的定位在反射 ACL和区域防火墙之间。它比反射 ACL 多了应用层能力比区域防火墙少了策略模型和可视化。选它不是为了追求功能全而是为了在现有设备、现有预算的前提下把安全性从几乎裸奔拉到及格线以上。2.3 上线前必须先确认的四个硬约束约束一硬件平台是否支持。不是所有设备都带这项功能尤其是低端型号或者精简版系统镜像。敲ip inspect ?看有没有回显是最快的判断方法。约束二会话表内存余量。每条会话记录在内存里占约 160 到 200 字节不同版本有差异按经验估算即可。假设内网 500 人人均 30 条并发会话就是 15000 条占 3MB 左右。听起来不多但别忘了设备还要跑路由表、NAT 表、ARP 表。上线前用show memory看一眼剩余量留出至少 30% 的余量比较稳妥。约束三NAT 与检测的处理顺序。这是最容易翻车的地方。调试动态条目时一定要用show ip inspect sessions之类的命令确认里面记的地址是转换前还是转换后。如果 ACL 里写的是转换前地址而会话表里是转换后地址两边对不上就会莫名其妙丢包。约束四AAA 服务器的可达性与备份路径。认证代理没有 AAA 就是一堆废命令。上线前必须配置local作为兜底认证方式并实测一遍服务器断开的情况下本地账号能不能登进去。这条不做好出故障的时候你连设备都进不去。3. CBAC 核心机制拆解与配置落地3.1 检测规则、ACL、接口三者的配合关系CBAC 的配置逻辑可以浓缩成一句话规则在接口上挂一边ACL 在接口上挂另一边。具体来说内部接口的入方向挂ip inspect 规则名 in负责记录出向会话外部接口的入方向挂一条扩展 ACL负责拦掉所有非期望流量。当内部主机发起连接包先经过内部接口被检测规则捕获记入会话表然后转发出去。回程包到达外部接口先过 ACL——ACL 里当然没有这条放行条目包本来会被丢——但设备在查 ACL 之前会先查会话表发现这条属于已建立的会话于是动态插入一条临时放行条目包顺利通过。这个顺序解释了为什么外部接口的 ACL 可以写成默认拒绝。也解释了一个常见误区不要在外部接口的入向 ACL 里给回程流量单独写放行条目。写了不但浪费规则还会让动态条目的作用被掩盖出问题的时候很难判断到底是静态规则放行的还是状态检测放行的。另外一个细节是检测规则挂在接口的in方向指的是从该接口进入设备的流量。所以内部接口挂in外部接口不需要挂ip inspect ... in。这个方向搞反了会话表里什么都看不到。3.2 一份可直接抄的配置模板以下语法为通用形式不同版本的命令字可能略有差异下发前先用帮助命令确认一遍再执行。! 第一步定义检测规则集按业务实际需要挂协议 ip inspect name CBAC_OUT tcp ip inspect name CBAC_OUT udp ip inspect name CBAC_OUT icmp ip inspect name CBAC_OUT dns ip inspect name CBAC_OUT http ip inspect name CBAC_OUT ftp ip inspect name CBAC_OUT smtp ip inspect name CBAC_OUT esmtp ip inspect name CBAC_OUT sqlnet ! 第二步内部接口挂检测规则方向为 in interface GigabitEthernet0/0 description Inside ip address 10.10.10.1 255.255.255.0 ip inspect CBAC_OUT in ! 第三步外部接口挂入向 ACL白名单式 interface GigabitEthernet0/1 description Outside ip address 203.0.113.1 255.255.255.0 ip access-group 101 in ! 第四步ACL 内容只放行必须对外开放的服务 access-list 101 permit tcp any host 203.0.113.1 eq 25 access-list 101 permit tcp any host 203.0.113.1 eq 443 access-list 101 deny ip any any log逐段解释。第一步的规则集里tcp和udp是打底项负责通用状态跟踪icmp让内网发起的 ping 能收到回应dns处理域名查询http除了跟踪连接外还带 Java applet 阻断能力ftp负责处理 PORT/PASV 协商smtp和esmtp支持邮件协议里的扩展命令sqlnet是数据库客户端常用的。第二步的ip inspect CBAC_OUT in一行就够不用写out。第三步的 ACL 里我故意只开了 25 和 443 两个口其余全拒。最后那条deny ip any any log很重要——log关键字会在日志里留下被丢弃的包信息这是排查问题的第一手材料也是安全审计的基本盘。不过要注意日志量流量大的时候log会刷屏可以改成log-input或者干脆先不加等稳定运行几天后再决定。3.3 超时参数怎么算、怎么调CBAC 的超时参数决定了会话在会话表里存活多久调得太短业务频繁断调得太长表项堆积。默认值如下表参数默认值命令调优建议TCP 空闲超时3600 秒ip inspect tcp idle-time长连接业务多的调大UDP 空闲超时30 秒ip inspect udp idle-time视频类业务需单独评估DNS 超时5 秒ip inspect dns-timeout一般不用改TCP FIN 等待5 秒ip inspect tcp finwait-time保持默认TCP SYN 等待30 秒ip inspect tcp synwait-time跨广域网可适当调大半开会话上限高水位500ip inspect max-incomplete high按终端数重算半开会话上限低水位400ip inspect max-incomplete low高的 80% 左右半开连接的两个水位值需要重点算一下。所谓半开会话指的是 SYN 发出去了但三次握手没完成的、或者正在等待关闭的连接。高水位是触发丢弃的阈值低水位是恢复接收的阈值两个值之间留出一段缓冲区避免高水位附近反复震荡。假设内网有 300 台终端每台平均同时打开 8 个连接其中约 10% 处于握手阶段那么瞬时半开会话大约是 300 × 8 × 0.1 240 条。默认的高水位 500 看起来够用但如果遇到开机高峰、批量软件同时启动瞬时值可能翻三倍到 700 以上这时候就会触发丢弃表现为部分终端上网断断续续。经验做法是按峰值估算值 × 1.5设高水位低水位取高水位的 80%。上例中高水位设 1050低水位设 840。! 按终端规模调整半开会话阈值 ip inspect max-incomplete high 1050 ip inspect max-incomplete low 840 ! 单主机半开连接限制防单点扫描 ip inspect tcp max-incomplete host 50 block-time 0最后那条block-time 0表示不限时阻断配合host 50意味着单个 IP 超过 50 条半开会话就拒绝新连接。这个值在办公网里设 50 差不多了如果内部有做压力测试的开发同事记得提前给他们的测试机加例外不然会被投诉上不了网。3.4 应用层检测的那些特殊之处HTTP 检测。除了跟踪连接http检测还有个容易被忽略的能力阻断 Java applet。配法是ip inspect name CBAC_OUT http java-list 50然后 ACL 50 里定义允许加载 applet 的源地址。这个功能在十年前很有用现在 Java applet 基本绝迹但如果你接手的是老系统可能还真能用上能挡掉一批通过 applet 载荷绕过 ACL 的老攻击手法。FTP 检测。前面说过它解析 PORT/PASV 命令。这里有个坑如果内网同时有多个客户端访问同一台 FTP 服务器主动模式下服务器会从 20 端口反向连接各个客户端的数据端口CBAC 靠控制会话的关联信息来区分。实测中没有出过问题但如果中间隔了一层 NAT客户端地址被转换了数据通道的地址可能会对不上表现为能登录、能 ls但 get 卡死。这种时候优先检查是不是 NAT 转换点位于检测点之前。多媒体协议。H.323、SIP 这类协议的信令里带 SDP 描述写着 RTP 的收发地址和端口。CBAC 会解析这些内容并预先开洞。麻烦在于某些终端不按规范填地址填了个私有地址或者 0.0.0.0检测模块就懵了。遇到这种设备与其跟它较劲不如把相关终端所在的网段单独划出来用静态 ACL 处理别硬上检测。UDP 的近似会话问题。UDP 无连接CBAC 只能靠五元组加空闲计时器来假装维护会话。默认 30 秒的空闲超时对 DNS、NTP、SNMP 这类短交互完全够用但对长时 UDP 流比如某些视频会议、组播应用就不行了——30 秒一到条目被回收后续的包再来就是新连接回程照样被 ACL 挡住。解决办法是针对特定业务把udp idle-time调大但这是全局参数会影响所有 UDP 应用所以要权衡。更稳妥的做法是对该业务单独定义一条检测规则只挂在相关接口上。4. 认证代理的完整落地流程4.1 三段式认证流程拆开看认证代理的动作可以拆成三个阶段每个阶段对应不同的失败模式理解清楚才能查得动问题。第一阶段是截获。用户浏览器向任意地址发 HTTP 请求设备在入口处发现这个源地址还没有通过认证于是把请求劫持下来返回一个设备自己生成的登录页面。注意这个页面是设备渲染的不是用户想访问的网站。如果用户访问的是 HTTPS截获会失败——因为 TLS 握手在设备看来是一堆加密字节它没法在中间插入登录页。这是认证代理只能拦 HTTP 的根本原因也是实际部署中最大的痛点。第二阶段是核验。用户在页面上填账号密码设备拿着这组凭证去 AAA 服务器可能是 RADIUS 也可能是 TACACS核验或者退回本地用户库核验。核验结果连同用户属性一起返回属性里可能包含这个用户属于哪个组、允许访问什么。第三阶段是放行。核验通过后设备根据 AAA 返回的属性或者本地配置的 ACL 模板生成一条临时 ACL 绑定到该源 IP同时记录一条缓存条目告诉后续流量这个地址已经认证过了别再拦。缓存的存活时间由auth-cache-time控制到期自动删除当然也可以手工清。这套流程有个隐含前提用户的源 IP 在整个会话期间不能变。如果中间有 DHCP 租期到期重新分配、或者有地址转换导致源地址变化认证状态就会丢失用户被要求重新认证体验很差。所以认证代理最好部署在地址相对固定的网段或者配合较长的 DHCP 租期。4.2 AAA 侧与登录页面的准备AAA 配置是整个功能的地基顺序不能乱。先启用 AAA 框架再定义认证和授权的方法列表最后配置服务器。! 启用 AAA aaa new-model ! 认证方法列表先服务器后本地兜底 aaa authentication login default group radius local aaa authentication login CONSOLE local ! 授权方法列表认证代理专用的关键字 aaa authorization auth-proxy default group radius local ! 服务器配置 radius-server host 10.10.10.50 auth-port 1645 acct-port 1646 key 替换成你的密钥 radius-server retransmit 3 radius-server timeout 5这里有两个细节值得说。第一aaa authentication login CONSOLE local这行必须单独定义并应用到控制台线路。因为默认方法列表改成group radius local之后如果 RADIUS 服务器挂了、本地账号又没配控制台登录也会走默认列表容易出现服务器不通、自己也进不去的死锁。单独给控制台定义一个纯本地的方法列表是保命的操作。第二aaa authorization auth-proxy这个关键字是认证代理专属的不要写成aaa authorization network两者作用范围不同写错了功能直接不生效而且不报错特别难查。AAA 返回的属性里最有用的是acl属性和inacl属性——服务器可以直接告诉设备给这个用户下发哪条 ACL。这样权限管理就集中在服务器侧设备配置不用动人员变动时改服务器就行。如果服务器不支持或者不想用也可以在设备本地用ip auth-proxy name关联一个 ACL 模板走本地逻辑。4.3 配置模板与逐行注解! 定义认证代理规则名称 AP_HTTP触发协议 http ip auth-proxy name AP_HTTP http ! 认证缓存时间单位分钟默认 60 ip auth-proxy auth-cache-time 30 ! 空闲超时单位分钟超时后回收动态条目 ip auth-proxy inactivity-timer 60 ! 接口上启用注意只需要在入口接口启用 interface GigabitEthernet0/0 description Inside ip address 10.10.10.1 255.255.255.0 ip auth-proxy AP_HTTP ip access-group 110 in ! ACL 定义需要认证的流量放进来其余拒绝 access-list 110 deny tcp any host 10.10.10.1 eq 80 access-list 110 permit tcp any any eq 80 access-list 110 permit tcp any any eq 443 access-list 110 deny ip any any log解释一下这几行。ip auth-proxy name AP_HTTP http里的http是触发协议意思是看到 HTTP 请求就去检查认证状态。auth-cache-time 30表示认证后 30 分钟内不再重复要求认证这个值太短用户频繁登录太长则权限回收不及时30 分钟是个折中。inactivity-timer 60表示 60 分钟没有流量就回收动态条目适合人员流动性大的场景。ACL 110 里第一条deny tcp any host 10.10.10.1 eq 80是个易被忽略的写法。它的目的是阻止用户访问设备自身的 Web 管理界面。认证代理工作时如果用户能直接打开设备的 Web 页面就有可能绕过认证页面。虽然实际上认证代理一般会先拦截但显式拒绝一次更保险。后面的permit tcp any any eq 80和eq 443是放行需要认证的流量。这里要注意放行的意思是允许流量进入认证流程不是直接放行最终能不能出去取决于认证结果。很多人第一次配的时候看到 permit 就以为通了结果用户还是上不了网其实是被认证流程挡住了这是正常的。4.4 动态条目的生成、继承与回收认证通过之后设备会在内部生成一条 ACL 条目形如permit ip host 10.10.10.20 any绑定到那个源地址上。这条条目不是写在配置里的重启就没了用show ip access-lists能看到但带特殊标记。继承关系上有个细节动态 ACL 会继承触发它的那条 ACL 的位置。也就是说如果 ACL 110 里permit tcp any any eq 80是第 2 条那么认证后生成的动态条目会插在第 2 条附近而不是附在最末尾。这个特性可能导致意料之外的结果——如果中间有 deny 规则夹着动态条目可能被挡住。我的做法是把认证代理相关的 ACL 单独编号别跟其他策略混在一个列表里减少相互干扰。回收有三条路径。一是inactivity-timer到期自动回收二是auth-cache-time到期后重新要求认证但注意这两者不是一回事前者管流量记录后者管认证凭证缓存三是手工清除用clear ip auth-proxy cache或者针对单个地址clear ip auth-proxy cache 10.10.10.20。测试阶段会频繁用到手工清除记熟这条命令能省不少时间。还有一个常见误解认证代理下发的 ACL 和 CBAC 的动态条目是两套东西。前者管谁能访问网络后者管回程流量能不能进来。两者叠加使用时认证通过的用户还要经过 CBAC 的状态检测才能正常通信少一环都不行。4.5 与 CBAC 联动的正确顺序两个功能同时启用时处理顺序是这样的内部接口收到包 → 先匹配ip access-group的静态 ACL → 再过认证代理判断有没有认证 → 认证通过后进入 CBAC 检测记入会话表 → 转发出去。回程包进来 → 外部接口 ACL → CBAC 会话表命中 → 放行。这个顺序决定了两件事。第一认证代理的 ACL 一定要写在 CBAC 检测之前也就是挂在内部接口的ip access-group上如果把认证相关判断放到外部接口回程流量已经被拒绝在门外了。第二认证代理生成的动态 ACL 只影响入向策略不影响 CBAC 的会话记录所以两个功能的超时参数要分别调别指望调一个另一个跟着变。实际配置里我习惯把认证代理放在内部接口CBAC 也挂内部接口两个一起生效interface GigabitEthernet0/0 ip address 10.10.10.1 255.255.255.0 ip access-group 110 in ip inspect CBAC_OUT in ip auth-proxy AP_HTTP三行命令看起来简单但任意一行写错方向整个功能链就断了排查的时候一定先确认这三行都在而且都在同一个接口的in方向。5. 常见问题与排查技巧实录5.1 用户能上网但回程不通先查方向再查顺序这个症状最容易出现在刚配完的时候内部主机 ping 得出去但收不到回应或者 TCP 三次握手只完成了前两步。八成是检测规则挂错了方向或者挂在了错误的接口上。排查顺序我总结成三步。第一步show ip inspect interfaces看规则有没有真正挂上去、挂的是哪个方向。第二步show ip inspect sessions看会话表里有没有记录。如果没有记录说明出向流量根本没被检测到重点查接口方向如果有记录但回程还是被丢那就去看外部接口 ACL 的日志确认丢包原因。第三步show ip inspect statistics看被丢弃的包计数如果这个数字在持续增长说明检测模块在主动丢包多半是半开会话超限或者协议检测失败。有个很隐蔽的坑接口上同时配了ip inspect X in和ip inspect X out。方向写多了不会报错但会话表会出现重复记录性能直接腰斩而且show命令的输出看起来还挺正常。有一次帮人排查一个网速慢但 ping 正常的问题最后发现就是多写了一行out删掉之后恢复正常。5.2 认证页面反复弹缓存和地址变化的连环坑用户在登录页填完账号密码页面跳一下又弹回登录页。这个问题的成因有好几种按出现频率排序。最常见的是auth-cache-time设成了 0 或者特别小的值。有些版本的默认值跟文档不一致配完一定要用show ip auth-proxy config之类的命令确认实际生效值别信文档。第二种是用户地址在变。笔记本从无线切到有线、DHCP 重新拿地址都会导致认证状态丢失。这种没法彻底解决只能优化延长 DHCP 租期、把无线和有线划到同一个网段、或者配置更长的缓存时间。第三种是 AAA 服务器返回的属性不完整。服务器只返回了认证成功没返回授权属性设备不知道该给这个用户下发什么 ACL于是认为认证没完成重新弹页面。排查方法是打开 AAA 调试看返回的属性列表里有没有 acl 相关的字段。调试命令会输出大量日志生产环境慎用必须在维护窗口做。第四种是登录页面的地址不可达。设备弹出的登录页指向自己的某个接口地址如果这个地址用户访问不到比如路由不通、或者被 ACL 挡了页面加载失败用户会觉得认证没成功。这个用手机连上去实测一次就能发现比在设备上查半天快。5.3 长连接被莫名切断超时参数与空闲判定用户反馈下载大文件到 90% 断了、数据库连接半小时不用就断、视频会议开着开着掉线。这类问题的根子是超时参数和业务特征不匹配。CBAC 判定会话是否空闲依据是有没有包经过而不是连接是否还有意义。一个 FTP 大文件传输数据通道一直在传没包才怪理论上不会超时。但如果业务是长轮询或者心跳间隔很长比如某些监控系统 5 分钟才发一个包而tcp idle-time被调到了 300 秒那必然断。调优的方法是先抓现状用show ip inspect sessions反复采样看目标业务的会话在表里存活多久。然后把这个时间跟业务方的实际需求对一下再定参数。我一般会把长连接业务的空闲超时调到业务心跳间隔的 3 倍以上留足冗余。UDP 类业务更要小心。默认 30 秒的空闲超时对视频会议这种持续发包的没问题但对每隔 1 分钟发一次状态包的物联网设备就完蛋了。这类设备在办公网里越来越多遇到连不上又查不出原因的先怀疑 UDP 超时。5.4 排查速查表现象优先怀疑快速验证命令处理动作出向通、回程丢检测方向挂错show ip inspect interfaces确认只在 in 方向挂一次会话表无记录规则未生效show ip inspect sessions检查接口是否挂了规则网速异常慢重复挂规则show ip inspect statistics删除多余的 out 方向配置部分终端断网半开会话超限show ip inspect statistics调高 high/low 水位FTP 能登录不能传数据通道未开show ip inspect sessions detail检查 NAT 与检测的先后认证页反复弹缓存时间过短show ip auth-proxy config调大 auth-cache-time认证后仍不通动态 ACL 被挡show ip access-lists单独编号避免规则交叉AAA 超时服务器不可达本地测试认证配 local 兜底并检查路由6. 上线前的验证清单与几次被教育的经历6.1 我自己必做的一套验证动作配置敲完不等于能上线我一般会走一遍固定流程大概二十分钟能挡掉八成的低级错误。先做基础连通验证从内网选三台不同网段的机器分别 ping 外网、访问 HTTP、访问 HTTPS、做一次 DNS 查询。四项全过说明状态检测的基本链路是通的。再做反向验证从外网主动向内网发起连接确认全部被拒并且在日志里能看到拒绝记录。这一步是证明入向真的收紧了很多人只测正向不测反向结果上线后才发现某条宽松规则忘了删。然后是极限验证找一台机器跑并发连接测试把半开会话数推上去观察show ip inspect statistics里的丢弃计数。如果一推就丢说明水位设低了当场调。这个测试最好在业务低峰做别影响别人。最后是故障演练把 AAA 服务器网线拔了看本地账号能不能登进设备、认证代理会不会把所有人挡在外面。理想的结果是本地兜底生效、已认证的用户不受影响因为缓存还在、新用户暂时上不去但有明确提示。如果演练结果是全体断网那就得重新设计降级方案。注意所有验证动作都要在变更窗口内做并且提前准备好回滚脚本。CBAC 和认证代理的配置散落在接口、ACL、全局配置三处回滚的时候很容易漏建议提前把原始配置完整导出备份。6.2 踩过的几个印象深刻的坑第一个坑跟日志有关。有次上线后设备 CPU 冲到 70%查了半天发现是外部接口 ACL 最后那条deny ip any any log惹的祸——外网扫描流量太大每秒几千个包全部写日志直接把设备拖垮。后来改成先不记日志只计数需要的时候再用show ip access-lists看命中次数配合抓包定位。这个教训是log 关键字在边界接口上要慎用尤其是暴露在公网的接口。第二个坑跟 NAT 顺序有关。某次部署完内网访问外网一切正常但外网访问内网的一台服务器不通。查了半天发现服务器放在 DMZ地址经过两次转换而 CBAC 的会话表里记录的是转换后的地址静态 ACL 里写的是转换前的两边对不上。最后的解决办法是在 DMZ 接口上单独定义一套检测规则跟内网的分开避免地址语义混乱。这件事让我记住一个原则一个检测规则集只服务一种地址语义别混用。第三个坑跟认证代理的登录页有关。设备默认生成的页面是英文的而且样式很简陋用户看到第一反应是这是不是钓鱼网站好几个人直接关掉不填。后来在设备上挂了个自定义页面加了单位和用途说明认证成功率立刻上来了。这件事说明技术方案再正确用户不认也是白搭登录页的用户体验也是安全方案的一部分。第四个坑是参数默认值的版本差异。同一套配置在两个不同版本的系统上跑出来的效果不一样主要是udp idle-time的默认值不同导致的。后来养成了习惯所有关键超时参数一律显式配置不依赖默认值。这样配置迁移的时候行为一致也方便日后对比排查。如果这套东西你已经跑起来了后面还可以往两个方向延伸一是把认证代理跟 802.1X 结合起来有线无线统一准入二是把 CBAC 的会话数据导出做流量基线异常连接一眼就能看出来。这两块我还在摸索等有成熟经验了再单独整理。
