作者：李·哈丁 | 2026年6月3日 | 阅读时间：7分钟 今天，UDP Gateway 提供了两个新功能。第一个功能允许 WireGuard 监听器接受来自任何客户端的连接，而无需预注册——这与 HTTPS 在网站上的使用模式相同。第二个功能允许异步调用 Lambda 目标，在不等待 Gateway 响应的情况下，将数据包发送到一个长时间运行的工作流。它们共同打开了一类面向公众、事件驱动的 WireGuard 服务，这在之前需要大量自定义基础设施才能建立。 WireGuard 开放端点 WireGuard 监听器一直要求每个连接的客户端必须预注册：您需要在 CloudFormation 模板中列出每个对等体的公钥，监听器会拒绝来自未知密钥的任何握手。该模型适合管理设备集的私有服务。但对于需要被大量或未知客户端访问的任何服务，这就造成了问题。考虑一下一个在首次启动时生成 WireGuard 密钥对的移动应用。或者一个按需提供的设备群，中央密钥管理在操作上不切实际。又或者任何面向公众的服务，您从未见过的客户端需要连接。在之前的模型中，每个客户端都需要一个外部注册步骤和 CloudFormation 更新，才能完成握手。这不是一个适合公共服务的模型。 新的 AllowUnknownPeers 属性消除了这一限制。将其设置为 true 的 WireGuard 监听器，Gateway 将与任何有效的 WireGuard 客户端完成握手，无论其公钥是否在列表中。连接仍然完全加密——WireGuard 的加密属性没有变化。不同之处仅在于监听器不再要求事先知道密钥。与 HTTPS 的类比是有意的。当您通过 HTTPS 访问一个网站时，服务器在建立加密连接之前不需要知道您是谁。TLS 握手完成，渠道被加密，身份验证（如果发生）是应用层单独关注的事情。开放的 WireGuard 端点以相同的方式工作：传输是加密的，身份可以由您的 Lambda 或 Step Functions 目标根据您的应用需求处理。 添加共享凭证门 完全开放的注册——接受任意 WireGuard 客户端——适用于某些服务。对于其他服务，您希望保持加密和开放的握手，同时还希望防止未发出凭证的客户端连接。UnknownPeerPreSharedKey 属性提供了精确应对这种情况的轻量级门。当设置 UnknownPeerPreSharedKey 时，未知的对等体必须在其 WireGuard 配置中包含该 PSK，否则握手将失败。这不是每个设备的身份验证——每个客户端使用相同的密钥——但它有效地限制了访问，仅限于已发出 PSK 的客户端。可以把它想象成用于传输层访问的共享 API 密钥：虽然不是强身份，但确实是针对从未获发凭证的客户端的任意连接的真正障碍。将 PSK 分发给客户端是您应用的责任。将其存储在 AWS Secrets Manager 中，并通过基础设施方面的 CloudFormation 堆栈引用；在客户端的制造或注册过程中将其提供给设备。 WireGuardListener: Type: Custom::ProxylityUdpGatewayListener Properties: ServiceToken: !FindInMap [ProxylityConfig, !Ref "AWS::Region", ServiceToken] ApiKey: !FindInMap [ProxylityConfig, Account, ApiKey] Protocols: - wg AllowUnknownPeers: true UnknownPeerPreSharedKey: !Sub "{{resolve:secretsmanager:${WireGuardPSK}:SecretString}}" Destinations: - Name: packet-handler DestinationArn: !GetAtt HandlerLambda.Arn Role: Arn: !GetAtt ProxylityRole.Arn 在 Peers 数组中列出的命名对等体不受 AllowUnknownPeers 和 UnknownPeerPreSharedKey 的影响。它们像以前一样使用自己的每对等体 SharedSecret。两种模型可以在单个监听器上共存：有一组固定的已知设备，以及一个面向共享凭证的动态客户端的开放插槽。 Lambda 异步调用 UDP Gateway 中的 Lambda 目标一直使用同步 RequestResponse 调用：Gateway 交付一批数据包，等待函数完成，并使用函数的返回值将回复数据包发送回客户端。该模型是默认值，以与 UDP 请求/响应模式的工作方式保持一致。但同步调用对于某些工作负载来说变得有限，因为函数的任务是启动一个超出单次调用的处理。Lambda 持久化函数正是为了解决这个问题：使用检查点和重放机制，持久化函数可以执行最长达一年，并在故障后自动恢复，而不会丢失进度。事件调用类型是这里正确的交付模型——Gateway 发送数据包批次并继续，而持久化函数在后台继续处理。