Reconya：当网络侦察遇上现代Web技术——一款让资产发现变得直观的开源工具

本文欲回答的核心问题

网络管理员和安全研究者如何在不部署重量级系统的前提下，快速建立起对自己网络中活跃设备的可视化认知？Reconya通过Go语言的高性能后端与HTMX的轻量级前端架构，提供了一种既专业又易用的网络资产发现方案。

在数字化基础设施日益复杂的今天，即使是家庭用户也可能拥有数十个联网设备。从智能音箱到nas存储，从物联网传感器到开发测试机，这些资产往往处于”可见但不可知”的状态——我们知道它们存在，却缺乏统一的管理视图。Reconya正是为解决这一现代网络的”盲点焦虑”而生。它不是一个笨重的企业级网管平台，而是一个精准定位在”侦察与发现”维度的轻量级工具，用开发者友好的技术栈实现了生产级功能。

一、项目定位：为什么我们需要新一代网络侦察工具？

本段欲回答的核心问题

相比传统网络扫描工具，Reconya究竟解决了哪些实际痛点？

传统网络管理工具往往陷入两个极端：一端是nmap这类功能强大但输出晦涩的命令行工具，另一端是SolarWinds或Nagios这类部署复杂、资源消耗巨大的企业平台。对于安全研究人员、中小型企业网管以及技术型家庭用户而言，两者都不理想。

Reconya找到了一个精准的需求空隙：在保持专业级扫描能力的同时，提供实时的、可视化的、无需复杂配置的设备发现体验。它的价值不在于替代现有的监控告警体系，而在于快速回答几个核心问题：我的网络上现在有什么设备？它们的身份信息是什么？状态如何变化？

实际应用场景：想象你是一名远程工作的开发者，家里运行着树莓派集群、测试服务器和各种智能家居设备。某天网络突然变慢，你怀疑有未授权设备接入。打开Reconya仪表盘，30秒内所有活跃设备及其MAC地址、供应商信息一目了然，异常设备无处遁形。这种即时洞察能力，是传统工具无法提供的流畅体验。

个人反思：在测试Reconya的过程中，我意外发现自己网络中竟有一个被遗忘的三年前的旧手机仍在自动连接Wi-Fi，默默消耗着带宽。这让我意识到，资产发现的真正价值不在于发现已知，而在于揭示遗忘——那些你以为已经下线的设备，往往才是安全隐患的温床。

二、核心功能矩阵：从IPv4到IPv6的完整覆盖

本段欲回答的核心问题

Reconya提供了哪些具体功能，这些功能如何在不同场景下发挥作用？

功能模块 技术实现 适用场景 数据更新频率
IPv4主动扫描 nmap集成+ICMP/TCP探测 企业内网、家庭网络初始发现 每30秒循环
IPv6被动监控 NDP监听+接口监控 IPv6环境设备静默发现 实时被动
设备指纹采集 MAC OUI库+OS探测+服务识别 安全审计、资产清点 扫描时触发
双栈地址管理 MAC地址关联IPv4/IPv6 混合网络环境统一视图 实时关联
Web服务截图 Headless Chrome自动捕获 快速识别Web管理界面 后台异步
事件日志流 实时WebSocket推送 监控异常上线/离线 实时

2.1 IPv4网络扫描：不止于Ping

Reconya的IPv4扫描并非简单的ping sweep。它采用分层策略：优先使用nmap的特权模式进行ICMP扫描，若权限不足则自动降级为TCP连接探测，目标端口包括80、443、22等常见服务端口。这种自适应机制确保了在不同运行环境下都能获得最佳发现效果。

场景示例：在一次渗透测试预侦察中，测试人员将Reconya部署在客户内网。由于容器环境限制，nmap无法获取raw socket权限，工具自动切换到TCP探测模式，成功发现了防火墙后方仅开放8080端口的打印机管理界面——这个设备不会响应ICMP，但TCP探测让它无所遁形。

2.2 IPv6被动监控：静默中的洞察

IPv6部署率低的一个重要原因是管理工具的滞后。Reconya的IPv6模块采用纯被动监听，不产生任何探测流量，通过捕获Neighbor Discovery Protocol (NDP)报文和监控本地接口的IPv6地址分配，实现在IPv6网络中的设备发现。

三种地址类型的识别逻辑：

  • Link-Local地址（fe80::/10）：链路层通信，Reconya通过监听RA/RS报文捕获
  • Unique Local地址（fc00::/7）：类似IPv4的私有地址，用于内网隔离环境
  • Global地址（2000::/3）：公网可路由地址，暴露面分析的关键

场景示例：某高校网络中心需要审计校园网IPv6部署情况。传统扫描工具会因IPv6地址空间巨大而失效。部署Reconya后，通过一周被动监听，准确绘制出各楼宇的IPv6设备分布图，发现大量IoT设备自动获取Global地址带来的潜在暴露风险。

个人反思：IPv6监控的”被动”哲学让我重新思考安全工具的本质。最好的侦察是不被察觉的侦察。在攻防对抗场景中，主动扫描会触发IDS告警，而被动监听如同”网络显微镜”，只观察不改变，这在高级持续威胁(APT)检测中价值非凡。

2.3 设备身份多维识别

Reconya不满足于IP和MAC层面的发现。它对每个设备构建多维身份档案：

  • 物理层：MAC地址+IEEE OUI供应商查询（自动匹配”Intel”或”Hon Hai”等厂商）
  • 网络层：通过反向DNS、mDNS、NetBIOS多管齐下解析主机名
  • 系统层：nmap OS指纹库识别操作系统（Linux 3.x、Windows 10等）
  • 服务层：端口扫描+banner抓取+Web截图，形成服务拓扑

场景示例：在家庭网络中，Reconya不仅识别出”192.168.1.105″这个IP，更揭示其完整身份：”这是一台运行Raspbian的树莓派，主机名pi-hole，开放了53、80端口，Web界面运行着Pi-hole广告拦截服务，供应商是Raspberry Pi Foundation”。这种细粒度信息对故障排查至关重要。

三、安装部署决策：为什么本地安装是唯一推荐路径

本段欲回答的核心问题

Reconya为何明确不推荐Docker部署？本地安装的具体步骤有哪些？

项目维护者在文档中毫不避讳地将Docker支持标记为experimental，这源于一个底层技术事实：Docker的网络命名空间隔离机制阻断了二层(L2)网络访问。容器内的进程无法直接访问宿主机的ARP表，也无法发送链路层帧进行MAC地址发现。即使使用--privileged和--network host模式，跨网段MAC发现依然不可靠。

技术决策的诚实性值得赞赏。许多项目为了迎合云原生潮流，勉强提供功能残缺的容器镜像，反而误导用户。Reconya团队明确建议：需要完整功能，请使用本地安装。

3.1 一键安装脚本：自动化背后的考量

Reconya提供了install.sh脚本，支持macOS、Windows、Debian系和Red Hat系发行版。脚本不仅安装Go、Node.js和nmap，更关键的是自动配置nmap的setuid权限——这是MAC地址发现的核心前提。

git clone https://github.com/Dyneteq/reconya.git
cd reconya
./install.sh

脚本执行逻辑：

  1. 环境探测：识别操作系统类型和已有依赖版本
  2. 依赖安装：调用系统包管理器（brew/apt/yum）安装缺失组件
  3. 权限配置：执行chmod u+s $(which nmap)赋予nmap raw socket能力
  4. 应用部署：下载Go依赖、编译二进制、安装Node模块
  5. 服务注册：创建systemd或LaunchAgent服务（视系统而定）

场景示例：一位网管需要在10台Linux监控节点部署Reconya。手动操作重复且易错。通过Ansible调用install.sh，配合自定义的.env配置模板，30分钟内完成全集群部署，且权限配置一致，避免了因nmap权限不足导致扫描结果缺失的常见问题。

3.2 手动安装：理解底层机制

对于喜欢掌控细节的用户，手动安装提供了透明性：

# 1. 基础依赖安装（以Ubuntu为例）
sudo apt-get install nmap golang nodejs

# 2. 关键权限配置
sudo chown root:admin $(which nmap)
sudo chmod u+s $(which nmap)

# 3. 应用配置
cd backend
cp .env.example .env
# 编辑.env文件修改默认密码

# 4. 启动服务
go mod download
go run ./cmd

Windows用户的特殊处理：由于SQLite需要CGO支持，Windows用户可能遇到编译错误。项目贴心地提供了.bat脚本，并明确建议使用CGO_ENABLED=1标志。这反映出团队对跨平台兼容性的务实态度——不求完美统一，但提供明确解决方案。

个人反思：一键脚本和手动安装两条路径的设计体现了”渐进式复杂度”理念。新手需要快速见效，专家需要理解原理。作为曾踩过无数”自动化脚本坑”的运维者，我强烈建议即使在生产环境使用脚本安装，也应先通读脚本内容，理解其权限操作逻辑。安全与便利的平衡点在于知情同意。

四、从零到一：Reconya的使用旅程

本段欲回答的核心问题

完成安装后，如何一步步将Reconya投入实际使用？

4.1 初始访问与安全加固

安装完成后，服务默认监听http://localhost:3008（注意：非3000端口，3000端口由前端开发服务器使用）。默认凭证是admin/password，这是一个必须立即修改的安全风险。

安全加固路径：

  1. 首次登录后，立即编辑backend/.env文件
  2. 修改LOGIN_PASSWORD为强密码（或同时修改用户名）
  3. 更改JWT_SECRET_KEY（使用openssl rand -hex 32生成）
  4. 重启服务使配置生效

场景示例：某安全研究员在VPS上部署Reconya用于监控蜜罐网络。若使用默认密码，扫描结果可能被未授权访问，泄露敏感资产信息。通过脚本自动化部署时，在install.sh运行后自动注入随机生成的密码，确保每次部署凭证唯一。

4.2 网络配置的艺术

Reconya支持多网络管理，这意味着你可以同时监控多个网段（如VLAN隔离的办公网、访客网、DMZ区）。

配置最佳实践：

  • 使用CIDR表示法（如192.168.1.0/24）而非IP范围，语义更清晰
  • 对于家庭用户，从单个/24子网开始
  • 企业用户可创建多个网络配置，按扫描频率区分（DMZ区每5分钟，办公网每30秒）

核心操作流：

登录 → 仪表盘 → 添加网络 → 输入CIDR和描述 → 选择网络 → 点击"开始扫描"

扫描启动后，仪表盘会实时显示发现的设备。不同于传统工具的一次性输出，Reconya会持续监控设备在线状态，新设备上线时会触发WebSocket推送，在UI中高亮显示。

4.3 设备详情深度挖掘

点击任意设备卡片，进入详情页。这里的信息密度决定侦察深度：

  • MAC与供应商：识别设备制造商，快速区分”_intel”无线网卡与”Espressif”物联网模块
  • 主机名解析：多方法聚合结果，若mDNS显示”living-room-tv.local”而NetBIOS显示”ANDROID-TV”，可判断其为安卓智能电视
  • 开放端口：不仅列出端口，更通过banner抓取显示服务版本（如OpenSSH 7.4）
  • 操作系统指纹：nmap OS检测给出置信度评分，如”Linux 3.7-3.10 (95%)”
  • Web截图：对于80/443/8080等服务，自动捕获页面截图，一眼识别路由器管理页或NAS登录界面

场景示例：在排查内网异常流量时，通过Reconya发现某设备开放了9999端口且截图显示为”ESPHome”界面。结合MAC供应商”Espressif”，快速定位到是智能灯泡固件缺陷导致不断发包。传统nmap扫描需要手动访问验证，而截图功能将排查时间从5分钟缩短到30秒。

五、技术内幕：扫描算法与性能考量

本段欲回答的核心问题

Reconya如何在保证发现完整性的同时控制网络负载？

5.1 四层扫描策略详解

Reconya的扫描不是单点操作，而是有状态的多层流水线：

第一层：网络发现（30秒间隔）

  • 主策略：nmap -sn (ping scan)，利用raw socket发送ICMP echo、timestamp、netmask请求
  • 回退策略：TCP SYN到80, 443, 22, 21, 23, 25, 53, 135, 139, 445等端口
  • L2补充：读取系统ARP表，捕获近期通信设备的MAC（即使不响应扫描）

第二层：设备识别（异步任务）

  • 对发现的IP，启动goroutine池并行处理
  • MAC地址通过ARP请求获取，若跨网段则依赖路由器ARP代理
  • 主机名同时发起DNS PTR、mDNS (._tcp.local)、NetBIOS查询，最快响应者胜出
  • OS探测使用nmap -O模式，发送TCP/UDP/ICMP探测包，匹配签名数据库

第三层：端口扫描（后台worker）

  • 默认扫描Top 100端口，可通过配置扩展
  • 使用connect()扫描而非SYN扫描，避免Windows系统防火墙拦截
  • 发现开放端口后，执行service/version探测 (-sV)

第四层：Web服务增强探测

  • 检测到80/443/8080/8000等端口后，触发headless Chrome访问
  • 捕获页面截图、title标签、server响应头
  • 超时控制在10秒内，避免阻塞后续扫描

性能影响评估：在典型的/24子网（254个地址）中，完整扫描周期约15-30秒，产生约2-5MB网络流量。相比持续抓包分析，这种脉冲式扫描对网络影响微乎其微。

个人反思：四层策略的设计体现了”确定性 vs 开销“的权衡艺术。为什么不全量65535端口扫描？因为实践中90%的服务集中在Top 1000端口，扫描其余端口带来的性能开销远大于发现价值。Reconya默认Top 100的配置偏向保守，但这正是其适合持续监控的原因——安全工具自身不应成为网络负担。

5.2 IPv6被动监控的技术优雅性

IPv6的地址空间是128位，主动扫描在数学上不可行。Reconya的被动监控模块展示了协议理解深度：

NDP监听实现：在Linux上通过netlink socket监控内核邻居表变化（ip neighbor show），在macOS/BSD上使用sysctl接口。当内核收到邻居通告(NA)或发送邻居请求(NS)时，Reconya捕获这些事件并提取IPv6地址与MAC映射。

接口监控：通过rtnetlink监控网络接口的地址变化，捕获设备自动配置的Link-Local地址和RA广播分配的Prefix。

地址分类逻辑：程序根据地址前缀自动分类，UI中以不同颜色标识（Link-Local蓝色、Unique Local黄色、Global红色），帮助用户快速识别暴露面。

场景示例：在一次红队演练中，攻击方利用IPv6无状态地址自动配置(SLAAC)绕过了IPv4防火墙。防守方通过Reconya的被动监控，实时发现了攻击机的IPv6 Link-Local地址，尽管该地址未在IPv4 DNS中注册。这种协议层可见性在现代混合网络中至关重要。

六、配置调优：让工具适应你的网络

本段欲回答的核心问题

如何通过.env配置让Reconya在不同规模和拓扑的网络中发挥最佳效果？

.env文件是Reconya适应性的核心。以下是关键参数调优策略：

# 基础安全设置
LOGIN_USERNAME=netadmin          # 不要使用admin，太容易被猜解
LOGIN_PASSWORD=complex_password  # 建议16位以上，含符号
JWT_SECRET_KEY=32_random_hex     # 生产环境必须修改，否则token易被伪造

# 性能调优
DATABASE_NAME="reconya-prod"
SQLITE_PATH="/opt/reconya/data.db"  # 生产环境建议使用独立数据盘

# IPv6监控精细控制
IPV6_MONITORING_ENABLED=true
IPV6_MONITOR_INTERFACES=eth0,eth1   # 多网卡环境明确指定，避免监控无关接口
IPV6_MONITOR_INTERVAL=30            # 降低至10秒可更快发现设备，但CPU占用上升
IPV6_LINK_LOCAL_MONITORING=true     # 内网环境建议开启
IPV6_MULTICAST_MONITORING=false     # 除非运行mDNS/Bonjour服务，否则关闭减少噪音

6.1 扫描频率与网络负载平衡

默认30秒扫描间隔适合大多数场景，但在高动态环境（如BYOD办公网）可缩短至10秒，在低功耗环境（如家庭IoT网络）可延长至60秒。调整需权衡：

  • 频率过高：增加网络拥塞，可能触发IPS告警
  • 频率过低：错过瞬时设备（如移动设备连接后快速断开）

调优公式：建议扫描周期 = 网络中平均设备在线时长 / 10。例如，若设备平均在线10分钟，则60秒扫描周期可捕获90%以上的设备。

6.2 数据库维护策略

SQLite虽然轻量，但长期运行会产生性能问题。建议：

  • 定期归档：每月将data.db复制到备份位置并启动新数据库
  • WAL模式：Reconya默认启用，提升并发性能
  • 尺寸监控：若数据库超过500MB，考虑清理旧事件日志

场景示例：一个2000+设备的制造企业网络，运行Reconya半年后数据库达到2GB，查询明显变慢。通过设置cron任务每月轮转数据库，并删除90天前的事件记录，将查询速度从3秒优化到0.3秒。

七、运维实践：故障排查与性能监控

本段欲回答的核心问题

Reconya在运行中可能遇到哪些问题，如何系统化解决？

7.1 诊断命令速查

项目提供的npm脚本封装了常见运维操作：

npm run status   # 万能诊断命令，检查Go/Node/nmap/权限
npm run stop     # 确保彻底终止，避免僵尸进程占用端口
npm run start    # 后台启动，日志重定向到~/.reconya/logs/

status输出解读：

  • ✓ nmap found with CAP_NET_RAW：权限正确，可完整扫描
  • ✗ nmap requires setuid：需运行chmod u+s $(which nmap)
  • ✓ Go version 1.21+：满足要求
  • ✗ Node.js version < 18：需升级，否则HTMX特性可能异常

7.2 无设备发现的系统性排查

遇到扫描空结果时，按以下路径排查：

  1. 网络可达性：Reconya所在主机能否访问目标网段？使用ip route检查路由
  2. 权限验证：运行getcap $(which nmap)确认是否有cap_net_raw+ep
  3. 防火墙拦截：本地iptables/firewalld是否阻止了扫描报文 outbound
  4. 网段配置：CIDR是否写错？如192.168.1.0/24误写为192.168.1.0/23
  5. 二层隔离：是否跨VLAN扫描？路由器是否启用了ARP代理？

高级技巧：在扫描时运行tcpdump -i any icmp or tcp[13] & 2 == 2，观察是否有探测报文发出。若无，问题在Reconya权限；若有但无响应，问题在网络层。

7.3 端口占用冲突处理

Reconya需要两个端口：

  • 3008：Go后端API，可在.env中修改PORT变量
  • 3000：Node开发服务器，生产环境若不需要实时前端热重载，可在启动脚本中禁用

冲突场景：若宿主机已有服务占用3008，启动会失败。解决方案：

# 方案一：修改Reconya端口
echo "PORT=8080" >> backend/.env

# 方案二：停止占用服务
lsof -ti:3008 | xargs kill -9

个人反思：多端口设计反映了前后端分离架构的便利性，但也增加了运维复杂度。我曾在一个服务器上部署多个Reconya实例监控不同网段，因端口冲突排查花费半小时。这提醒我：任何工具的自动化脚本都应内置端口冲突预检机制，而用户则应在部署前绘制端口使用地图。

7.4 长期运行的稳定性考量

Reconya作为监控工具，可能需要7×24运行。实测中需关注：

  • 内存泄漏：Go语言的GC机制良好，但SQLite长连接可能导致内存缓慢增长。建议每周重启服务
  • 日志膨胀：事件日志无自动清理，需配置logrotate或手动cron任务
  • nmap残留进程：极端情况下nmap子进程可能僵死。监控ps aux | grep nmap数量，若超过5个且存在超1小时进程，需手动清理

场景示例：某安全公司将Reconya部署在持久运行的蜜罐分析节点。通过systemd配置Restart=always和RestartSec=10，并配合LimitNOFILE=65536，实现了服务崩溃自动恢复和海量连接支持。这展现了工具在工程化部署中的潜力。

八、架构设计哲学：简洁与效能的平衡

本段欲回答的核心问题

Reconya的技术选型背后反映了怎样的设计取舍？

8.1 为什么选择Go+HTMX+SQLite？

  • Go：静态编译、跨平台、原生并发。网络扫描这类IO密集型任务，goroutine池的效率远高于Python多线程。单二进制分发避免了依赖地狱
  • HTMX：无需React/Vue等重型框架，服务器端渲染+少量JS实现动态交互。对于监控仪表盘，这极大降低了前端复杂度
  • SQLite：嵌入式数据库，零配置，适合单节点部署。虽然不支持高并发写入，但Reconya的写入负载远低于其处理能力

对比思考：若用Python+Flask+PostgreSQL实现类似功能，部署复杂度提升10倍，内存占用增加5倍，而功能并无本质增强。Reconya的选型体现了”足够好“的工程智慧——不追求技术炫技，只选最适合问题的工具。

8.2 扫描状态机设计

Reconya的扫描不是简单循环，而是有状态机管理：

  • Idle：无任务，等待用户触发
  • Discovering：执行ping sweep
  • Identifying：对在线设备进行身份识别
  • PortScanning：后台worker执行端口扫描
  • Screenshotting：对Web服务截图
  • Monitoring：进入监控模式，只监听变化

状态转换通过channel和sync.WaitGroup同步，防止资源竞争。这种设计确保用户点击”停止扫描”时，所有goroutine优雅退出，不会残留后台任务。

个人反思：阅读源码时，我发现开发者用context.WithCancel()实现了扫描取消机制。这让我想起早期版本可能存在的”僵尸扫描”问题——用户停止扫描后，nmap进程仍在后台运行。这种持续改进的细节，反映了工具成熟度不仅在于功能，更在于边界条件的处理。

九、实用摘要与操作清单

9.1 快速开始Checklist

  • [ ] 确认运行环境：Linux/macOS/Windows，具备管理员权限
  • [ ] 执行一键安装：./install.sh（生产环境建议先阅读脚本）
  • [ ] 验证nmap权限：npm run status显示nmap with CAP_NET_RAW
  • [ ] 修改默认密码：编辑backend/.env，设置强密码和JWT密钥
  • [ ] 启动服务：npm run start
  • [ ] 浏览器访问：http://localhost:3008，使用新凭证登录
  • [ ] 添加网络：输入CIDR，如192.168.1.0/24
  • [ ] 开始扫描：点击按钮，观察设备实时出现
  • [ ] 安全加固：防火墙限制3008端口访问（如iptables -A INPUT -p tcp –dport 3008 -s 10.0.0.0/8 -j ACCEPT）

9.2 生产环境建议配置

参数 开发/测试值 生产推荐值 说明
SCAN_INTERVAL 30 60 降低频率，减少网络负载
PORT_SCAN_THREADS 10 30 增加并发，缩短扫描窗口
SCREENSHOT_TIMEOUT 10s 5s 严格超时，避免阻塞
DB_MAX_CONNECTIONS 10 50 提升数据库并发能力
LOG_LEVEL debug warn 减少日志噪声

9.3 常见问题速查表

现象 可能原因 解决命令
无MAC地址显示 nmap权限不足 sudo chmod u+s $(which nmap)
设备发现不全 跨网段扫描 在目标网段部署扫描节点
服务启动失败 端口占用 lsof -ti:3008 | xargs kill
SQLite locked错误 并发写入 重启服务，或迁移至PostgreSQL
IPv6不显示 内核NDP未启用 sysctl net.ipv6.conf.all.accept_ra=1

十、一页速览（One-page Summary）

Reconya是什么：Go+HTMX构建的轻量级网络资产发现工具，专注实时设备侦察与可视化。

核心优势：nmap深度集成、IPv6被动监控、零JavaScript前端、单二进制部署。

适用场景：中小型企业内网管理、渗透测试预侦察、家庭IoT设备审计、IPv6迁移监控。

安装要点：本地安装唯一推荐，一键脚本./install.sh，必须配置nmap setuid权限。

使用要点：修改默认密码、配置CIDR网段、理解扫描状态机、定期维护SQLite数据库。

性能指标：扫描/24子网约15-30秒，流量2-5MB，内存占用<100MB（千设备规模）。

已知限制：Docker因L2隔离不支持完整MAC发现；跨VLAN扫描需ARP代理；SQLite不适合万级以上设备。

最佳实践：多网段部署独立实例、每月数据库归档、使用logrotate管理日志、通过nginx反向代理添加HTTPS。

十一、常见问题FAQ（基于真实用户反馈）

Q1: Reconya和Nessus/OpenVAS有什么区别？
A: Reconya专注资产发现与状态监控，不做漏洞评估。它更轻量、实时性更强，适合持续监控而非定期审计。Nessus是重量级漏洞扫描器，两者可以互补：先用Reconya发现资产，再将结果导入Nessus定向扫描。

Q2: 为什么扫描不到虚拟机内部的IP？
A: 虚拟机使用NAT网络时，宿主机只能看到虚拟化网关的MAC。需将虚拟机网络设为桥接模式，使其直接进入二层广播域，Reconya才能捕获其MAC和IP。

Q3: 能否扫描公网IP？
A: 技术上可以配置公网CIDR，但强烈不建议。主动扫描公网属于违法行为，且Reconya的扫描频率会触发云服务商IDS。它设计用于内网资产发现。

Q4: IPv6监控会消耗大量CPU吗？
A: 不会。被动监控只监听内核事件，CPU占用率通常<1%。唯一开销是解析NDP报文，但现代CPU处理这点负载微不足道。

Q5: 如何集成到现有监控系统？
A: Reconya的SQLite数据库可直接查询，或修改源码暴露Prometheus metrics端点。更简单的方式是：定期查询devices表，将新设备插入到企业的CMDB或Zabbix监控。

Q6: Web截图功能失败怎么办？
A: 检查headless Chrome是否安装：which chromium或which google-chrome。若在无GUI服务器运行，需安装chromium-browser包并确保--no-sandbox参数被Reconya调用。

Q7: 数据库锁定了如何处理？
A: SQLite在写入时会锁定文件。若多个进程同时写入，会报”database is locked”。确保只运行一个Reconya实例。若问题持续，可能是goroutine泄漏，需重启服务并检查日志。

Q8: 能监控Wi-Fi客户端吗？
A: 可以，但需运行在有 monitor 模式的无线网卡上。普通接入点模式只能看到已关联客户端。更实用的场景是将Reconya部署在路由器或软路由上，直接通过有线接口监控整个LAN。