背景
北京办公室员工的数量逐渐增长，Wi-Fi 设备也越来越多。早期连接公司网络只要共享一下 Wi-Fi 密码即可，但随着时间的推移，这种方式暴露出以下问题：
- 任何知道密码的人都可以将任何设备连接至公司局域网（无论是否是公司员工、无论是否是公司允许的设备）。
- 员工离职后，无法禁止其再次连接公司网络。
- 在 UniFi Controller UI 上看到的客户端名称为自己设置的 Hostname。由于只有仅少数人会特意配置自己的 Hostname，导致难以查找此客户端的归属人。
可选的解决方案
对于问题 3，使用 UniFi 全家桶的我们只有一种方案：提前配置 UniFi Controller，根据 MAC 地址创建对应的客户端名称。另外还可同时配置 DHCP 服务，为特定客户端预留 IP。
对于问题 1 和 2：
- a. 与 SSO 结合，配置 Radius 服务。
- b. 配置 802.1X 访问权限认证。
- c. 使用 MAC 地址白名单，明确限制可连接的客户端。
我们选择的是方案 c。原因如下：
- 方案 a 和 b 需要较长时间调研和实施，我们没有相关经验。
- 目前企业规模不大，能够接受配置 MAC 白名单。
- 实现方案 c 的同时可以一并解决问题 3，一举两得。
自动化
手动维护一份文档式的列表用于记录员工信息与对应的设备列表、MAC 地址，不仅费时费力，还难以和 UniFi 的实际配置保持一致。UniFi Controller 的 MAC Address Whitelist UI 也不太顺手，例如不提供批量编辑、删除操作：
因此我们选择用 UniFi Controller 的 API，在 GitHub 上找到第三方维护的 PHP SDK。借助封装好的 SDK，只需要调用 create_user() 和 update_user() 方法，我们很容易就开发了一个 CLI 小脚本，并定义了一套 YAML 配置文件：
lei.li@rightcapital.com: # 设备所有者
- mac: 78:7e:61:... # 设备 MAC 地址
description: iPad # 设备名称 / 描述
white_list: true # 是否加入 Wi-Fi 设备白名单
meimei.han@rightcapital.com:
- mac: 78:7e:61:...
description: iMac
white_list: false # iMac 使用有线网络连接，因此不需要加入白名单
# 以此类推...
我们把配置文件和 PHP 小脚本全部存放在一个 Git 仓库，配置好 GitLab CI，并在本地网关中安装了 GitLab CI Runner 以便于从局域网访问 UniFi Controller API。
需要增删设备时，提交到该仓库并创建 PR 即可，符合公司要求的设备经过 review 后合并到 master 分支，随后自动触发 CI 调用脚本把白名单以及设备信息配置好：
最终在 UniFi Dashboard 即可清晰明了地查看客户端列表和拓扑图：
拓展
在先前的文章中，我们介绍了将定时任务监控项代码化的实践过程。后续可考虑将小脚本和 YAML 格式配置文件改进为 Terraform Provider 和 HCL 语法的资源声明，每个客户端都是独立的 resource，借助 Terraform 帮助我们更加可靠地管理它们。
请关注我们的微信公众号「rightcapital」
