• Network Admission Control · Availability Design

  网络准入系统可用性设计
  逃生 · 双机热备 · 级联容灾
  准入系统一旦上线，就不再只是"安全设备"，而是生产链路的一环。 管控强度永远不能超过可用性承载能力——任何管控动作都要有兜底路径，任何组件都要有失效预案。

一、先正视一个事实：准入系统是生产链路的一部分

准入系统上线之前，网络是"哑"的——终端插上网线就能通。上线之后，每一台终端的入网、每一次认证、每一个 VLAN 下发，都要经过准入系统。这意味着准入系统从安全设备变成了生产链路的一环：它挂了，网络不是"少了安全管控"，而是"新终端入不了网、认证终端可能被误断"。

• 设计铁律
  管控强度永远不能超过可用性承载能力。任何管控动作都要有兜底路径，任何组件都要有失效预案。

这条铁律落地为三个具体机制：逃生、双机热备、级联容灾。

• 二、逃生机制：管控系统的自我熔断

  2.1 为什么需要自动逃生

  准入系统的阻断逻辑是持续运行的：新设备接入，判定，放行或阻断。正常运行时，阻断的是该阻断的。但有两种异常场景会让阻断行为本身变成事故：

  • 认证服务异常

    Radius 服务进程崩溃、数据库连接池耗尽、证书过期——此时所有认证请求超时。802.1X 下终端反复认证失败，交换机端口卡在 Unauthorized；VARP 下准入设备无法查询终端状态。如果策略默认是"认证失败即阻断"，全网终端会批量掉线。

  • 策略数据异常

    管理员误操作把某个大 VLAN 的入网规则从"允许"改成"拒绝"，或者批量导入的黑名单覆盖了正常终端。阻断量瞬间飙升。

  这两种场景的共同点是：系统无法区分"终端真的违规"和"我判定不了"。而一个诚实的准入系统必须承认：判定不了的时候，安全让位于可用。这就是逃生的本质——阻断量的异常本身就是系统故障的信号，要用这个信号反过来熔断管控。
  2.2 阈值模型的设计
  逃生判定基于两组可观测指标：

  // 逃生判定模型
  触发条件（任一满足）：
    ① 放行数量 < 阈值A  或  放行率 < 阈值B（持续 T1 时间）
    ② 新增阻断数量 > 阈值C  或  阻断率 > 阈值D（持续 T2 时间）
  
  触发动作：自动关闭准入控制功能（或切换为全放行模式）
  恢复方式：人工确认后手动恢复，或满足恢复阈值后自动恢复

  • 为什么用"率"而不是绝对值

    夜间和白天的终端基数差一个数量级，固定数量的误报在白天是噪声、在夜间就是全部。放行率（放行数/请求数）和阻断率天然做了归一化。

  • 为什么要持续时间窗口

    瞬时毛刺不该触发逃生——管理员手动测试阻断功能时，阻断率瞬间 100% 是正常行为。设置持续窗口（如 5 分钟内阻断率持续高于 80%）过滤掉操作噪声。

  • 恢复策略比触发策略更谨慎

    触发是自动的，恢复一般是人工的。自动恢复的条件必须比触发条件严格得多，否则系统在"熔断—恢复—再熔断"之间震荡，网络状态比不熔断还差。实践中多采用"人工确认 + 定时自动恢复（较长周期）"的双轨。

  • 逃生的粒度

    全局逃生是最后的手段，粒度更细的做法是按准入方式、按 VLAN 分段逃生——802.1X 认证故障只关闭 802.1X，VARP 异常只影响对应 VLAN。粒度越细，安全损失越小，但配置复杂度越高。迪康网络准入控制系统等产品的"主动逃生配置"即采用可配置阈值的全局熔断模型，把颗粒度取舍留给管理员。

• 三、双机热备：Radius 与 VARP 的状态冗余

  3.1 Radius 热备

  802.1X 和 MAB 的认证都汇聚到 Radius 服务，它是准入系统里单点风险最集中的组件。

  关键不在"有两台"，而在状态的一致性：

  • 身份与凭据数据

    账号库、证书状态、终端指纹必须实时或准实时同步，否则切换后会出现"合法终端被拒"。

  • 策略与配置

    放行规则、黑白名单、VLAN 下发策略需保持一致，配置变更应在两台上原子生效。

  • 在线终端状态

    备机必须知道"谁已经在线"，否则切换瞬间会把在线终端当作新终端重新认证，造成闪断。

  • 心跳与防脑裂

    独立心跳链路 + 仲裁机制，避免主备互相失联后同时进入主状态、下发互斥策略。

  3.2 VRRP 热备

  VRRP 热备的一个隐形问题是状态漂移：主备长期运行，若设备画像、白名单等数据只写在主机本地而没同步，切换后备机拿着过期数据做准入判定，误判率上升。所以 VRRP 热备必须与 Radius 热备共用同一套数据同步通道，而不是各备各的。

• 四、级联架构：多节点网络的分层容灾

  4.1 为什么单中心撑不住

  集团型网络（多园区、多分支）把所有终端的认证压到中心节点，有两个硬伤：

  • 硬伤一：跨广域网的认证时延

    终端入网本是本地行为，却要跨 WAN 到中心完成认证。链路抖动、RTT 升高直接表现为认证超时、入网慢，甚至触发大面积的"认证失败即阻断"。

  • 硬伤二：中心故障的爆炸半径

    中心一挂，所有园区同时失去认证与管控能力。此时逃生只能全局放行，等于全网无管控——安全与可用同时失守。

  4.2 级联自身的高可用

  级联引入了新的故障模式：中心挂了怎么办、链路断了怎么办、子节点数据积压怎么办。对应的处理：

  • 中心节点故障

    子节点自动进入本地自治模式，使用本地缓存的策略继续完成认证与准入，网络不受影响；中心恢复后增量回传审计数据与本地变更。

  • 级联链路中断

    认证在子节点本地闭环，不依赖链路可达；策略更新暂缓而非失效，链路恢复后自动拉取最新版本并回传积压数据。

  • 子节点数据积压

    本地落盘队列 + 限速回传，设置容量上限与淘汰优先级（优先保留阻断与告警记录，普通放行日志可降采样）。

  • 子节点自身故障

    子节点同样需要逃生与双机热备，或降级为本地放行，避免"中心活着、园区却断了"的局部事故。

• 五、压测与演练：可用性不是配置出来的

  逃生阈值、热备切换、级联降级，这些机制写在配置里不等于能工作。三个必做的验证动作：

  • 逃生阈值演练

    人为制造高阻断（如误配置一条大范围拒绝规则），验证系统是否在 T2 时间窗内真实熔断放行；同时验证恢复流程不会造成"熔断—恢复—再熔断"的震荡。

  • 双机切换演练

    拔心跳线、杀 Radius 进程、断开主备同步链路（脑裂场景最易出问题），验证切换过程中在线终端是否掉线、切换后审计数据是否连续、是否存在双主下发互斥策略。

  • 级联断链演练

    断开子节点到中心的链路，验证本地认证是否正常、策略是否仍然生效、数据是否正确缓存，链路恢复后积压数据是否完整同步且不漏审计。

• 六、结语

  网络准入系统的可用性设计遵循的是一个朴素的安全工程原则：任何强制机制都必须自带失效安全模式（fail-safe）。
  逃生机制用阻断量的异常反向熔断管控，双机热备用状态冗余消化设备故障，级联架构用分层自治消化规模与链路风险。三者各管一段，缺一不可。

  • 部署准入系统时，验收清单里"认证功能可用"只完成了一半——另一半是逐项验证：设备宕机会怎样、策略配错会怎样、链路中断会怎样。答案都应该是：网络活着，管控可恢复。