简介：这份资源围绕 ip-guard 网络监控与管理工具展开，面向企业 IT 运维、网络管理员以及需要部署终端行为审计与上网行为管理的技术人员，帮助解决内网监控、权限管控与员工上网行为记录等实际问题。压缩包为 rar 格式，整体约 33.39MB，包内文件数量与具体类型上游未提供明细，故不展开说明。资源标题标注为 406 用户版本，作者自述已使用一年，说明其在真实环境中经过一定周期验证，对想了解该工具部署与使用思路的读者具备参考意义。目前已有 1407 人浏览学习，属于同类工具资源中关注度较高的内容。读者可借助该资源了解 ip-guard 在终端监控、网络行为管理方面的功能定位与配置方向，结合自身企业网络规模评估适用性，并作为搭建内网监控体系的入门参考，适合具备一定网络基础、希望快速上手管理利器的运维人员查阅。
1. 从一次内网排查说起：为什么我又把 ip-guard 翻了出来
去年帮一个朋友处理他们内部网络的异常外联问题，当时手头没有现成的流量审计工具，临时装了一套开源方案，结果在终端行为采集这一层卡了整整两天——进程链抓不全、屏幕操作录不到、U盘拷贝记录缺失。后来一个做企业IT运维的老哥丢给我一份 ip-guard 的部署包，说你先拿这个把底摸清楚。装完跑了一周，终端侧的行为日志颗粒度确实比我之前那套拼凑方案细得多，尤其是文档操作和即时通讯内容的留存，基本能做到事后可回溯。
这次经历让我意识到，ip-guard 这类网络监控与管理工具，在中小规模内网里依然有它不可替代的位置。但网上关于它的资料要么是厂商白皮书式的功能罗列，要么是零散的破解讨论，真正从部署、配置到日常运维的完整记录很少。这篇内容不聊破解，只聊我在实际环境里怎么把它跑起来、哪些参数值得调、哪些坑我踩过。如果你正在做内网行为管理选型，或者手头已经有一套 ip-guard 但只用到了皮毛，下面这些记录应该能帮你省掉不少试错时间。
2. 部署前想清楚：ip-guard 到底管什么、不管什么
2.1 它的能力边界在哪里
很多人第一次接触 ip-guard，会把它当成一个单纯的“监控软件”，这个理解太窄了。从我这几次部署的经验看，它实际覆盖的是终端行为管理 + 网络准入 + 文档加密三条线。终端行为管理包括进程记录、窗口标题采集、屏幕快照、文件操作审计、打印记录、即时通讯内容留存；网络准入控制的是终端能不能连内网、能不能访问外网、能访问哪些网段；文档加密则是对指定后缀的文件做透明加解密，离开授权环境就打不开。
但它的短板也很明显。第一，对加密流量的解析能力有限，如果内网大量使用 HTTPS 且没有做证书中间人，内容层面的审计会打折扣。第二，服务端性能对数据库依赖很重，SQL Server 的版本和索引优化直接影响控制台响应速度。第三，客户端对操作系统的兼容性在不同版本间有差异，老版本 Windows 和最新版 Windows 11 的驱动签名策略经常打架。
我一般会这么判断：如果你需要的是“谁在什么时候动了什么文件、发了什么消息、插了什么U盘”，ip-guard 能覆盖；如果你要的是“深度包检测 + 应用层协议识别”，那它不如专业的 NDR 或全流量审计设备。
2.2 部署架构的三种常见形态
实际落地时，ip-guard 的部署架构大致分三种。第一种是单服务器全量部署，服务端、数据库、控制台全在一台机器上，适合 200 终端以内的场景。第二种是服务端与数据库分离，数据库单独一台，服务端只跑应用，适合 500 终端左右。第三种是多级级联，总部一套主服务端，分支机构各跑一套从服务端，数据定时回传，适合跨地域的中大型内网。
我这次跑的是第二种，服务端 Windows Server 2019，数据库 SQL Server 2017，终端数峰值 380 左右。选这个架构的原因很简单：控制台查询日志时，数据库 IO 是瓶颈，分离之后查询响应从平均 4 秒降到了 1 秒以内。
2.3 授权与用户数的关系
标题里提到的“406用户”这个数字，我理解是指授权终端数。ip-guard 的授权模式是按终端点数算的，服务端不限制管理账号数量，但每个被管理的终端都要占一个授权。实际部署时要注意，授权文件导入后，控制台显示的“已授权点数”和“已注册终端数”是两个概念。已注册终端数可以超过授权点数，但超出的终端会进入“未授权”状态，策略不生效。
我遇到过一种情况：测试阶段反复重装客户端，导致服务端里残留了大量重复的终端记录，占用了授权点数。解决办法是在控制台里先删除无效终端记录，再重新注册。这个操作在“终端管理”里做，删除时勾选“同时删除该终端的日志”，否则数据库会越跑越大。
3. 服务端与数据库配置：几个影响性能的关键参数
3.1 数据库连接池与超时设置
ip-guard 服务端和 SQL Server 之间的连接池配置，直接决定了高并发时控制台会不会卡死。默认安装后，连接池最大连接数通常是 100，超时 30 秒。在 300 终端以上的环境里，这个值偏小。我一般会调到 300 连接、超时 60 秒。
调整位置在服务端安装目录下的ServerConfig.xml，找到<Database>节点：
<Database> <MaxPoolSize>300</MaxPoolSize> <ConnectionTimeout>60</ConnectionTimeout> <CommandTimeout>120</CommandTimeout> </Database>MaxPoolSize控制同时打开的数据库连接上限，ConnectionTimeout是建立连接的超时秒数，CommandTimeout是单条 SQL 执行的超时。改完重启服务端服务生效。注意不要盲目调太大，SQL Server 的max worker threads默认是 0（自动），如果连接数超过 CPU 核心数的几十倍，反而会因上下文切换导致性能下降。
3.2 日志分区与清理策略
ip-guard 的日志表增长非常快。一个 300 终端的环境，如果开启了屏幕快照和即时通讯内容留存，数据库每天增量在 2GB 到 5GB 之间。如果不做分区和清理，三个月后查询就会明显变慢。
我的做法是两步。第一步，在 SQL Server 里对日志主表按周做分区，分区函数按LogTime字段切分。第二步，在 ip-guard 控制台的“系统设置”里开启自动清理，保留周期设为 90 天。注意自动清理任务默认是每天凌晨 2 点执行，如果数据库压力大，可以改成每周一次，但保留周期要相应缩短。
-- 查看当前日志表大小和行数 SELECT t.name AS TableName, p.rows AS RowCounts, SUM(a.total_pages) * 8 / 1024 AS TotalSpaceMB FROM sys.tables t INNER JOIN sys.indexes i ON t.object_id = i.object_id INNER JOIN sys.partitions p ON i.object_id = p.object_id AND i.index_id = p.index_id INNER JOIN sys.allocation_units a ON p.partition_id = a.container_id WHERE t.name LIKE '%Log%' GROUP BY t.name, p.rows ORDER BY TotalSpaceMB DESC;这段 SQL 用来定位哪些日志表占用空间最大。通常AgentLog、ScreenLog、IMLog这三张表是增长主力。如果ScreenLog过大，可以考虑降低屏幕快照的采集频率，从默认的 5 分钟一次改成 15 分钟一次。
3.3 控制台访问的权限模型
ip-guard 控制台的权限分三级：超级管理员、策略管理员、审计员。超级管理员什么都能改；策略管理员只能改策略不能看日志；审计员只能看日志不能改策略。实际使用时，建议给日常运维人员只开审计员权限，策略变更走审批流程。
我见过一个翻车案例：某公司把超级管理员账号给了三个运维，结果其中一个人误删了一条全局策略，导致所有终端的U盘管控失效，第二天才发现。后来他们改成策略管理员只能提交变更申请，超级管理员审批后才生效。这个流程在控制台的“权限管理”里配置，支持对接 LDAP 做统一认证。
4. 客户端策略配置：从进程审计到文档加密的实操
4.1 进程与窗口标题采集的粒度控制
客户端策略里最常用的是进程审计。ip-guard 默认会记录所有进程的启动和退出，但窗口标题采集默认是关闭的。开启后，每个进程的窗口标题变化都会产生一条日志，数据量会翻倍。
我的建议是：只对敏感进程开启窗口标题采集。比如财务软件、代码编辑器、即时通讯工具，其他如浏览器、系统进程只记录进程名和路径即可。配置路径在“策略模板” -> “进程审计” -> “高级设置”里，可以按进程名做白名单。
; 进程审计白名单示例（只采集以下进程的窗口标题） [WindowTitleCapture] ProcessList=finapp.exe,code.exe,wechat.exe,dingtalk.exe CaptureInterval=30CaptureInterval是窗口标题的采集间隔秒数，默认 10 秒，调到 30 秒可以降低日志量。注意这个配置是客户端本地的，服务端下发策略后会覆盖，所以要在服务端策略里改。
4.2 文档透明加密的密钥管理
文档加密是 ip-guard 里最敏感的功能。开启后，指定后缀的文件在授权进程里打开是明文，在非授权进程里打开是密文。密钥存在服务端的数据库里，客户端启动时从服务端拉取。
这里有一个血泪经验：密钥备份一定要做，而且要在开启加密之前做。我遇到过服务端数据库损坏导致密钥丢失的情况，结果所有加密文档都打不开了。后来每次部署，我都会在开启加密前先导出一份密钥文件，存在离线介质里。
导出方式在控制台的“文档加密” -> “密钥管理” -> “导出密钥”，导出的文件是加密的，需要设置一个保护密码。这个密码和密钥文件要分开存放，否则一起丢了就真没后悔药了。
4.3 网络准入与例外名单
网络准入控制的是终端能不能上网、能访问哪些IP。默认策略是“禁止所有外网访问，只允许内网指定网段”。实际配置时，例外名单比黑名单更常用。
比如研发部门需要访问代码托管平台，但不想让他们访问视频网站。做法是：先建一个“研发例外”策略组，在“网络控制”里添加允许访问的域名和IP段，其他一律禁止。注意 ip-guard 的域名过滤是基于 DNS 解析结果的，如果终端直接填 IP 访问，域名策略不生效，所以还要配合 IP 段过滤。
# 查看客户端当前生效的网络策略（在客户端安装目录下执行） AgentCLI.exe /querypolicy network # 输出示例： # PolicyName: R&D_Exception # AllowDomains: git.internal.com, repo.internal.com # AllowIPs: 10.10.0.0/16, 172.16.1.0/24 # DefaultAction: Block这个命令在客户端本地执行，用来确认策略是否下发成功。如果输出为空，说明客户端没有连上服务端，需要检查客户端的“服务端地址”配置和网络连通性。
5. 避坑记录：这五个问题我踩过，你不用再踩
5.1 客户端安装后蓝屏或反复重启
现象：在部分 Windows 10 机器上安装客户端后，系统蓝屏，错误码DRIVER_IRQL_NOT_LESS_OR_EQUAL，重启后进入恢复模式。
原因：客户端的文件过滤驱动和某些安全软件（如某杀毒软件的主动防御模块）冲突，或者和 Windows 自带的Filter Manager版本不匹配。
解决：先在安全模式下卸载冲突的安全软件，再安装 ip-guard 客户端。如果已经蓝屏，用 Windows 安装U盘启动进入修复模式，删除C:\Windows\System32\drivers\下 ip-guard 的驱动文件（通常以ipg开头），然后正常启动后重新安装。安装前建议先打上最新的 Windows 累积更新，驱动签名兼容性会好很多。
5.2 控制台登录提示“数据库连接失败”
现象：服务端服务启动正常，但控制台登录时提示数据库连接失败，日志里报Login failed for user 'ipguard'。
原因：SQL Server 的认证模式是“仅 Windows 认证”，而 ip-guard 用的是 SQL 账号认证。或者 SQL Server 的 TCP/IP 协议没启用。
解决：在 SQL Server 配置管理器里，把协议中的 TCP/IP 启用，端口保持 1433。然后在 SSMS 里把服务器认证模式改成“SQL Server 和 Windows 身份验证模式”，重启 SQL Server 服务。最后确认 ip-guard 使用的数据库账号有db_owner权限。
5.3 屏幕快照日志占满磁盘
现象：服务端磁盘空间告警，检查发现ScreenLog表所在的数据文件已经 200GB。
原因：屏幕快照默认每 5 分钟一次，且默认保留 180 天。300 终端的环境下，一天就能产生几万张图片。
解决：两步走。第一步，在控制台把屏幕快照频率改成 15 分钟，保留周期改成 30 天。第二步，在 SQL Server 里对ScreenLog表做分区，把历史分区切到单独的磁盘。如果已经占满，先手动清理 90 天前的记录，再收缩数据库文件。
-- 清理 90 天前的屏幕快照记录（分批执行，避免锁表） WHILE 1 = 1 BEGIN DELETE TOP (10000) FROM ScreenLog WHERE LogTime < DATEADD(DAY, -90, GETDATE()); IF @@ROWCOUNT < 10000 BREAK; WAITFOR DELAY '00:00:01'; END分批删除是为了避免一次性删除大量数据导致事务日志暴涨和锁表。WAITFOR DELAY让每批之间停 1 秒，给其他查询留出资源。
5.4 客户端离线后策略不生效
现象：笔记本带出公司后，U盘管控策略失效，可以随意拷贝文件。
原因：ip-guard 的默认策略是“在线生效”，客户端连不上服务端时，策略回退到“全部允许”。
解决：在策略模板里开启“离线策略”，设置离线有效期（比如 7 天）。离线期间，客户端使用本地缓存的策略，U盘管控和文档加密继续生效。超过有效期后，客户端锁定，需要连回服务端才能解锁。这个配置在“策略模板” -> “高级设置” -> “离线策略”里。
5.5 数据库备份恢复后日志丢失
现象：服务端数据库崩溃后从备份恢复，发现恢复点之后的所有日志都没了。
原因：SQL Server 的恢复模式是“简单”，只支持完整备份，不支持事务日志备份。ip-guard 的日志写入是实时的，简单模式下备份间隔内的数据会丢失。
解决：把数据库恢复模式改成“完整”，然后配置每日完整备份 + 每 15 分钟事务日志备份。这样最多丢 15 分钟的数据。注意事务日志文件会持续增长，需要定期做日志截断。
-- 查看当前恢复模式 SELECT name, recovery_model_desc FROM sys.databases WHERE name = 'ipguard'; -- 改成完整恢复模式 ALTER DATABASE ipguard SET RECOVERY FULL; -- 做一次完整备份（路径按实际改） BACKUP DATABASE ipguard TO DISK = 'D:\Backup\ipguard_full.bak' WITH INIT; -- 做一次事务日志备份 BACKUP LOG ipguard TO DISK = 'D:\Backup\ipguard_log.trn' WITH INIT;改完恢复模式后，必须做一次完整备份，否则事务日志备份会失败。之后用 SQL Server 代理作业定时执行这两条命令即可。
6. 回到那个 406 用户的场景：我的最终配置清单和一条硬习惯
那个 380 终端的环境跑稳之后，我把整套配置整理成了一份清单。服务端 Windows Server 2019，SQL Server 2017 分离部署，连接池 300、超时 60 秒，日志保留 90 天、屏幕快照 15 分钟一次，文档加密密钥离线备份两份，网络准入按部门分策略组。客户端统一用静默安装包推送，安装前先卸载冲突安全软件，安装后重启一次再注册。
这套配置跑了一年多，控制台查询响应稳定在 1 秒左右，数据库月增量控制在 60GB 以内，没有出现过蓝屏或策略失效的批量故障。中间有一次服务端磁盘告警，靠分区切换和分批清理扛过去了，没有影响终端使用。
回过头看，ip-guard 这类工具的价值不在于功能有多花哨，而在于策略能不能稳定执行、日志能不能可靠回溯。我现在的习惯是：每次开启一个新策略之前，先在一台测试终端上跑 48 小时，确认没有兼容性问题再批量下发。这个习惯帮我避开了至少三次可能的批量故障。另外，密钥备份和数据库完整备份这两件事，我强制自己在上线前必须做完，不做完不开加密功能。希望这些记录能帮到你。
本文还有配套的精品资源，点击获取
