保护您的中继
摘要
Iroh 的托管中继现在默认启用身份验证,要求使用 API 密钥签发的能力令牌,只有经过授权的端点才能使用它们,以防止中继滥用和流量劫持。
暂无内容
查看缓存全文
缓存时间: 2026/08/14 12:27
# 保护你的中继
来源:https://www.iroh.computer/blog/authenticated-relays
当两台设备无法直接连接时,[中继](https://docs.iroh.computer/concepts/relays)会承载连接,让数据仍能流通。如果中继接受任何人,那么任何得知其 URL 的人都可以通过它推送流量。而且他们一定会知道:它内置于你分发的每个客户端中,任何观察连接建立过程的人都能看到它。
因此,我们决定,[Iroh Services](https://services.iroh.computer/) 上的[托管中继](https://docs.iroh.computer/iroh-services/relays/managed)现在**默认需要身份验证**。只有携带由你项目 API 密钥签发的令牌的端点才能使用它们。
无需启用任何设置。如果你已经通过 `iroh_services` [预设](https://docs.iroh.computer/iroh-services/relays/managed)连接,你的端点会自动完成身份验证。
有一点需要注意:这是 2026 年 6 月起部署的中继的默认设置。如果你在此之前部署了中继,它将继续保持开放,这样已在使用它的端点不会受到影响。若要开启此功能,请前往 Relays > Settings 下的中继[身份验证设置](https://docs.iroh.computer/iroh-services/relays/managed#authentication)。
有人会在公共仓库、客户端捆绑包或截图中找到你的中继 URL,然后开始向你的基础设施发送垃圾流量,直到它崩溃。
你费尽心思搭建了自己的中继,但别人的流量仍会与你的流量竞争。中继的带宽和连接槽位都是有限的,无论它是你租用的物理机、你桌下的虚拟机,还是你向我们购买的容量,任何其他发现该 URL 的人现在都能使用它。
如果你运行自己的中继,你可以构建自己的身份验证方案——iroh 对此不设限制。但如果你使用的是我们的托管中继,直到本月之前,我们都没有为你提供一种轻松控制访问的方式。现在,我们发布了身份验证难题的第一部分——API 密钥。你可以无限地签发、轮换和删除它们。这些 API 密钥与你推送指标时使用的密钥相同,所以如果你正在使用 [Iroh Services](https://services.iroh.computer/),你已经有了一把。
部署一个专用中继,[免费试用 30 天](https://services.iroh.computer/)。
每次中继连接都以 HTTP 握手开始,也就是升级到 WebSocket 的同一握手。身份验证信息通过一个标准头部传输:
该令牌是一个签名的[能力令牌](https://docs.rs/rcan)。它包含四件事:
- **谁签发的**:你的项目 API 密钥
- **给谁的**:出示该令牌的端点的公钥
- **授予什么**:使用中继的权限,仅此而已
- **何时过期**:可以设置为较短的时间窗口,因此即使被泄露,也无法被长期使用
当端点连接时,iroh 的中继握手首先会证明端点确实拥有其密钥。每次连接都会如此,无论是否经过身份验证。然后中继会检查令牌:签名是否有效、是否未过期、是否授予中继使用权限、是否指定给这个确切的端点,以及是否由你项目中的一个 API 密钥签发?如果所有答案都是肯定的,该端点就会被允许接入。
由此产生了两个我们喜欢的特性。
**泄露的 URL 是无害的。** 没有由你的 API 密钥签发的令牌,尝试连接它不会得到任何结果。
**泄露的令牌可以建立连接,但无法冒用身份。** 该令牌是指定给一个特定端点的公钥的,因此从另一个端点出示它会失败:握手仍然需要证明对该端点私钥的所有权,而仅凭令牌是无法做到的。
撤销也遵循同样的路径。你的 API 密钥是中继识别的身份,因此轮换或删除密钥后,中继将停止认可由该密钥签发的令牌,依赖这些令牌的连接也会被断开。
你无需手动组装这些内容。`iroh_services` [预设](https://docs.iroh.computer/iroh-services/relays/managed)会从你的 API 机密生成令牌,并自动将其附加到每次中继连接上。构建经过身份验证的端点,只需你本来就会写的几行代码:
你的 API 机密永远不会离开你的进程。该预设使用它来派生一个中继范围内的令牌,而这个派生出的令牌才会被发送到中继。将 `.relays(...)` 指向项目仪表板中的中继 URL,设置 `IROH_SERVICES_API_SECRET`,就这样。
目前,每个端点获得相同的能力。未来,我们将增加生成不同作用域令牌的功能,这样你可以授予某些端点比其他端点更多的权限。此外,我们还将允许你单独撤销对端点的访问权限,并提供 API 在仪表板之外完成这一切。如果你对这些内容感兴趣,请通过 [Discord](https://discord.com/invite/DpmJgtU7cW) 联系我们,让我们知道。
如果你现在运行中继,至少在不同区域部署两个,这样某个区域宕机不会让你的端点无法连接。[托管中继指南](https://docs.iroh.computer/iroh-services/relays/managed)介绍了完整的设置过程。
有问题,或者想讨论你的中继设置?加入我们的 [Discord](https://discord.com/invite/DpmJgtU7cW),或与我们[预约通话](https://cal.com/team/number-0/iroh-services)。我们喜欢谈论中继,并希望确保你能充分利用它们。
Iroh 是一个能连接任意设备的网络库,开箱即用。你可以从现成协议生态系统中组合出所需功能,也可以在原始传输管道之上的简洁抽象中完全自定义。Iroh 是开源的,已经在数十万台设备上投入生产。要开始使用,请查看我们的[文档](https://iroh.computer/docs),直接深入[代码](https://github.com/n0-computer/iroh),或在我们的 [Discord 频道](https://iroh.computer/discord)中与我们交流。
相似文章
代币转售与欺诈背后的中继市场内幕
对打折转售LLM代币的市场的调查,通常通过滥用免费试用、窃取凭证和拒付攻击进行,主要在中国。开源代理one-api和new-api被用来汇集API密钥并实现请求负载均衡。
部分密钥管理应交给 HTTP 代理
博客文章建议将 API 密钥注入工作卸载到内部 HTTP 代理,使应用和代理程序永远接触不到密钥,从而简化轮换并降低外泄风险。
集中管理API密钥很方便,但代理是否应该看到它们?
探讨AI代理是否应直接看到API凭证,受到开源项目OneCLI的启发,该项目使用网关将占位符替换为真实密钥,引发了关于AI工具中信任与安全的讨论。
我为本地AI智能体构建了一个默认拒绝防火墙(OpenClaw/Hermes)——它会拦截每一次工具调用,并在执行任何可能存在风险的操作前征求我的批准
一个针对本地AI智能体的默认拒绝防火墙守护进程,拦截每一次工具调用,阻止危险操作,并对模棱两可的操作请求用户批准,同时具备防篡改日志记录。旨在降低提示注入风险。基于MIT许可证开源。
保障代理身份安全
一位安全专家讨论了为访问敏感资源的LLM代理保障身份令牌安全的挑战,并提出了一种基于代理的方法,将令牌绑定到特定环境以防止凭证窃取。