UDP ゲートウェイの新機能：Open Endpoints と非同期呼び出しの実装

UDP ゲートウェイに新たに 2 つの機能が本日導入されました。これにより、公開型のイベント駆動型 WireGuard サービスを以前より容易に構築でき、新たな可能性が開かれます。

• 新機能 1（Open Endpoints）：WireGuard リスナーが事前に登録されていないクライアントからの接続を受け入れることを可能にし、HTTPS のモデルと同じアプローチを実現します。
• 新機能 2（非同期呼び出し）：Lambda の宛先を非同期的に呼び出すことで、ゲートウェイがレスポンスを待機せずにパケットを長時間実行されるワークフローへ送ることができます。

「Open Endpoints」による未知のピアへの対応

WireGuard リスナーでは、これまで接続するすべてのクライアントを事前に登録する必要がありました。これに対し、新しい

AllowUnknownPeers

従来モデルの課題

• 事前登録必須：CloudFormation テンプレートで各ピアの公開鍵をリスト化し、リスナーはそれ以外の鍵からのハンドシェイクを拒否していました。
• スケーラビリティの問題：管理されたデバイスセットを持つプライベートサービスには最適でしたが、以下のようなケースには不向きでした。
  • 初回起動時にキーペアを生成するモバイルアプリ
  • オンデマンドでプロビジョニングされる多数のデバイス（中央集権的な鍵管理が運用上不切実な場合）
  • 以前見たことのないクライアントからの接続を許容すべき公開サービス
• 登録手順の必要性：従来のモデルでは、未知のクライアントがハンドシェイクを完了させる前に別途 CloudFormation の更新が必要でした。

新機能の詳細

• 設定方法：WireGuard リスナーで

  AllowUnknownPeers

  を

  true

  に設定します。
• 動作内容：ゲートウェイはピアの公開鍵がリスト化されていなくても、有効な WireGuard クライアントとハンドシェイクを完了します。
• セキュリティとの相性：
  • 接続は依然として完全に暗号化されています。
  • WireGuard の暗号学的特性には何ら変化はありません。
  • リスナーが事前に鍵を知っていることを要求しなくなった点が唯一の違いです。

HTTPS との類推

この設計は、HTTPS がウェブサイトを訪れる際の挙動と似ています。

• サーバーは暗号化された接続を確立する前にクライアントの正体を把握する必要がありません。
• TLS ハンドシェイクが完了すればチャネルは暗号化され、認証はアプリケーション層での別課題として扱われます。
• 「Open WireGuard Endpoints」も同様で、トランスポート層では暗号化が適用され、識別子は Lambda または Step Functions の宛先に、アプリケーション要件に従って処理されます。

共有秘密鍵によるアクセス制限ゲートの追加

「文字通りあらゆるクライアントを受け入れる」という完全な開放登録は一部のサービスには不向きです。そこで、暗号化と開放的なハンドシェイクを保ちつつ、秘密鍵を発行されていないクライアントからの接続を防ぐために

UnknownPeerPreSharedKey

動作メカニズム

• 設定条件：

  UnknownPeerPreSharedKey

  が設定されている場合、未知のピアは WireGuard 構成にその PSK（事前共有鍵）を含める必要があり、そうでない場合はハンドシェイクが失敗します。
• 認証モデル：
  • デバイスごとの個別認証ではなく、すべてのクライアントが同一の秘密を使用します。
  • 強力なアイデンティティではありませんが、認証されていない任意のクライアントからの接続に対する実質的なバリアとなります。
• アクセス制限：PSK が発行されたクライアントへのアクセスを有意義に制限できます。

インフラ構成と運用責任

• 共有秘密鍵（PSK）の配布はアプリケーション側の責任です。
  • インフラ側：AWS Secrets Manager に保存し CloudFormation スタックから参照。
  • クライアント側：製造時または登録時にデバイスにプロビジョン。

CloudFormation 構成例

命名ピアと未知のピアを単一のリスナーで共存させる構成です。固定された既知のデバイスに対し個別認証を行い、動的クライアントは共有 PSK で保護します。

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

  アレイにリストされたピアは影響を受けず、従来通りピアごとの

  SharedSecret

  を使用します。

Lambda の非同期呼び出し

UDP ゲートウェイにおける Lambda 宛先は、これまで常に同期型のリクエスト・レスポンス方式（パケットバッチの配信後、関数の完了を待機し、戻り値で返信）でした。しかし、長時間実行されるワークロードではこの方式には限界があります。

「Lambda Durable Functions」による解決

• 課題：単回の呼び出しを超えた処理を行う場合、同期型方式は不向きです。
• 解決策：

  Lambda durable functions

  を採用し、チェックポイント・アンド・リプレイ機構により最大 1 年まで実行でき、故障から自動的に再開される設計にします。

非同期呼び出しの導入 (

UseAsyncInvoke

)

新しい

UseAsyncInvoke

• 動作フロー：
  1. ゲートウェイがパケットバッチを配信し、即時

     HTTP 202 Accepted

     を受信します（関数の完了を待機しません）。
  2. UDP クライアントへの返信は行われません。
  3. 関数はゲートウェイのリクエストライフサイクルとは独立して完全に実行されます。
• 主なユースケース：耐久的なワークロードのトリガーです。

CloudFormation 構成例

Destinations:
  - Name: workflow-trigger
    DestinationArn: !GetAtt WorkflowTriggerLambda.Arn
    Role:
      Arn: !GetAtt ProxylityRole.Arn
    Arguments:
      UseAsyncInvoke: "true"

留意事項（非同期呼び出しを使用する場合）

• 返信なし：関数の戻り値は破棄されます。パケットへの即座な返信が必要な場合は、非同期呼び出しを避け標準的な同期方式またはレスポンスストリーミングを使用してください。
• 故障時の AWS リトライ：Lambda は失敗した非同期呼び出しを自動的に最多 2 回リトライします。関数が冪等であることを確認するか、デッドレターキューを設定してデータを失わずキャプチャしてください。
• ストリーミングとの互換性：

  UseAsyncInvoke

  と

  UseResponseStreaming

  は同じ宛先では同時に設定できません（相反する配信モデルです）。

両機能の組み合わせ

上記 2 つの機能は相互に独立していますが、公開型の WireGuard エンドポイントが長時間実行されるバックエンドワークフローをトリガーするパターンで自然に組み合わさります。

デバイスプロビジョニングサービスの例

1. 初回起動：デバイスは事前登録キーを持たず、初回ブート時にキーペアを生成します。
2. 接続と送信：共有 PSK を用いて開放的な WireGuard リスナーへ接続し、プロビジョニング要求パケットを送信します（

   AllowUnknownPeers: true

   ）。
3. 非同期処理：Lambda 関数がパケットを受け取り、Step Functions ステートマシンを開始します。
   • アイデンティティ登録、証明書の発行、DynamoDB レコード作成、SNS 通知などを処理。
   • ワークフローは数分乃至数時間実行され、チェックポイント化されます。
4. 完了：ステートマシンが完了し、デバイスは即座な返信を待たずに別のチャネルから確認を受けます。

メリット

• キーレジストリの事前管理が不要。
• ゲートウェイがプロビジョニング全期間接続を開いたままにする必要がない。
• 「パケット投入 → ワークフロー開始」により、イベント間で動作するインフラストラクチャ（長期間接続を保持する必要があるもの）が不要になります。

このパターンは、実行前に多段階検証を開始するデバイスコマンドや、複数システム間での耐久的な処理保証が必要な監査イベントなど、送信者が即座の応答を必要としないあらゆる入方向トリガー型のワークフローに適用できます。

初回ステップ

両機能は既に UDP ゲートウェイがサポートされているすべてのリージョンで利用可能です。既存のリスナーまたは宛先に変更を必要としません。

• AllowUnknownPeers

  ：デフォルトは

  false

  です。既存のピアリスト動作は変更されず、このオプションを設定しない限り従来の動作が続きます。
• Lambda 宛先：明示的に

  UseAsyncInvoke

  を設定しない限り、同期呼び出し方式を継続します。

詳細な構成については、WireGuard リスナードキュメント と Lambda 宛先ドキュメント をご参照ください。