SMC17/sovereign-edge

# sovereign-edge [](https://github.com/SMC17/sovereign-edge/actions/workflows/ci.yml) [](https://github.com/SMC17/sovereign-edge/releases) [](LICENSE) [](LICENSE) [](https://nixos.org/) [Sovereign Stack](https://stax.dev/sovereign-stack) 的一部分。伴随项目： [`sentinel-sbom`](https://github.com/SMC17/sentinel-sbom) 和 [`sovereign-offense-harness`](https://github.com/SMC17/sovereign-offense-harness)。 ## 为什么存在这个项目 Cloudflare 及其同类企业所运营的规模是这个项目无法企及的（200+ 个数据中心、多 Tbps 级别的任播 DDoS 清洗、ML 机器人分类、Workers 边缘计算、R2 对象存储）。如果应用场景确实需要依赖这种规模的基础设施，请直接使用它们。 对于那些不需要任播，且确实需要真正拥有并审查底层技术栈的场景——单一来源部署、欧盟数据驻留要求、受监管的工作负载、国防采购项目，以及拒绝让其 HTTP 请求在别人的 ASN 内终止的自托管爱好者——这些开源（OSS）组件其实早已发布，只是将它们组合起来一直令人十分头疼。 `sovereign-edge` 就是这个组合层： - **Caddy** — 自动 HTTPS + HTTP/3 + 安全标头基线 - **Coraza WAF + OWASP CRS** — 位于源站之前的 Web 应用防火墙 (WAF) - **nftables** — 无效状态丢弃 + ICMP 速率限制 + SYN 速率限制 - **knot-DNS** — 支持 DNSSEC 在线签名的权威 DNS (ECDSAP256SHA256) - **CrowdSec + crowdsec-firewall-bouncer** — 协作式 IP 黑名单，封禁操作通过 nftables 实施 本仓库中的原创工作是将其整合在一起的 NixOS 模块，它提供了合理的默认配置，只需一个 `enable = true;` 开关即可启用。底层服务都不是我们开发的；我们只是站在了巨人的肩膀上。 ## 架构（单 VPS 拓扑） ``` Internet │ │ ┌─────────────────────────┼──────────────────────┐ │ port 53 UDP/TCP │ ports 80/443 TCP + │ │ (DNS queries) │ 443 UDP (HTTP/3) │ ▼ ▼ │ ┌─────────┐ ┌─────────────────┐ │ │ knot │ │ nftables input │ (rate-limit + │ │ DNS │ │ chain (default- │ CrowdSec │ │ (auth. │ │ deny + ICMP/SYN │ bouncer- │ │ DNSSEC) │ │ limits + ct) │ injected │ └─────────┘ └────────┬────────┘ bans) │ │ │ ▼ │ ┌────────────────┐ │ │ Caddy │ │ │ (auto-HTTPS, │ │ │ HTTP/3, cache)│ │ └────────┬───────┘ │ │ │ ▼ │ ┌────────────────┐ │ │ Coraza WAF │ │ │ (OWASP CRS) │ │ └────────┬───────┘ │ │ │ ▼ │ ┌────────────────┐ │ │ reverse_proxy │ │ │ to origin │ │ └────────┬───────┘ │ │ │ ▼ │ Origin server │ │ CrowdSec agent watches Caddy access.log + sshd journalctl, decides on bans, the firewall bouncer applies them in nftables ▲ ``` 注意：knot-DNS 是一个权威 DNS 服务器，独立于 HTTP 数据路径。它被包含在此捆绑包中是因为大多数边缘部署都需要这两者，而不是因为 DNS 查询需要经过 WAF。 ## 演示 ``` $ git clone https://github.com/SMC17/sovereign-edge $ cd sovereign-edge $ nix build .#nixosConfigurations.edge.config.system.build.toplevel /nix/store/268kvdxfim0rzp7zpch521jkajwxm047-nixos-system-edge-26.05.20260506.ed67bc8 $ # Drop into your own flake $ cat my-edge.nix { imports = [ inputs.sovereign-edge.nixosModules.sovereign-edge ]; sovereign-edge = { domain = "yourdomain.tld"; origin = "127.0.0.1:8080"; # your Caddy reverse-proxies here }; } $ nixos-anywhere --flake .#my-edge deploy@vps.example.com ``` 按组件切换： ``` imports = [ inputs.sovereign-edge.nixosModules.knot ]; # just sovereign DNS imports = [ inputs.sovereign-edge.nixosModules.caddy ]; # just edge proxy # 等 ``` ## 诚实的对比 这并不是为了在超大规模场景下替代 Cloudflare。它针对不同的部署形态提供了不同的权衡。下面的表格尽我所能做到了客观诚实。 | | sovereign-edge | Cloudflare | Akamai | Fastly | 手工组装的开源方案 | |---|---|---|---|---|---| | 部署拓扑 | 单 VPS | 全球任播 (200+ POPs) | 全球任播 | 全球任播 | 单一主机或自有架构 | | L3/4 层 DDoS 防护 | 基于 IP 的速率限制 (nftables) | 多 Tbps 级别的任播清洗 | 多 Tbps 级别 | 清洗 | 仅依赖主机内核 | | WAF | Coraza + OWASP CRS | 专有方案 + 可选 CRS | Kona 及其他 | Signal Sciences | 视情况而定 | | DNS / DNSSEC | knot 权威 DNS + 在线签名 | 是 | 是 | 是 | 视情况而定 | | 机器人管理 | CrowdSec 协作式黑名单 + 手动规则 | ML 分类器 | Bot Manager | NextGen WAF | 无内置功能 | | 边缘计算 (Workers) | 无 | 是 (V8 隔离沙箱) | 是 | 是 (Wasmtime) | 无 | | 对象存储 (R2 级别) | 无 | R2 | NetStorage | 不适用 | 无 | | 一键部署 | `nix build` 然后 nixos-anywhere deploy | 控制面板点击 | 企业销售 | 控制面板点击 | 手动 | | 厂商锁定 | 无 | 高 | 高 | 中 | 无 | | 审计透明度 | 源码可读的 Nix 模块 | “信任 SOC2” | “信任 SOC2” | “信任 SOC2” | 视情况而定 | | 定价 | 电费 + VPS 费用（约 €5/月 Hetzner CX22） | 按请求计费 + 免费额度 | 企业定价 | 按请求计费 | 视情况而定 | **sovereign-edge 的适用场景**：在单台 VPS 上运行且 RPS 低于 ~10K 的单一来源部署。你需要边缘技术栈的“形态”（反向代理 + WAF + DNS + 速率限制 + DNSSEC），但不需要全球任播、边缘计算或多 Tbps 级别的 DDoS 清洗。常见匹配场景：具有数据驻留限制的受监管工作负载、反云托管的自托管爱好者、国防项目参考部署、以及不希望流量在美国 ASN 内终止的欧盟企业。 **Cloudflare 及同类厂商的适用场景**：任播规模、ML 机器人分类器、多 Tbps 级别的 DDoS 防护、边缘计算平台。如果你需要其中任何一项，这个工具并不适合你。 **手工组装更胜一筹的场景**：如果你已经自己成功搭建了 Caddy + nftables + knot + CrowdSec 并且运行良好，这个项目不会给你带来任何新东西——继续维护你自己的配置就好。这里的价值在于为那些尚未进行过这种配置组合的用户，或者希望获得一个可以通过声明式覆盖的可复现基础环境的用户提供组合方案。 ## 状态 — 已验证与未验证的内容 每个阶段的验收标准是 `nix build .#nixosConfigurations.edge.config.system.build.toplevel` 成功执行。 **该标准仅证明 NixOS 模块图能够正确求值且闭包构建成功。它并不能证明系统能够运行、处理流量或 WAF 能够拦截任何内容。** 在真实 VPS 上的运行时验证已列入路线图，并被定为 Phase-1.7 阶段项。 | 阶段 | 组件 | 实际已验证的内容 | |---|---|---| | **Phase 1** | Caddy + nftables + knot + CrowdSec 基础设施 | 闭包构建成功。无运行时验证。 | | **Phase 1.5** | CrowdSec 采集器 + firewall-bouncer + knot DNSSEC | 闭包构建成功。无运行时验证。 | | **Phase 1.6** | Caddy 中的 Coraza WAF + OWASP CRS | 闭包构建成功。Caddy config-adapter 接受 `coraza_waf` 指令（证明插件已编译）。无运行时流量测试。 | | **Phase 2** | Anubis (反 AI 爬虫 PoW 网关，监听 127.0.0.1:8923) + Headscale (Tailnet 控制平面，127.0.0.1:8080) — 均通过 `mkEnableOption` 启用（默认关闭） | 启用两个模块后闭包构建成功。无运行时流量测试。 | | **Phase 1.7** (下一阶段) | 在真实 VPS 上的参考部署，处理实际流量，观察到 OWASP CRS 规则生效，观察到 Anubis PoW 拦截爬虫 | 尚未开始。 | | **Phase 3** (已设计) | Zig 原生组件 (边缘缓存, CRS 引擎)，全栈的 sentinel.zig 审计信封，Pomerium 零信任集成 | 未开始；仅列出。 | 详细路线图请参阅 [STATUS.md](STATUS.md)。 ## 安装 / 部署 ### 作为 NixOS 模块使用 ``` { inputs.sovereign-edge.url = "github:SMC17/sovereign-edge"; outputs = { self, nixpkgs, sovereign-edge, ... }: { nixosConfigurations.my-edge = nixpkgs.lib.nixosSystem { modules = [ sovereign-edge.nixosModules.sovereign-edge ./hardware-configuration.nix { sovereign-edge = { domain = "yourdomain.tld"; origin = "10.0.0.5:8080"; lanCidrs = [ "10.0.0.0/24" ]; # optional }; } ]; }; }; } ``` ### 通过 nixos-anywhere 部署 ``` nix run github:nix-community/nixos-anywhere -- --flake .#my-edge deploy@vps.example.com ``` ## 验收标准（证明级别的透明度） 本工具自身的原则：声明不会强于证据。目前的验收标准是有意设置得较低的——它们只证明了构建能力，而非运行时表现。 - **Phase 1 / 1.5 / 1.6 / 2** — 闭包构建成功（`nix build` 返回 0，每次提交都会测试）。这意味着模块图能够正确求值且派生树能够解析。这并不代表部署后的实例能正确处理流量。参考主机启用了 Phase 2 的可选模块（Anubis, Headscale），因此该命令也能证明这些模块的闭包可以构建成功。运维人员可以在自己的配置层中将这些开关关闭。 - **Phase 1.7**（在声称“可用于生产环境”之前理应存在的缺失标准）——在真实的 VPS 上部署，提供真实域名服务，观察到 Coraza 拦截故意发出的恶意请求，观察到 CrowdSec 在 nftables 中封禁攻击者 IP，观察到下游成功验证 DNSSEC 签名，观察到 Anubis PoW 拦截爬虫。以上这些目前均未进行。 - **Phase 3** — 仅有设计。 ## 为什么构建它 三件事汇聚在了一起： 1. 云厂商的边缘服务已整合为大约 3 家提供商（CF, Akamai, Fastly），每家都是闭源 SaaS，且距离被一纸《云法案》传票强制披露流经其系统的所有数据只有一步之遥。 2. 用于替代它们的 OSS 组件已经全部发布——Caddy 已经成熟，Coraza 将 OWASP CRS 移植到了一个简洁的 Go 库中，knot-DNS 提供了符合 RFC 标准的 DNSSEC，CrowdSec 协作式黑名单运作良好。 3. 组合层并不存在——运维人员必须自己将每个部分连接起来。`sovereign-edge` 就是这个组合层。 我们的判断是：存在一个真实的客户群体——国防、欧盟数据驻留需求、受监管的金融机构、反厂商锁定——对他们来说，“达到 Cloudflare 级别但我可以将其部署在自己的物理机上”的价值远大于全球任播的噱头。 ## 许可证 AGPL-3.0-or-later。详见 [LICENSE](LICENSE)。 如果你将 `sovereign-edge` 作为服务出售，你所做的修改必须向上游公开。这是一种集成商包裹上游的模式——为现代互联网边缘打造的 Red Hat / Linux 模式。 ## 贡献 详见 [CONTRIBUTING.md](CONTRIBUTING.md)。强制要求签名提交。 安全策略：[SECURITY.md](SECURITY.md)。 ## Sovereign Stack 的一部分 这是更广泛的“不要租用，自己运行”基础设施集合中的一个组成部分。 - [**sentinel-sbom**](https://github.com/SMC17/sentinel-sbom) — Nix `flake.lock` → 包含树内 narHash 验证的 SPDX SBOM - [**sovereign-offense-harness**](https://github.com/SMC17/sovereign-offense-harness) — 带有签名审计信封的对手模拟运行器 完整项目组合请参阅 [github.com/SMC17](https://github.com/SMC17)。

标签：AppImage, Caddy, CISA项目, Coraza, CrowdSec, DDoS防护, DNSSEC, DNS服务器, HTTP/3, ICMP限速, Knot DNS, Linux网络安全, nftables, NixOS, Sovereign Stack, SYN限速, WAF, Web应用防火墙, 主干网栈, 人工智能安全, 协同IP黑名单, 反向代理, 合规性, 安全标头, 开源, 数据主权, 欧洲数据驻留, 系统配置管理, 自动HTTPS, 自托管, 边缘计算, 防火墙, 高安全性