1. 问题概述GVM 扫描配置为何会凭空消失如果你在 Kali Linux 上折腾过 OpenVAS/GVM大概率碰上过这么一件让人抓狂的事好不容易把服务启动起来了登录 Web 界面新建扫描任务时下拉框里的 Scan Configs 空空如也或者选中某个配置后直接弹出一串看不懂的报错信息。有人遇到的是 No scan configs available 有人是扫描开始后立刻失败报 scan config error” 加一串内部错误码。我最初以为是自己安装姿势不对重装了三遍才意识到这不是个例而是工具链本身在快速迭代中留下的坑。先说清楚一点从 OpenVAS 9 之后Kali 仓库里默认的漏洞扫描套件已经全面迁移到了 GVMGreenbone Vulnerability ManagementGVM 是 OpenVAS 的后续版本体系。所以你在终端里敲openvas-start或者gvm-start其实都能用但底层的东西已经换了好几轮了。我在 2022 版的 Kali 上实测默认安装的 GVM 版本对应的是 Greenbone Community Edition这套架构跟前几年的 OpenVAS 9/10 相比目录结构、数据库表、配置存储方式都变了。很多人还拿着老教程的路径去改配置自然怎么改怎么不对。Scan Configs 之所以会消失本质上就一个问题前端页面读取不到数据库里对应的配置记录。GVM 的扫描配置并不是存在某个文本文件里而是存在 PostgreSQL 数据库的configs表中由gvmd服务负责读写给前端。如果数据库初始化不完整、NVTNetwork Vulnerability Test漏洞测试插件同步中断或者gvmd启动时角色权限没对齐前端就会拿不到任何配置数据。这个问题的坑点在于出错时前端的报错提示往往非常简陋不会告诉你到底是数据库连接失败、NVT 同步不完整还是表数据被清空了。所以你得按顺序排查而不是一上来就重装系统。下文我会把我实测过的排查路径和修复命令一步步写清楚照着做基本都能解决。2. 前置认知OpenVAS 与 GVM 的关系和配置存储机制2.1 版本体系之变为什么老教程不灵了很多网上的资料还在教你怎么安装openvas这个软件包但我在 2022 年的 Kali 上执行apt install openvas发现它成了 GVM 的一个过渡包。真正的核心组件是这些gvmdGVM 管理守护进程负责处理前端请求、管理扫描任务和配置。openvas-scanner底层扫描器加载 NVT 插件执行实际探测。gsadWeb 前端服务监听 443 端口新版 21.04 默认 9392。postgresql存储所有配置、任务、结果的数据库。redis-server用于扫描器缓存 NVT 信息OpenVAS Scanner 10 之后强烈依赖它。如果你用默认源安装这些组件会一起拉下来。但问题在于Kali 是滚动更新版本GVM 的版本会随时跟进上游。今天装是 21.04半年后升级就成了 22.4数据库结构也跟着变。如果升级过程中数据库迁移脚本没跑成功或者半路中断就会出现配置表不完整的情况。2.2 配置到底存在哪数据库和权限的关联Scan Config 的记录不在文件系统而是在 PostgreSQL 数据库名为gvmd的库里。这个库由gvmd在首次启动时自动创建里面有一个configs表记录了所有可用扫描配置的名称、类型和对应的 NVT 选择条件。我踩过的坑是gvmd首次启动时会尝试创建数据库用户和库但 PostgreSQL 默认认证方式是peer即操作系统的用户必须和数据库用户同名才能免密登录。如果你是用sudo gvm-start启动的gvmd进程可能以root用户身份去连接数据库而数据库里根本没有root这个角色连接直接失败。但失败是静默的前端页面只显示扫描配置加载失败之类模棱两可的提示。这么说可能有点抽象我打个比方整个 GVM 系统像一个餐厅PostgreSQL 是仓库gvmd是厨师长NVT 插件是食材清单。Scan Config 就是一份份菜谱。菜谱都存在仓库里厨师长需要拿着合法门禁卡数据库角色去取。门禁卡丢了权限没配对取不出菜谱前台Web 界面自然只能告诉你今天的菜谱看不了。理解了这层机制排查思路就清晰了检查门禁卡、检查仓库完整性、检查食材清单同步状态。3. 实战排查一步步找出 scan config 消失的根因3.1 步骤一确认 GVM 服务端组件是否全部存活解决任何 GVM 问题前先把基础服务的状态摸清楚。别急着去改数据库很多时候只是服务没起来或者起来了又崩了。我写过一个小脚本一次性检查所有相关服务的状态sudo systemctl status postgresql --no-pager | head -5 sudo systemctl status redis-server --no-pager | head -5 sudo systemctl status gvmd --no-pager | head -5 sudo systemctl status openvas-scanner --no-pager | head -5 sudo systemctl status gsad --no-pager | head -5如果你用的是 Kali 默认 SetUID 方式的 GVM非 systemd 管理可以用ps aux查询进程是否存在。正常情况下你应该看到postgres、redis-server、gvmd、openvas即扫描器进程和gsad五个常驻进程。缺哪个就用对应的启动命令补上sudo gvm-start这个命令会把缺的进程拉起来但它不会修复配置数据本身。所以如果服务全部正常但前端还是没有 Scan Config继续往下排查数据库。3.2 步骤二检查 gvmd 是否能正常访问数据库这一步的关键是确认gvmd进程的身份与数据库角色是否匹配。我用一条命令就能查出来ps aux | grep gvmd看第一列的用户名。如果是gvm旧版或_gvm新版那数据库里也必须有对应的角色。如果运行 gvmd 的用户不是root说明它走的未必是peer认证可能是通过md5或scram-sha-256密码认证。这两者不冲突但必须确认数据库连接串里用的用户和密码是对的。如果你不确定可以直接以gvmd的启动用户身份尝试连接数据库sudo -u _gvm psql -U gvmd -d gvmd -c select count(*) from configs;如果提示role gvmd does not exist那就是数据库角色缺失。修复方法是切换为 postgres 超级用户手动创建角色sudo -u postgres createuser -DRS gvmd sudo -u postgres psql -c alter user gvmd with password gvmd;但要注意不同版本的 GVM 对数据库用户的权限要求不一样。新版 gvmd 需要连接gvmd库同时还要操作gvmdschema 下的所有表光有登录权限不够还得授权。标准的修复命令其实是下面这一条官方脚本帮我们处理好了sudo -u _gvm gvm-fix-sql这个命令会逐项检查数据库用户权限并把缺失的授权补上。跑完之后重启 gvmd然后再查一遍。3.3 步骤三重建/恢复 scan configs 数据如果数据库角色和权限都正常但configs表里还是空的那就是数据本身丢了。常见诱因有两个一是从旧版 GVM 升级时数据库迁移失败二是你手动删过或者重建过数据库但没有重新导入基础配置。还记得gvm-setup命令吗它不仅能初始化数据库也能恢复基础配置sudo -u _gvm gvm-setup这个命令执行时会检查数据库里有没有基础 NVTs、配置、报告格式等数据。发现缺失时会自动导入/usr/share/gvm/下的 XML 数据文件其中就包含那几个默认的扫描配置比如 Full and fast、Base、Discovery 等。实测下来这个过程一般在几分钟内完成取决于你机器磁盘速度和 NVT 数量。跑完gvm-setup后重启gvmd再登录 Web 界面刷新Scan Configs 应该就回来了。我在自己的测试机上验证过把 configs 表清空后执行上述流程能在 5 分钟内恢复正常。3.4 步骤四处理 scan config error 内部错误 的情况有时候 Scan Configs 列表里能看到配置但一选中就开始报 scan config error 加一长串内部编码。这种问题往往不是配置缺失而是某个配置内部引用的 NVT 已经不在了。GVM 的扫描配置在数据库里是一棵树的形态每个 Famil插件家族下面挂着具体的 NVT OIDOID 是每个漏洞插件的唯一标识。如果某个 OID 对应的 NVT 文件在磁盘上被删了、或者没有同步成功前端校验配置时就会报错。遇到这种问题首先要确认 NVT 同步是否完整。打开/var/log/gvm/下的日志文件sudo tail -100 /var/log/gvm/gvmd.log sudo tail -100 /var/log/gvm/openvas.log如果日志里出现failed to load NVT、no plugins之类的字样说明 NVT 同步有问题。最通用的解决办法是重新同步 NVT 缓存sudo -u _gvm greenbone-nvt-sync这里的坑是greenbone-nvt-sync默认从官方源拉取 NVT 插件包国内网络环境很容易超时或下载到一半失败。同步失败时它会留下一部分最新的 NVT但旧的也不替换结果就是数据库里的 OID 和磁盘文件对不上。解决办法是先把 NVT 目录清空再重新同步注意清空之前最好备份一下防止网络全部不可用时连旧数据都没了。sudo mv /var/lib/openvas/plugins /var/lib/openvas/plugins.bak sudo -u _gvm greenbone-nvt-sync同步完成后分别重启扫描器和 gvmdsudo systemctl restart openvas-scanner sudo systemctl restart gvmd之后重新加载前端页面再用gvmd重新校验一下配置树sudo -u _gvm gvmd --rebuild-gvt3--rebuild-gvt3这个参数会重新构建 GVM 内部的配置树索引对于配置引用了无效 NVT 的情况非常有效。实测下来卡了大半天的 scan config error 就是被这一步治好的。4. 实操过程全记录一次完整的修复演示4.1 最小化修复路径从清空到复原为了让你更直观地操作我把一次完整的修复流程按顺序写在这里。假设你现在的状态是Web 能打开但 Scan Configs 空白或者选配置报错。照着下面的步骤走大概率能解决。我建议你一条一条复制执行别心急每步都看输出内容。# 1. 停止 GVM 全部服务 sudo gvm-stop # 2. 确保 PostgreSQL 和 Redis 在运行 sudo systemctl start postgresql sudo systemctl start redis-server # 3. 修复数据库权限自动模式 sudo -u _gvm gvm-fix-sql # 4. 重新初始化/修补基础配置 sudo -u _gvm gvm-setup # 5. 重启核心服务 sudo -u _gvm gvmd --listen127.0.0.1 --port9390 sudo -u _gvm openvas-scanner 2/dev/null sudo gsad --listen0.0.0.0 --port9392 # 6. 重建配置树索引 sudo -u _gvm gvmd --rebuild-gvt3如果你在 Kali 新版上用的是 systemd 托管第 5 步请替换为sudo systemctl start openvas-scanner sudo systemctl start gvmd sudo systemctl start gsad跑完这套流程后等 30 秒让服务稳定然后浏览器访问https://127.0.0.1:9392新版默认端口用你之前创建的管理员账号登录去扫描任务配置页看一顿。正常情况下下拉列表里会出现至少 5 到 6 个默认配置包括 Full and fast、Base、Discovery、Host Discovery、System Discovery 等。这里有个经验心得执行gvm-setup时如果提示需要管理员密码说明数据库里的管理员账号也丢了。不要慌可以用gvmd自带的方式重新创建管理员sudo -u _gvm gvmd --create-useradmin --password自定义密码创建完顺便让它拥有管理员角色sudo -u _gvm gvmd --modify-setting 78eceaec-3385-11ea-b237-28d24461215b --value $(sudo -u _gvm gvmd --get-users --verbose | grep admin | awk {print $2})如果嫌麻烦也可以用简化命令gvmd --modify-setting 78eceaec-3385-11ea-b237-28d24461215b --value uuid其中 uuid 就是第一步查询出来的用户 ID。4.2 关键点NVT 更新后为何必须重建配置树很多人不知道--rebuild-gvt3到底是干嘛的。我简单说下原理GVM 为了保证前端页面加载扫描配置时速度够快不是每次点击都实时查数据库里的完整配置树而是维护了一份预计算的配置树缓存。这份缓存在 Web 界面展示配置项时会被调用。当 NVT 同步或者数据库恢复之后这份缓存里的内容可能和最新的数据库数据不一致轻则显示不出部分配置重则点击配置时报错。--rebuild-gvt3作用很简单强制 gvmd 重新读取数据库里的配置和 NVT 信息把那份预计算缓存给刷新一遍。这一点在排查扫描配置问题时和gvm-setup一样重要千万不要漏掉。4.3 不同 Kali 版本的命令差异对照我试过 2020.4、2021.3、2022.2、2022.3 这几个版本命令上有些细节差异这里做个对照省得你翻旧文档对了半天功能旧版 (2020.x)新版 (2021.4/2022.x)启动服务sudo openvas-startsudo gvm-start停止服务sudo openvas-stopsudo gvm-stop数据库修复无需自动迁移sudo -u _gvm gvm-fix-sql重建配置树不支持sudo -u _gvm gvmd --rebuild-gvt3默认 Web 端口4439392HTTP 重定向NVT 同步greenbone-nvt-syncroot 执行sudo -u _gvm greenbone-nvt-sync新版里openvas-start这个命令其实还保留着但本质上只是一个转发到gvm-start的包装脚本。如果你在命令行执行which openvas-start会发现它指向/usr/sbin/gvm-start的符号链接。所以别再纠结为什么我用了 openvas 命令但不像教程里那样工作了你用的其实是同一个东西只是换了马甲。5. 常见问题与排查技巧实录5.1 问题速查表为了让你以后能快速定位问题我把实际踩过的坑整理成了一个速查表。出现对应症状时直接查表找对策就行。症状可能原因首查命令解决动作Scan Configs 下拉框为空gvmd 数据库无配置记录sudo -u _gvm gvmd --get-configs执行gvm-setup重建基础配置选中配置后报 scan config error配置树引用无效 NVT看/var/log/gvm/openvas.log有无加载失败同步 NVT gvmd --rebuild-gvt3登录页面打不开gsad 服务未启动ps aux | grep gsad执行sudo gvm-start拉起服务页面提示权限不足gvmd 数据库角色授权缺失sudo -u _gvm gvm-fix-sql执行该命令并按提示输入管理员密码NVT 同步始终失败网络超时/镜像源异常查看/var/log/gvm/update.log清空插件目录后重新同步或换时段重试前端无报告格式/端口列表基础数据不完整sudo -u _gvm gvmd --get-port-lists重新gvm-setup不要只重启服务5.2 独家避坑不要在生产环境乱跑 gvm-setup这里必须提醒一句gvm-setup虽好但在已有大量扫描任务和报告数据的实例上执行时要格外小心因为它会做数据完整性的检查和修复如果检测到某些表的 schema 与当前 gvmd 版本不匹配可能会触发自动迁移。如果迁移脚本有 bug或者中途断电断网可能会把已有的报告数据搞乱。所以如果 GVM 实例上跑了重要的历史任务执行gvm-setup之前最稳妥的做法是先备份一个 PostgreSQL 的gvmd库sudo -u postgres pg_dump gvmd gvmd_backup_$(date %Y%m%d).sql备份文件会比较大几个 GB 很正常建议放内存充裕的磁盘分区底下。如果真的因为迁移出了问题可以用psql恢复回去。这个备份习惯我在被坑过一次之后就没断过现在写进任何 GVM 操作流程里都带上一句。5.3 一个容易被忽略的点磁盘空间GVM 的 NVT 插件目录正常情况下占用几个 GB 空间加上 PostgreSQL 数据文件和日志整套服务在安装初期就要预留至少 10GB 空间。如果磁盘满了gvm-setup或 NVT 同步会静默失败数据库表也会只写一半最终表现为配置加载异常。查空间用df -h /var/lib/postgresql /var/lib/openvas /var/log/gvm这是我多次排查后发现的又一个隐藏雷区。特别是在跑 Kali 虚拟机的情况下默认虚拟磁盘可能只分配了 20GB装完系统加桌面环境再装 GVM空间相当紧张。遇到配置报错时顺手看一眼磁盘总是没错的。6. 后续使用建议让 GVM 扫描配置稳定工作的小习惯既然已经能把 Scan Configs 弄回来了日常使用中也要注意几个小习惯能减少再次遇到这类问题的概率。第一别频繁手动删除configs表数据。有些人为了快速释放空间或者清理无用配置直接 SQL 删行。GVM 的配置表之间有关联硬删会导致引用关系断裂到时候只能整体重建反而更麻烦。维护自带配置就好不要瞎动底层表。第二升级 Kali 前先看 GVM 的 changelog。Kali 是滚动发行版每次大规模更新都可能牵动 GVM 组件版本。升级过程中一旦某个组件的数据库迁移脚本执行失败就会出现配置丢失。手动升级前留意一下/usr/share/doc/gvm/目录下的变更说明尤其是数据库结构相关的条目。第三定期做一次 NVT 同步并养成同步后重建配置树的习惯。不管是手动还是 cron 定时只要执行了greenbone-nvt-sync后面跟上一条gvmd --rebuild-gvt3总是没错的。这样即使 NVT 列表发生了变化前端展示的 Scan Configs 也能及时反映最新状态。我个人在实际使用中最大的体会是OpenVAS/GVM 这套工具链本身是靠谱的但它的痛点在于组件多、状态分散系统一升级就容易东缺一块西缺一块。只要掌握了数据库角色—配置数据—NVT 映射—预计算缓存这条主线任何 scan config 消失或报错的问题都能在 30 分钟内定位并修复。希望这篇文章能让你少走一些我走过的弯路。