本篇文章讲述了实际研发iceHorizonCloud的一些想法。
前言
这个客户端是干啥用的
上节已经说过，这个客户端是针对设备跨三层路由时进行策略随行而准备的。同时还可以对接入设备进行安全检查，以避免不正当软件造成的不良影响
我可以在哪里得到这个客户端
经过博主我一番考虑之后，我决定把iHCSC这个客户端开源了（在我的GitHub中）。该客户端由Golang编写，借以来实现跨平台。由于是Golang的初学者，再加上经验不是很足，因此代码的规范性可能非常差，还请朋友们包涵。
功能列表
- 设备安全检查：目前只实现了进程检查，Windows客户端会强制要求管理员方式启动，进而读取系统中所有的进程名，并拼接成一个长字符串发送到服务端进行匹配。
- 读取IP和MAC地址：读取方式仍然是使用socket套接字，创建套接字后获取套接字中的源IP，再使用套接字中的源IP地址遍历匹配设备接口查找对应的物理接口，读取相应的MAC地址。
- 硬件信息读取：包含CPU型号，必要时可以做硬件绑定。
- 系统信息读取：读取系统类型和版本号，以及主机名等，Windows可以额外读取系统的ID，用于硬件+IP+MAC+系统唯一绑定（服务端还没写）。
实现原理
客户端的实现比较简单，进程获取方式都是使用开源轮子，通信这块使用的HTTPS协议，解析方式为JSON。相关的私有协议还在设计中，还是要话一些时间做私有协议。
服务端设计其实比较简单，没客户端这么复杂。服务端设计是整套的iptables+ipset，IP列表可以使用Linux的动态链接库libipset，golang服务端可以嵌入C语言使用gccgo编译，进而引入动态链接，然后联动后端和防火墙。
服务端还需要嵌套一层nginx做反向代理和负载均衡，以避免接口短时请求压力过高，同时需要打开SSL功能，实际部署时我把HSTS打开了。客户端也会强制要求验证证书，否则不会进行下一步操作。
还在计划的功能
- 远程诊断：我看H3C iNode缺少一个很必要的功能——远程诊断服务。有时候客户端这边一些莫名其妙的问题，无法判断问题的时候，可能需要使用诊断服务，如果无法连接服务器就可能没什么用处了。
- 日志收集服务：还在考虑要不要把所有的日志集中进行上传，用于诊断服务和网管使用。当然，这些数据均不会包含用户数据，不过关于进程检查的还是需要在TOS上强调。
- 管理中心：由于这个系统太过于庞大，因此还是得慢慢考虑和编写，短期要先把专利拿下。
- 私有协议：要想确保安全，底层的通讯协议和部分加密方式还是需要自己设计，同时代码要做好混淆等防逆向工作。私有协议目前还停留在文档阶段，还没有开始施工，主要是存在不定长字段，加上协议使用UDP传输，不像TCP的流式传输一样可以解决重传和长数据问题。UDP数据要控制长度，否则IP层分片容易出现丢失和乱序。正是因为客户端需要发送进程列表，因此这个字段是不定长同时甚至可能是超长，尽管我们建议局域网尽可能使用巨型帧，但是不排除仍然可能会超出长度。以防万一还是需要在协议上做功夫，因此还需要一段时间。
- 用户登录：这个是必备功能了，后边肯定要加的，等不同平台客户端问题解决了就可以了。
- CA安装：这个功能还在考虑做不做，因为一边是隐私问题，一边是国家要求的审计问题。两者相互冲突，用户层面讲需要考虑隐私问题，审计层面讲需要进行完全审计。众所周知，行为审计系统无法应对SSL/TLS加密的内容，但是如果有相应的根证书即可解密，但是这种根证书一般是存在于管理机构，因此审计需要也很难拿到。除了这个办法，还有一种办法是在用户端安装CA证书，可以通过管理员执行的客户端来给客户端证书库安装根证书。
- TAP/TUN隧道：众所周知，IPv4存在广播，因此二层没有做好防护的情况下，可能会存在广播泛洪，影响性能。比较合适的方法是IPv6，IPv6中取消了广播功能，因此安全层面来讲不容易出现IPv4这样的情况。但是在管理角度来讲，由于IPv6可以通过邻间通告自动配置地址，并不方便管理。对此，我们想到了一种先配置，再认证的方式，即客户端使用v6相互通告完成地址和路由配置，使用v6连接到TAP服务器，流量通过单栈v6的TAP隧道传输，客户端TAP接口上配置IPv4地址和v6地址即可，通过客户端下发路由表即可实现相应功能。这样以来，即可解决大多的管理和用户端配置的问题
额外考虑
- 性能问题：上边提到，我们把进程检查任务放到了服务端，尽管在字符匹配上做了相应的优化，但是客户端多的时候服务器压力还是挺高的，因为每次心跳里的进程列表也都需检查，对此正在考虑检查工作要不要下放到客户端。
其他
上述的一些想法是已经在实施中的了，也有的还在规划阶段。是目前博主总结网络管理里得出的一些问题，结合自己的研发经验想到的业务逻辑。