OpenSandbox dns+nft双模过滤揭秘：DNS过滤与nftables防火墙协同原理完整指南

OpenSandbox dnsnft双模过滤揭秘DNS过滤与nftables防火墙协同原理完整指南【免费下载链接】OpenSandboxSecure, Fast, and Extensible Sandbox runtime for AI agents.项目地址: https://gitcode.com/GitHub_Trending/ope/OpenSandboxOpenSandbox 是面向 AI Agent 的安全、快速、可扩展的沙箱运行时Sandbox runtime for AI agents。本文揭秘其出口流量控制的dnsnft双模过滤机制DNS 过滤负责在域名层面拦截nftables 防火墙负责在 IP 层面兜底两层协同实现默认拒绝、按域名放行的出口网络隔离且对应用完全透明 ️。为什么需要 DNS 过滤 nftables 防火墙两层单独用任何一种方式控制沙箱出网都有明显短板方案能做什么漏洞仅 IP/CIDR 白名单精确封锁地址段云服务、CDN 的 IP 经常变动维护成本高且无法表达允许 pypi.org这样的域名语义仅 DNS 过滤dns-only 模式按域名放行被拒域名返回 NXDOMAIN软限制应用可以绕过 DNS直接用 IP 发起连接如curl http://140.82.114.6或走 DNS-over-HTTPS(TLS) 绕过解析因此 OpenSandbox 采用双层架构DNS 代理提供按域名声明的易用性nftables 提供内核级的真正隔离。设计详情见 OSEP-0001: FQDN-based Egress Control。整个机制运行在一个与沙箱共享网络命名空间的Egress Sidecar中应用容器不获得任何额外权限CAP_NET_ADMIN只授予 sidecar这是它的关键安全设计。第一层DNS 代理过滤域名白名单在这里生效DNS 过滤的实现在 components/egress/pkg/dnsproxy/proxy.go透明劫持sidecar 在127.0.0.1:15353启动纯 Go DNS 代理并用iptables把命名空间内所有 53 端口流量 REDIRECT 过来——不修改/etc/resolv.conf即使应用硬编码了 DNS 服务器也会被拦截。策略匹配每条查询按network_policy评估支持精确域名api.github.com、通配符*.pypi.org被拒域名直接返回NXDOMAIN并写入审计日志egress.policy.denied_total指标 1。域名→IP 学习被允许域名的 A/AAAA 应答会被解析出来并通知第二层——这是两层协同的关键纽带见下文。用户侧只需在创建沙箱时声明策略specs/sandbox-lifecycle.yml 中定义了network_policy结构{ defaultAction: deny, egress: [ { action: allow, target: api.github.com }, { action: allow, target: *.pypi.org }, { action: allow, target: 10.96.0.0/12 } ] }域名规则交给 DNS 层IP/CIDR 规则则由 nftables 直接处理dns-only 模式下会被忽略并告警。第二层nftables 防火墙内核级默认拒绝nftables 规则引擎在 components/egress/pkg/nftables/manager.go 中构建opensandbox表并维护 6 个集合allow_v4/allow_v6、deny_v4/deny_v6、doh_block_v4/doh_block_v6。它做四件事静态 IP/CIDR 规则启动时把策略里的 IP/CIDR 允许项一次性灌入 allow 集合链尾默认 drop。动态 DNS 租约dnsnft 模式的核心当 DNS 层解析出允许域名的 IP 后这些 IP 被同步写入 nftables 动态集合代码注释原话program nft before client connects见 proxy.go#L60-L61带 TTL——取 DNS 应答 TTL 加安全余量钳制在 60–360 秒。这样即使域名 IP 漂移防火墙也始终只放行刚刚被 DNS 层认证过的地址。活跃连接续租sidecar 每 30 秒轮询一次活动 TCP 连接只为仍在使用的 DNS 授权 IP续租components/egress.md 文档详解连接结束后还留有 6 分钟重连窗口然后条目自然过期。加密 DNS 封堵默认 drop 853 端口DoT可选开启对 443 端口 DoH 服务商 IP 段的封锁堵住绕过 DNS 解析这条暗道。双模协同一次请求的完整旅程把两层拼起来dnsnft模式下的流量旅程是这样的 应用请求pypi.org→ 53 端口流量被 iptables 劫持到 sidecar 的 DNS 代理DNS 代理匹配策略*.pypi.org命中 allow → 转发到上游解析若未命中 → 直接回NXDOMAIN连接在第一步就死了解析成功后在客户端建立 TCP 连接之前解析出的 IP 已进入 nftables 动态 allow 集合带 TTL应用发起 TCP 连接 → 命中 allow 集合 → 放行若应用试图直接用 IP 连接一个未经 DNS 认证的地址 → nftables 默认拒绝若应用尝试 DoH/DoT 绕过解析 → 853 端口/DoH IP 段被封。三层执法模式可通过OPENSANDBOX_EGRESS_MODE环境变量切换见 egress 组件文档模式DNS 过滤nftables能否防直接 IP 绕过disabled❌❌❌dns默认✅❌❌软限制dnsnft严格场景推荐✅✅✅如何验证双模过滤是否生效官方提供了一组冒烟与基准脚本是排查问题的最佳入口DNS 过滤冒烟测试components/egress/tests/smoke-dns.shnftables 规则冒烟测试components/egress/tests/smoke-nft.shdnsnft 协同基准测试components/egress/tests/bench-dns-nft.sh手工快速核对两步即可nft list table inet opensandbox查看allow_v4集合中是否出现刚解析出的 IP再在沙箱内curl一个未放行域名确认得到 NXDOMAIN / 连接超时。官方排障建议见 egress 文档 Troubleshooting。新手最容易踩的 3 个坑K8s 集群内 Service 需要双放行defaultAction: deny下访问集群内 Service既要放行 Service 的 DNS 名过 DNS 层又要放行其 ClusterIP 所在 CIDR过 nftables 层只放一个都会失败。详细指导见 网络隔离架构文档。平台级强隔离用deny.always/var/egress/rules/deny.always文件中的规则优先级高于一切用户策略且每分钟热加载适合把集群 Pod/Service CIDR 全量封死防止沙箱互访。运行时兼容性该机制依赖 iptablesnat表runc/Kata 均支持但gVisor 不支持与 Istio 等透明 Service Mesh 共存目前也不支持兼容性说明。延伸阅读完整设计提案与架构图oseps/0001-fqdn-based-egress-control.mdEgress 组件全量文档含 HTTP API、指标、Fleet 模式docs/components/egress.mdDNS 代理源码components/egress/pkg/dnsproxy/nftables 管理器源码components/egress/pkg/nftables/出口 API 规范specs/egress-api.yaml一句话总结DNS 层管名字nftables 层管地址前者学习、后者执法——这就是 OpenSandboxdnsnft双模过滤既易用又严密的全部秘密 。【免费下载链接】OpenSandboxSecure, Fast, and Extensible Sandbox runtime for AI agents.项目地址: https://gitcode.com/GitHub_Trending/ope/OpenSandbox创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考