这套方案面向 Windows/macOS/Linux 混合办公、控制面和数据完全自托管 的中小型互联网公司。原则是优先复用已有平台，每个领域只保留一个权威系统；邮件网关与远程接入入口可以放在 DMZ，但不依赖外部 SaaS。

“开源”不等于“社区版功能无限”。Fleet、NetBird、Semaphore UI、Nexus 等均有商业功能或许可边界，部署前应按实际版本做一次功能和许可证 PoC。

总体架构

  flowchart TB
    U[员工设备<br/>Windows / macOS / Linux]
    R[远程员工]
    B[分支机构]

    subgraph ID[身份与信任]
        AD[Samba AD<br/>LDAP / Kerberos / DNS]
        SSO[LemonLDAP::NG<br/>OIDC / SAML / 访问代理 / MFA]
        CA[step-ca<br/>X.509 / SSH CA]
        VAULT[OpenBao 可选<br/>应用密钥与动态凭据]
        AD --> SSO
    end

    subgraph ACCESS[网络接入]
        NB[NetBird<br/>远程访问与设备级策略]
        FW[OPNsense<br/>WireGuard / IPsec]
    end

    subgraph OPS[运维与安全]
        FLEET[Fleet<br/>终端资产与策略]
        GLPI[GLPI<br/>ITSM / CMDB]
        JUMP[JumpServer<br/>特权访问审计]
        MON[Zabbix + Wazuh<br/>可用性与安全监控]
    end

    subgraph APPS[内部应用]
        GIT[Forgejo<br/>Git / CI / Packages]
        NC[Nextcloud + Office<br/>文件与协作]
        CHAT[Zulip]
        MAIL[邮件系统]
        DOC[Collectives / MkDocs]
    end

    subgraph DATA[计算与备份]
        PVE[Proxmox VE / Incus]
        BK[Kopia + Proxmox Backup Server]
    end

    U --> AD
    U --> FLEET
    R --> NB --> SSO
    B --> FW --> SSO
    SSO --> GIT
    SSO --> NC
    SSO --> GLPI
    SSO --> JUMP
    CA --> MAIL
    CA --> JUMP
    VAULT -.凭据.-> GIT
    JUMP --> PVE
    NC --> BK
    GIT --> BK
    PVE --> BK

认证与内部 PKI

  • Samba AD + samba-tool/RSAT：统一管理用户、组、计算机、DNS、LDAP 和 Kerberos。生产环境至少部署两个域控制器，并保持可靠的时间同步。
  • LemonLDAP::NG：直接使用 Samba AD 作为用户目录，提供 OIDC、SAML、Kerberos/SPNEGO、访问代理、TOTP 和 WebAuthn；它负责 Web SSO，不替代 AD 的账号与机器管理。
  • step-ca：首选内部在线 CA，签发和自动续期 X.509、mTLS 与 SSH 证书；离线保存根 CA，仅让中间 CA 在线。
  • OpenBao：不是 step-ca 的同类替代，而是可选的密钥与动态凭据平台。只有出现数据库动态账号、应用密钥租约或集中 secrets workflow 时再引入。

Keycloak 是完整但较重的 IAM，且不自带通用应用访问代理，Dogtag 和 OpenXPKI 是完整但较重的 CA；Authentik 自带代理，但 LDAP 通常作为同步来源而非直接账号存储；Zitadel 也维护自己的身份存储。Dex 是轻量 OIDC 联邦组件，而 Authelia、oauth2-proxy、Oathkeeper、Pomerium 更偏访问网关，均不能替代 Samba AD 的目录与机器管理。

IT 运维

  • Fleet：统一采集资产、软件、漏洞和合规信息，并管理多平台设备策略。免费版适合资产、查询、策略、脚本和基础 MDM；应用部署、补丁/OS 更新、RBAC、审计等能力需核对当前的 Free/Premium 边界。严格要求所有功能均为自由软件时，目前没有同等成熟的三平台单体替代品。
    • OpenUEM 更偏传统桌面运维和软件分发。
    • MeshCentral 更适合远程桌面、终端、文件传输和临时支持，可作为 Fleet 的补充，而非 MDM 替代品。
  • GLPI：ITSM/CMDB 的权威数据源，管理工单、采购、合同以及资产与员工关系。Fleet 负责发现和控制终端，GLPI 负责业务流程，避免维护两份资产主数据。
  • JumpServer：统一管理服务器、数据库等特权访问，提供授权、录像和审计。更轻量的有 Teleport、spug 和 Next Terminal。JumpServer 和 Teleport 支持 passwordless 体验，前者使用认证凭证代填，后者使用临时证书认证。
  • Semaphore UI：运行和调度 Ansible、Terraform/OpenTofu、Shell 与 PowerShell。社区版可做基础执行，但 LDAP/OIDC 当前属于 Pro；若必须纯开源 SSO，可优先通过 Forgejo Actions 执行运维代码，或接受更重的 AWX。
  • NetBox：网络与机房的 Source of Truth，负责 IPAM、VLAN、机柜、线路和布线数据；它不是 SNMP 网络监控系统。
  • 监控与安全：用 Zabbix 统一做服务器、服务和 SNMP 告警，也可以考虑更现代的 Nightingale；用 Wazuh 做三平台日志、安全基线、文件完整性和安全事件。Security Onion 或 SELKS 适合另行建设 NDR/流量检测，资源开销较大，不建议与 SIEMonster 同时部署。

VPN 与零信任接入

站点互联统一放在 OPNsense：两端均可控时首选 WireGuard；需要连接传统防火墙或第三方机构时使用 strongSwan/IPsec；OpenVPN 只保留兼容或应急入口。Tinc、n2n、OpenConnect、SoftEther 不必与主方案并行维护。

员工远程访问首选 NetBird，接入 LemonLDAP::NG OIDC，并按用户组、设备和网段设置最小权限。社区版不支持控制面 HA，应做好配置备份和快速重建；若 HA 是硬要求，需要调整产品或许可选择。

可选方案：

  • Headscale + Headplane：控制面轻量且支持 OIDC，但 Headscale 没有官方内置 Web UI，管理界面依赖社区项目。
  • Netmaker：适合服务器 Mesh、跨云和站点互联，支持 WireGuard、Web UI 与 OIDC，社区版不支持打洞失败自动切换到 relay gateway，也不支持 relay gateway 高可用。
  • Defguard：适合需要 WireGuard 连接级 MFA、自助设备注册和统一 Web 管理的场景，不支持 Mesh 网络拓扑。
  • OpenZiti：服务级身份、暗服务和持续授权更接近严格 ZTNA，但部署和运维明显更复杂。
  • Hashicorp Boundary：应用层面的零信任通用 TCP 转发，与 Hashicorp Vault 集成紧密，支持 Passwordless 体验，Boundary Controller 代填认证凭证。
  • Nebula 没有内置 OIDC/Web 管理；ZeroTier 的自托管 UI 与许可边界需要额外评估，不作为严格开源方案的默认选择。

开发管理

  • Forgejo：负责 Git、Issue、Pull Request、Actions CI/CD、Release、容器和多种语言包仓库；对中小型团队通常比 GitLab CE 更轻。
  • Nexus Repository：仅在需要缓存 Maven/npm/PyPI/Docker 等外部依赖时引入。当前社区版 限制 40,000 个组件和每天 100,000 个请求，超限会停止接收新组件；开源 Core 版支持的格式又少于社区版。严格开源时优先使用 Forgejo Packages，加少量按格式部署的缓存代理。

内部办公协作

  • Nextcloud：统一提供 Files、Calendar、Contacts、Tasks、Deck、Collectives 和 Text。相比之下，ownCloud 的协作组合较少，Seafile 更专注文件同步。
  • 在线 Office：优先在实际文档样本上比较 ONLYOFFICE Docs 与 Nextcloud Office/Collabora。ONLYOFFICE Docs 9.4 已取消社区版原有的 20 个同时连接限制；Nextcloud Office 是集成应用，后端使用 Collabora Online，Collabora CODE 则是其开发版部署，不应列成三个独立产品。
  • Zulip：按主题组织的即时通讯适合技术团队和异步讨论。
  • 邮件：成熟方案采用 Postfix + Dovecot + Rspamd + Redis + Roundcube，可用 docker-mailserver 或 Mailu 降低部署复杂度；Stalwart 是更现代的一体化备选，支持 SMTP、IMAP、JMAP、CalDAV、CardDAV 和 WebDAV。

如果需要与互联网 MTA 收发邮件，应将 SMTP 网关置于 DMZ，使用独立静态公网 IP，并配置匹配的 A/AAAA 与 PTR、SPF、DKIM、DMARC；同时做好 TLS、限速、队列监控和投诉处理，绝不能配置成开放中继。无法取得 PTR 或端口 25 质量较差时，使用信誉良好的出站 smarthost 更稳妥。

文档与内容管理

  • 员工手册、制度和部门知识放在 Nextcloud Collectives。
  • 架构、API、运维和灾备手册放在 Forgejo Git + MkDocs，通过 PR 审核并静态发布。
  • IT 自助排障文章放在 GLPI Knowledge Base，讨论结论再沉淀到正式文档。
  • 对外网站和技术博客使用 Hugo。
  • 只有 Collectives 的层级、模板或权限明显不足时，才引入 BookStack。Foswiki 仅适合结构化表单与可编程 Wiki；Drupal 适合复杂、多语言、强工作流门户；WordPress 适合由运营人员高频可视化发布。三者都不应仅为“写文档”而部署。

外部社区与工单

  • Discourse：作为论坛、用户社区和一般支持入口。
  • Zammad：仅在出现严格 SLA、复杂客服队列、结构化客户资料和客服报表需求时引入。普通研发问题留在 Forgejo，内部 IT 工单留在 GLPI，避免再增加 Issue 系统。

文件、主机与虚拟化备份

  • Kopia：作为服务器、NAS 和三平台文件备份的主方案，支持加密、压缩、滚动分块去重、GUI 与服务器模式。
  • Proxmox Backup Server：备份 Proxmox VM 与容器，不能由普通文件备份完全替代。
  • UrBackup：适合集中管理 Windows/Linux 客户端的文件和系统镜像备份；它原生以相同文件去重为主，不能简单等同于 Kopia 的仓库级滚动分块去重。
  • Restic + Backrest/Wrestic/Restic Browser：成熟的替代组合；Burp + BurpUI 也可用，但桌面端体验较弱。

无论工具如何选择，都应落实 3-2-1、至少一份离线或不可变副本、数据库一致性备份，以及定期自动校验和人工恢复演练。

虚拟化

  • Proxmox VE：默认生产虚拟化平台，提供 VM、LXC、集群、存储和 Web 管理。
  • Incus：更轻量的系统容器/VM 管理方案，可用于开发测试或小型独立节点。除非边界明确，不建议与 Proxmox 重复管理同一批生产资源。

密码管理

  • Passbolt：偏团队共享、分组和协作流程。
  • Vaultwarden：资源占用低，兼容 Bitwarden 客户端，但属于社区实现。

二者选择一个即可。无论选择哪一个，都应保留独立于 SSO 的离线 break-glass 管理凭据，并将恢复密钥纳入受控备份。

建议落地顺序

先建设双 Samba AD、LemonLDAP::NG、内部 PKI、备份与监控；再上线 Forgejo、Nextcloud、GLPI 和终端管理；最后按真实需求增加 ZTNA、JumpServer、安全检测和外部社区。这样既能控制系统数量，也能避免身份、资产、工单和文档出现多个权威来源。