初窥Huawei_Campus 解决方案_用户接入（三）

目录

前言

我们在学习虚拟化园区网解决方案的时候，会接触到这么几个概念：NAC、策略联动、业务随行，那他们之间是什么关系？NAC、策略联动、业务随行都是进行用户接入控制的一种技术。

  1. 业务随行是基于安全组对用户进行管理、保证用户在园区任何位置都可以拥有相同的权限策略。
  2. NAC（network admission control网络接入控制）是通过接入网络的客户端和认证保证网络安全的技术；
  3. 策略联动是通过在网关设备上统一管理用户的访问策略并且在网关设备和接入设备执行用户访问策略来解决大型园区策略强度与复杂度之间矛盾的一种解决方案，是为了网络规模较大时，简化配置的一种方案。

策略联动

什么是策略联动呢？什么是策略？谁跟谁联动？

策略联动是园区网的解决方案，这个策略指的就是权限策略，什么是权利策略呢？其实特别简单，就是谁能访问谁，谁不能访问谁，比如默认一个vlan不能访问另一个vlan，这一点我们可以通过acl或安全策略来实现。那联动是什么意思？联动的意思就是结合，结合谁呢？其实是结合准入，准入的意思很简单，就是是否允许你接入。

那我们可以来总结一下了，什么策略联动？

策略联动指的策略结合准入，更具体一点的表达是是否允许你接入，以后接入之后能获取的什么权限。

为什么要有策略联动呢？

策略和准入本来就是自然的先后顺序，准入之后自然就要获取权限，将准入和策略联动起来是一个很好的结合。不结合到一起是否可以呢？当然也可以，就是配置起来比较麻烦罢了，比如某个研发的同事离职很久了，但是工位上的网口一直没有处理，一直处于闲置状态，一旦有人接入就能获取研发人员的一部分权限，那我们可以在交换机将这个接口down掉，当有新员工来了之后我们将其打开（准入），并再将其划分到研发所属的vlan（权限），如果很多人同事入离职，这些岂不是很麻烦！

策略联动是如何解决以上问题的？

集中统一管理合法用户以及其权限，放置到一个数据库当中,比如RADIUS服务器当中，然后在接入交换机上开机dot1x认证，当交换感知到有终端接入时，会让终端输入用户名和密码，交换机接收到之后统一发往RADIUS服务器进行校验，如果认证不通过，那就不允许接入，如果允许通过，就要在数据库当中查找其权限，这个权限指的就是该用户所属的vlan以及ACL，认证服务器将权限信息发送给认证执行点上，认证执行点就会立马执行，将该用户放到所属的VLAN当中并且设置好ACL。认证执行点一般放到接入交换机上，因为这样授权的颗粒度才最精细。而且接入交换机面向终端的接口最好是混杂接口，不能是access或trunk接口。

策略联动的缺点—并发问题

问题出在RADIUS服务器上。我们通常是在接入层做认证执行点，接入交换机与RADIUS服务器做点到点通信，如果网络规模大比如上千台接入交换机同时连接RADIUS，这样会造成并发量过大的问题。那如何解决并发的问题？可以参考一下打印服务器，公司里面的打印机的有支持连接数是很小的，大概10位左右，人一多打印机就容易离线，通过在打印机与终端之后加入打印服务器，让打印服务器去承担用户的并发压力和文件缓存，打印机只需要面对一台打印服务器即可，压力瞬间减少很多；策略联动的解决方案与此类似，将认证为分认证执行点与认证控制点两部分，认证执行点放在接入交换机，认证控制设备放在汇聚或核心设备上，认证执行点都仅对认证控制点连接，然后认证控制点再与RADUIS服务器连接，认证控制点起到了缓存和分担RADIUS服务器压力的作用。

策略联动涉及到的协议

认证控制点与认证执行点之间使用CAPWAP隧道：control and provisioning of wireless access points

认证控制点与RADIUS服务器（通常是控制器充当）之间

策略联动的实现机制，与打印的场景基本上一致的，如下所示：、

image-20230625135127942

策略联动最致命的缺点—需要提前配置好执行点设备

RADIUS服务器有一个缺点，就是只能下发权限，比如说只能告诉交换机把接口划入到哪个VLAN当中，告诉交换机使用哪个ACL，但是却不能创建VLAN和ACL，需要提前把VLAN和ACL创建好才行，好麻烦的说！

业务随行

基本概念

比策略联动更高级的—业务随行 什么是业务随行？

杭州华为全球考试足以的园区就配置了业务随行的功能，华为的员工无论在自己的工位还是在餐厅、健身房，无论在任何地方通过终端获取的权限都是一样的，可以随时随地的办公，业务权限始终跟随用户身份，这就是业务随行。

业务随性这么神奇的技术是如何实现的？

这么神奇的技术通过策略联动是无法完美实现的，算是勉强能实现，就是因为策略联动多了一步需要提前在执行点设备上创建VLAN和ACL，难道业务随行实现了这个功能？其实没有，业务随性是通过引入其它概念来实现的，比如安全组、资源组。

策略联动的管理核心其实还是用户的IP地址，通过划分不同的VLAN获取不同的网段的IP地址，然后在IP地址的基础上再附加权限（ACL），也就是说权限由ACL控制，而在业务随行当中权限由权限矩阵来实现，那什么是权限矩阵？

什么是权限矩阵呢？

矩阵这个名字看起来挺唬人，但这个矩阵其实就是一张表格，看着就像一个数据库，用户拥有什么权限是由这表表格说了算的，一张由安全组成的表格，如下所示：

查房系统 医疗系统 病例库
领导 允许 允许 允许
医生 允许 允许 允许
护士 禁止 允许 禁止
病人 禁止 禁止 禁止

动态安全组：领导、医生、护士、病人

静态安全组：查房系统、医疗系统、病例库

没看到用户呀？其实用户在上面这张表当中没有体现出来，用户是要放到组当中的，比如病人，张三、李四是病人，那他们就是属上表当中的病人安全组。

那什么是资源组呢？

资源组是也是安全组一种，用来弥补安全组的不足；

安全组里面即可以放置用户，也可以放置资源，比如http、dns这样的服务；但是如果一台服务器同时提供http和dns，安全组就无法进行标识了，两个服务都是同一个IP地址，如果通过安全组将这个安全组下发之后，那该用户就同时拥有了访问http和dns的权限，这样权限太大了，不合理。正确的做法就是将分开标识，虽然是一个IP地址，但是拥有不同的服务，那就是两个安全组，怎么办呢？就在安全组与IP对应的形成的表当中再插入一列组名，这个组就是资源组，这么看来，资源组也是安全组一种而已。

安全组里面只能通过职业来分类吗？

当然不是，我们可以随便进行分类，不一定非得通过职业。

业务随行和策略联动是什么关系？

策略联动的意思就是权限策略结合准入，我们之前看到的通过控制器下发VLAN和ACL就是策略联动的一种实现方式，只不过这种方式不太好用，很难实现业务随行，所以才有了业务随行，所以我们可以把业务随行看做是策略联动一种升级版实现方式。

基本架构

image-20230625135138647

业务随行的基础架构还是AAA架构，由网络设备做为客户端，控制器做为AAA服务端的二层架构，但由于并发问题，业务随行的架构当前是三层：

  1. 控制器做AAA服务器
  2. 客户端分为
    1. 认证点
    2. 策略执行点。

控制器：控制器充当认证服务器，同时也是业务随行的策略控制中心，制定和下发全网的安全组之间的策略控制矩阵。

认证点：认证点充当认证服务器的缓存点，控制器在制定完安全组与安全控制矩阵之后会立马下发一份到达认证点，之后就能够对终端进行身份认证，以减少对控制器的并发连接。

策略执行点是最底层，就是策略执行的时候，策略执行的内容是什么？来自于哪里呢？策略执行的内容并不是传统802.1x当中的下发的VLAN和ACL，而是安全组组成的权限矩阵。

基本原理

我们来总结一下：

  • 策略联动准入的实现方式
    1. 控制器做RADIUS、下发ACL+VLAN实现权限控制
    2. 控制器做RADIUS、通过安全组和资源组实现权限控制（campus方案使用这一种）
  • 第一种方法的部署方式：准入 + ACL和VLAN
  • 第二种方法的部署方式：准入 + 安全组（campus方案使用这一种）

image-20230625135147655

我们可以来分析一下整个过程：

  1. 管理在控制器中创建用户账号，定义UCL组（安全组），同时将用户账号加入其所属的UCL组，所有用户必须在认证通过后才可以接入网络。然后为用户统一定义基于UCL组的网络访问策略（策略矩阵）
  2. 控制器将安全组和策略矩阵下发到策略执行点设备。
  3. 执行点设备向控制器建立IP-GROUP通道
  4. 用户终端开机，开机之后认证执行点推送802.1x的认证界面给用户终端，认证信息（BPDU）穿越认证执行点到达认证点，认证点向控制器发起用户认证校验请求；控制器将将授权结果（用户所属安全组对应的VLAN）下发给策略执行点，此时用户连接的接口会执行关联信息，得到终端所属的VLAN，终端开始通过DHCH获取IP地址；认证点或策略执行点将终端获取的IP地址上报给控制器，控制器将此IP和安全组做一个对应关系，就是IP-GROUP表项。
  5. 控制器通过IP-GROUP通道向执行点设备推送IP-安全组表项信息（该用户所属组作为授权结果），该表记录源/目的IP与安全组的映射关系。
  6. 用户访问网络。当执行点设备收到用户报文后，会尝试识别报文的源/目的IP对应的安全组，对报文执行基于组策略

如何给用户穿马甲？

其实最终还是通过IP+安全组的映射来实现的。比如你获得的IP地址是1.1.1.1，输入用户名是zhangsan，那认证点会结合RADIUS数据库帮你生成这样一条映射信息：1.1.1.1 | 医生组，流量怎么能携带用户名和安全组呢？不会的，其实这种穿马甲就是通过这种映射关系来实现的，当你的流量上来之后，立马判断你的源IP地址，然后来查这么表，根据IP地址得知你的安全组是医生组，然后将流量再交给策略执行进程，策略执行进程会根据你的安全组结合矩阵再判断你是否你权限访问你想访问的资源组。对了，1.1.1.1 | 医生组 这样的信息叫做IP-GROUP。这样信息认证点上肯定会存在，由于认证点帮用户认证时不可避免的去控制器查询校验，所以控制器上也有一份。如果认证点与策略执行点不是一个设备的话，那策略执行点就无法获取IP-group表，那就得去控制器上订阅一份，使用的协议是http2.0，VXLAN网络不用订阅，因为VXLAN的报文里面本身就嵌入了安全组的信息。

安全组理解（一）

安全组是业务随行的重点，安全组在控制器上叫安全组，下发到设备上就叫”UCL(用户控制列表)”。

我们可以把安全组理解成为一个用户组，这个组当中可以放置用户，比如你把研发的所有人员放都到RD组当中，将与非研发有关的人员都放到NRD组，从这个角度来看，安全组就是一个用户组；

同样的，我们也可以把安全组理解成为一个资源集合，比如你将算法服务器集群定义为Core_Server组，将公共资源相关的服务器集群定义为public_server组。

那有了这个组我们就可以定义访问策略了，比如NRD和RD组都都可以访问public_server，但只有RD组可以访问core_server组，那我们就可以这么定义，如下所示：

public_server core_server
RD 允许 允许
NRD 允许 不允许

总而言之，安全组就是一个组，这个组里面啥都能放；当组与组之间联合起来时就可以组成安全策略矩阵，我们就可以在这个矩阵当中定义哪些组之间可以相互访问，哪些组之间不可以相互访问。

安全组理解（二）

查房系统 医疗系统 病例库
领导 允许 允许
医生 允许 允许 允许
护士 禁止 允许 禁止
病人 禁止 禁止 禁止

安全组里面里面其实是可以为空的，如上图所示。那当领导去访问病例库的时候到底是允许还是禁止呢？其实真实的的安全矩阵应该是这样，如下图所示：

查房系统 医疗系统 病例库 ANY
领导 允许 允许
医生 允许 允许 允许
护士 禁止 允许 禁止
病人 禁止 禁止 禁止

你会发现多了一列ANY，ANY这一列也全是空的，ANY列是全空的代表禁止，也就是当领导访问病例库的时候不知道到底是禁止还是允许时，就会向后匹配ANY，ANY我们可以明确写动作，如果不写，安全期间，它的默认动作就是拒绝的。

安全组理解（三）

客户诉求 传统方案 业务随行方案
满足移动化办公的权限一致 采用动态VLAN+静态ACL方案，配置规划复杂、预配置工作量大，ACL维护困难，难以保证用户网络权限一致 寅网络访问策略与IP的解耦，管理员在控制器基于用户身份进行安全组的统一划分，通过策略矩阵统一管理策略，配置简单，维护方便，能有效保障用户移动时的网络访问权限一致
基于业务的用户隔离 采用二层VLAN隔离+三层ACL隔离方案，在移动化办公背景下，配置规划复杂，预配置工作量大，ACL维护困难，难以有效实现用户隔离 二层端口隔离+基于安全组的组间策略，组间隔离策略与IP解耦，配置简单，维护方便，能将有效实现用户隔离
简化配置和管理 认IP为基础，需要在网络设计前期规划大量VLAN，ACL等，配置复杂，难以理解，不得于后期维护 以安全组（UCL）为基础，仅需要定义几个用户组，组间策略，大大简化规划和配置工作量，且策略矩阵简单形象，容易理解，便于维护。

通过上文的描述我们知道了安全组特别重要，还可以组合安全组形成安全矩阵，还知道了安全组当中是可以加入用户的，而且安全是可以做为权限策略下发到策略执行点的，那么问题为了？安全组仅仅有用户或权限，也那也不够呀？在传统的802.1x方案当中，权限策略是包括VLAN和ACL的，有了VLAN用户终端才能顺利获取IP所属VLAN的IP地址，那在安全组当中，包括VLAN吗？当然有了！

那我们总结一下，安全组里面都有什么？

  • 安全组里有什么？
    • 用户账号和密码
    • 该安全组所属的VLAN或VLAN池

安全组理解（四）

安全组分为两为两个大类

  1. 普通的安全组
    1. 动态安全组
    2. 静态安全组
  2. 资源组

我们先来解释一下资源组，资源组是安全组的一种类型，用为完成普通安全组无法完成的工作。为什么会有资源组？安全组不是挺强大的吗？安全组说白了就是一组对象的集合，细粒度顶多到IP这一层，这就会导致一个问题，你看哈，假如我有一台服务器（只一 个IP地址）同时提供gitlab和公司门户网站两种服务，当然是通过侦听不同的套接字来实现的，那如果通过安全组来定义的话，就只能定义到Ip这一层，无法区分这同一个IP的不同的端口！如果不同区分端口的话就可能会导致事故，比如你在做策略的时候将这个IP允许所有人能访问，这将对gitlab的安全性产生威胁。所以我们需要一种更高级的安全组，这种安全组可以区域三层以上的东西，将192.168.0.10:443 和 192.168.0.10:8080完全区分开了，这样我们在做策略的时候就可以只让研发人员访问gitlab，所有人都可以访问公司的门户网站。

关键节点选择

认证点和策略执行点位置选择：

一般认证点选择用户网关设备，并且网关设备同时做为策略执行点，部署业务随行功能。

主要原因：

  1. 接入交换机数据较多，在每台接入交换机上配置认证功能较为繁琐，管理起来也较为麻烦；
  2. 控制器需要向策略执行点设备同步权限策略，如果选用接入交换机做为认证点，则策略执行点设备的数量会大幅增加（因为接入交换机数量较多），不仅增加了控制器上设备管理的工作量和难度，还延长了每次同步策略的时间。
  3. 对于用户网关以下的二层网络能够互通的用户，如果想要进行互访控制，可以部署二层隔离，使用户在二层不能互通，流量必须经过用户网关。

业务随行的部署

以下所有配置都是在控制器上的操作，还是比较简单的，尽量不截图说明。

第一步：创建安全组

业务部署—安全组/资源池—创建安全组

PS：安全组内没有任何的VLAN

第二步：创建策略控制矩阵

  1. 安全组/资源池—策略控制—增加

  2. 要选择设备（策略执行点设备）之后，自动形成矩阵

  3. 在矩阵上配置策略，点击部署之后会自动下发到策略执行点设备

    PS：此时已经推送到策略执行点了，我们可以去策略执行点查看

    # 在策略执行点上查看创建ucl组，即安全组
dis cur | incl ucl-group
# 查看策略点上根据ucl组创建的策略，策略实际是通过acl创建的
dis cur | incl acl

    目前的问题是知道组与组之间策略，但是还没有用户，也不知道用户属于哪个组。

另外，业务随行部署之后，立马就是准入，我们下面顺便把准入也给做了

第一步：创建用户组和用户

安全组/资源池—用户管理创建用户账号、并配置账号密码（注意这在这个地方把“下次登录修改密码给取消掉”）

第二步：创建认证规则

准入—准入策略—认证授权—认证规则—创建认证规则（注意，把各种认证协议都选上）

第三步：创建安全的授权结果（其它就是给安全组配置VLAN）

准入—准入策略—认证授权—授权结果—创建

写入关键信息：安全组和安全组对应的VLAN

PS：要搞上对应的站点

第四步：创建授权规则

准入—准入策略—认证授权—授权规则—创建

  • 认证方式：用户接入认证
  • 接入方式：WIFI或有线
  • 账号信息匹配：选择对应的用户
  • 对应的账号选择一下
  • 最关键的来了，最后选择对应的授权结果
posted @ 2023-06-25 13:54  张贺贺呀  阅读(437)  评论(0)  编辑  收藏  举报