翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# オーソライザーのトラブルシューティング
<a name="custom-auth-troubleshooting"></a>

 このトピックでは、カスタム認証ワークフローで問題を引き起こす可能性のある一般的な問題と、それらを解決するための手順について説明します。問題を最も効果的にトラブルシューティングするには、 の CloudWatch Logs を有効に AWS IoT Core し、ログレベルを **DEBUG** に設定します。 AWS IoT Core コンソール ([https://console.aws.amazon.com/iot/](https://console.aws.amazon.com/iot/)) で CloudWatch ログを有効にできます。 AWS IoT Coreのログの有効化と設定の詳細については、「[AWS IoT ログ記録の設定](configure-logging.md)」を参照してください。

**注記**  
ログレベルを長期間 **DEBUG** のままにしておくと、CloudWatch は大量のログデータを保存する可能性があります。これにより、CloudWatch の料金が増加する可能性があります。リソースベースのログ記録を使用して、特定のモノのグループ内のデバイスのみの詳細度を高めることを検討してください。リソースベースのログ記録の詳細については、「[AWS IoT ログ記録の設定](configure-logging.md)」を参照してください。また、トラブルシューティングが完了したら、ログレベルの詳細度を引き下げます。

トラブルシューティングを開始する前に、[カスタム認証ワークフローについて](custom-authorizer.md) でカスタム認証プロセスの概要を確認してください。これは、問題の原因を見つけるのにどこを確認すればよいかを理解するのに役立ちます。

このトピックでは、調査する次の 2 つの領域について説明します。
+ オーソライザーの Lambda 関数に関連する問題。
+ デバイスに関連する問題。

## オーソライザーの Lambda 関数に問題がないか確認する
<a name="custom-auth-troubleshooting-lambda"></a>

次の手順を実行して、デバイスの接続試行が Lambda 関数を呼び出していることを確認します。

1. オーソライザーに関連付けられている Lambda 関数を確認します。

   これを行うには、[DescribeAuthorizer](https://docs.aws.amazon.com/iot/latest/apireference/API_DescribeAuthorizer.html) API を呼び出すか、 AWS IoT Core コンソールの [**Secure**] (安全性) セクションで目的のオーソライザーをクリックします。

1. Lambda 関数の呼び出しメトリクスを確認します。これを行うには、次の手順を実行します。

   1.  AWS Lambda コンソール ([https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/)) を開き、オーソライザーに関連付けられている関数を選択します。

   1. [**Monitor**] (監視) タブを選択し、問題に関連する時間枠のメトリクスを表示します。

1. 呼び出しが表示されない場合は、 AWS IoT Core に Lambda 関数を呼び出すアクセス許可があることを確認します。呼び出しが表示された場合は、次の手順に進みます。次の手順を実行して、Lambda 関数に必要なアクセス許可があることを確認します。

   1.  AWS Lambda コンソールで 関数の**アクセス許可**タブを選択します。

   1. ページの下部にある [**Resource-based Policy**] (リソースベースのポリシー) セクションを見つけます。Lambda 関数に必要なアクセス許可がある場合、ポリシーは次の例のようになります。  
****  

      ```
      {
        "Version":"2012-10-17",		 	 	 
        "Id": "default",
        "Statement": [
          {
            "Sid": "Id123",
            "Effect": "Allow",
            "Principal": {
              "Service": "iot.amazonaws.com"
            },
            "Action": "lambda:InvokeFunction",
            "Resource": "arn:aws:lambda:us-east-1:111111111111:function:FunctionName",
            "Condition": {
              "ArnLike": {
                "AWS:SourceArn": "arn:aws:iot:us-east-1:111111111111:authorizer/AuthorizerName"
              },
              "StringEquals": {
                "AWS:SourceAccount": "111111111111"
              }
            }
          }
        ]
      }
      ```

   1. このポリシーは、関数に対する アクセス`InvokeFunction`許可を AWS IoT Core プリンシパルに付与します。表示されない場合は、[AddPermission](https://docs.aws.amazon.com/lambda/latest/dg/API_AddPermission.html) API を使用して追加する必要があります。次の例では、 AWS CLIを使用してこの操作を行う方法を示しています。

      ```
      aws lambda add-permission --function-name FunctionName --principal iot.amazonaws.com --source-arn AuthorizerARn --statement-id Id-123 --action "lambda:InvokeFunction"
      ```

1. 呼び出しが表示された場合は、エラーがないことを確認します。エラーは、Lambda 関数が AWS IoT Core が送信する接続イベントを適切に処理していないことを示している可能性があります。

   Lambda 関数でのイベントの処理については、[Lambda 関数の定義](custom-auth-lambda.md) を参照してください。 AWS Lambda コンソール ([https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/)) のテスト機能を使用して、関数のテスト値をハードコードし、関数がイベントを正しく処理していることを確認します。

1. エラーのない呼び出しが表示されても、デバイスが接続 (またはメッセージを発行、サブスクライブ、および受信) できない場合、問題は、Lambda 関数が返すポリシーが、デバイスが実行しようとしているアクションのためのアクセス許可を付与しないことである可能性があります。関数が返すポリシーに問題があるかどうかを判断するには、次の手順を実行します。

   1. Amazon CloudWatch Logs Insights クエリを使用して、短期間にログをスキャンし、エラーがないか確認します。次のクエリ例では、イベントをタイムスタンプでソートし、エラーを探します。

      ```
      display clientId, eventType, status, @timestamp | sort @timestamp desc | filter status = "Failure"    
      ```

   1. Lambda 関数を更新して、返されるデータと関数 AWS IoT Core をトリガーするイベントをログに記録します。これらのログを使用して、関数が作成するポリシーを検査できます。

1. 呼び出しにエラーがないにもかかわらず、デバイスが接続できない (またはメッセージを発行、サブスクライブ、受信できない) 場合は、別の原因として、Lambda 関数がタイムアウト制限を超えている可能性があります。カスタムオーソライザーの Lambda 関数のタイムアウト制限は 5 秒です。関数の期間は、CloudWatch ログまたはメトリクスで確認できます。

## デバイスの問題の調査
<a name="custom-auth-troubleshooting-investigate"></a>

Lambda 関数の呼び出しに問題がない場合や、関数が返すポリシーに問題がない場合は、デバイスの接続試行に問題がないか確認してください。不正な形式の接続リクエストにより、 がオーソライザーをトリガー AWS IoT Core しない可能性があります。接続の問題は、TLS レイヤーとアプリケーションレイヤーの両方で発生する可能性があります。

**考えられる TLS レイヤーの問題:**
+ お客様は、すべてのカスタム認証リクエストで、ホスト名ヘッダー (HTTP、MQTT over WebSockets) または Server Name Indication TLS 拡張 (HTTP、MQTT over WebSockets、MQTT) を渡す必要があります。どちらの場合も、渡される値はアカウントの AWS IoT Core データエンドポイントの 1 つと一致する必要があります。これらは、次の CLI コマンドを実行したときに返されるエンドポイントです。
  + `aws iot describe-endpoint --endpoint-type iot:Data-ATS`
  + `aws iot describe-endpoint --endpoint-type iot:Data` (レガシー VeriSign エンドポイント)
+ MQTT 接続にカスタム認証を使用するデバイスは、`mqtt` の値の Application Layer Protocol Negotiation (ALPN) TLS 拡張も渡す必要があります。
+ カスタム認証は現在、ポート 443 でのみ使用できます。

**考えられるアプリケーションレイヤーの問題:**
+ 署名が有効になっている場合 (オーソライザーで `signingDisabled` フィールドが false の場合)、次の署名の問題がないかを確認します。
  + `x-amz-customauthorizer-signature` ヘッダーまたはクエリ文字列パラメータのいずれかでトークン署名を渡していることを確認してください。
  + サービスがトークン以外の値に署名していないことを確認してください。
  + オーソライザーの `token-key-name` フィールドで指定したヘッダーまたはクエリパラメータでトークンを渡すようにしてください。
+ `x-amz-customauthorizer-name` ヘッダーまたはクエリ文字列パラメータで渡すオーソライザー名が有効であること、またはアカウント用にデフォルトのオーソライザーが定義されていることを確認してください。