开放 WireGuard 端点

# 新功能上线：开放 WireGuard 端点与 Lambda 异步调用 来源：https://proxylity.com/articles/now-available-open-wireguard-endpoints-and-async-lambda.html 开放 WireGuard 端点接受任意对等端与异步 Lambda 工作流示意图 今日 UDP 网关推出两项新功能。第一项功能允许 WireGuard 监听器接受来自任何客户端的连接，无需预先注册——这与 HTTPS 网站采用的模型相同。第二项功能支持 Lambda 目的地进行异步调用，允许将数据包发送至长期运行的工作流而无需网关等待响应。两者结合，使得构建面向公众的事件驱动型 WireGuard 服务成为可能，此前这类服务需要大量定制化基础设施支撑。 ## WireGuard 开放端点 WireGuard 监听器过去要求每个连接客户端必须预先注册：需在 CloudFormation 模板中列出每个对等端的公钥，监听器会拒绝任何未知密钥的握手请求。该模型适用于拥有受管设备集的私有服务。但对于需要被大量未知客户端访问的场景，这会导致问题。 例如某个移动端应用在首次启动时生成 WireGuard 密钥对，或需动态配置且不便集中管理密钥的设备集群，或任何需要允许从未见过的客户端连接的公共服务。在原有模型下，每个客户端都需要通过带外注册步骤并在 CloudFormation 更新后才能完成握手。这种模式无法适配公共服务场景。 新增的 `AllowUnknownPeers` 属性移除了该限制。将其设为 `true` 后，WireGuard 监听器将接受任何有效 WireGuard 客户端的连接，无论其公钥是否在列表中。连接仍然保持完全加密——WireGuard 的加密特性不会改变。区别仅在于监听器不再要求预先知晓密钥。 与 HTTPS 的类比是有意为之。通过 HTTPS 访问网站时，服务器无需在建立加密连接前识别用户身份。TLS 握手完成后通道即被加密，认证（如果存在）则作为应用层的独立环节处理。开放 WireGuard 端点的工作原理与之类似：传输层加密，身份验证可通过 Lambda 或 Step Functions 目的地按应用需求实现。 ### 添加共享凭证门控 完全开放的注册模式——接受任意 WireGuard 客户端——适用于某些场景。但若需要加密特性与开放握手机制，同时又要阻止未获得凭证的客户端连接，`UnknownPeerPreSharedKey` 属性可提供轻量级访问控制。 当设置 `UnknownPeerPreSharedKey` 时，未知对等端必须在 WireGuard 配置中包含该预共享密钥（PSK），否则握手将失败。这不是设备级认证——所有客户端使用相同密钥——但能有效限制访问权限至获得 PSK 的客户端。可将其视为传输层访问的共享 API 密钥：虽非强身份验证，但能有效阻拦未获凭证客户端的任意连接。 分发 PSK 至客户端是应用层的责任。基础设施侧可将其存储于 AWS Secrets Manager 并在 CloudFormation 堆栈中引用；客户端侧则在制造或注册阶段将其预置到设备中。 ```yaml 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`。两种模型可在单个监听器上共存：一组具有设备级 PSK 的固定已知设备，以及一个使用共享凭证接入的开放动态客户端通道。 ## Lambda 异步调用 UDP 网关中的 Lambda 目的地始终使用同步 `RequestResponse` 调用模式：网关发送数据包批次，等待函数执行完成，并根据函数返回值向客户端发送应答包。该模型作为默认设置与 UDP 请求/响应模式的工作方式保持一致。 但对于函数任务仅是触发后续处理的工作负载，同步调用会存在限制。Lambda 持久化函数正为此类场景设计：通过检查点与重放机制，持久化函数可持续执行长达一年，故障后自动恢复且不丢失进度。`Event` 调用类型在此场景下是理想的交付模型——网关发送数据包批次后即可继续执行，持久化工作流则独立运行。 新增的 `UseAsyncInvoke` 参数将调用类型更改为 Lambda 的 `Event` 模式。网关发送数据包批次后立即收到 HTTP 202 Accepted 响应，无需等待函数完成。不会向 UDP 客户端发送应答。函数执行完全独立于网关的请求生命周期。 该功能主要用例是触发持久化工作负载。使用 `UseAsyncInvoke` 调用的函数接收入站数据包批次后，启动持久化执行（或按需调度至 Step Functions 编排模型），然后立即返回。远程客户端发送了 UDP 数据包；此时已为代表其运行的长期容错工作流，该工作流具有检查点进度和自动故障恢复能力——所有这些都无需网关保持连接。 ```yaml Destinations: - Name: workflow-trigger DestinationArn: !GetAtt WorkflowTriggerLambda.Arn Role: Arn: !GetAtt ProxylityRole.Arn Arguments: UseAsyncInvoke: "true" ``` 使用异步调用时需注意以下几点： - **不发送应答**：函数返回值将被丢弃。若数据包需要应答，异步调用不适用——应使用标准同步调用或响应流。 - **AWS 失败重试**：Lambda 会自动重试失败的异步调用最多两次。请确保函数（及其启动的下游工作流）具备幂等性，或配置死信队列以捕获失败情况，避免数据静默丢失。 - **与流式传输互斥**：同一目标不能同时启用 `UseAsyncInvoke` 和 `UseResponseStreaming`——两者代表互斥的交付模型。 ## 功能组合应用 两项功能独立存在，但可自然结合实现特定模式：触发长期后端工作流的公共 WireGuard 端点。 设想一个设备预配置服务。设备制造时不预注册密钥——首次启动时生成密钥对，使用共享 PSK 连接开放的 WireGuard 监听器，并发送预配置请求数据包。Lambda 函数接收数据包后启动 Step Functions 状态机处理完整预配置流程——身份注册、证书签发、DynamoDB 记录创建、SNS 通知——随即返回。状态机运行数分钟或数小时。设备不会立即收到应答；配置确认将通过工作流完成后的单独通道送达。 整个过程无需在设备出厂前管理密钥注册表，也无需网关在配置期间保持连接开放。这仅是一个数据包的传入、一个工作流的启动，事件之间无需持续运行基础设施。 该模式同样适用于所有无需立即响应的入站触发工作流，例如需要在执行前启动多步验证的设备指令，以及需要跨系统提供持久化处理保障的审计事件。 ## 开始使用 两项功能现已在 UDP 网关支持的所有区域可用。均无需更改现有监听器或目标配置——`AllowUnknownPeers` 默认为 `false`，现有对等端列表行为保持不变；Lambda 目的地将继续使用同步调用，除非显式设置 `UseAsyncInvoke`。 完整配置详情请参阅 WireGuard 监听器文档 (https://proxylity.com/docs/listeners/wireguard.html#open-endpoints) 和 Lambda 目标文档 (https://proxylity.com/docs/destinations/lambda.html)。完整的 CloudFormation 属性参考——包括 AllowUnknownPeers (https://proxylity.com/docs/cloudformation/listener.html#allowunknownpeers) 和 UnknownPeerPreSharedKey (https://proxylity.com/docs/cloudformation/listener.html#unknownpeerpresharedkey)——涵盖了所有选项，包括在同一监听器上混合使用命名对等端与未知对等端的配置方案。