

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

# クライアントアクセストークンをローテーションして AWS IoT 安全なトンネリング接続の問題を解決する
<a name="iot-secure-tunneling-troubleshooting"></a>

 AWS IoT セキュアトンネリングを使用すると、トンネルが開いている場合でも接続の問題が発生する可能性があります。次のセクションでは、発生する可能性のある問題と、クライアントアクセストークンをローテーションして解決する方法について説明します。クライアントアクセストークン (CAT) をローテーションするには、[RotateTunnelAccessToken](https://docs.aws.amazon.com/iot/latest/apireference/API_iot-secure-tunneling_RotateTunnelAccessToken.html) API または [rotate-tunnel-access-token](https://docs.aws.amazon.com/cli/latest/reference/iotsecuretunneling/rotate-tunnel-access-token.html) AWS CLIを使用します。クライアントを送信元モードまたは宛先モードのどちらで使用する場合にエラーが発生するかに応じて、送信元モードまたは宛先モード、あるいはその両方で CAT をローテーションできます。

**注記**  
送信元と宛先のどちらで CAT をローテーションする必要があるか不明な場合は、`RotateTunnelAccessToken` API 使用時に `ClientMode` を ALL に設定することで、送信元と宛先の両方で CAT をローテーションできます。
CAT をローテーションしてもトンネル期間は延長されません。例えば、トンネル期間が 12 時間で、トンネルが既に 4 時間開かれているとします。アクセストークンをローテーションすると、生成された新しいトークンは残りの 8 時間だけ使用できます。

**Topics**
+ [無効なクライアントアクセストークンのエラー](#invalid-access-token)
+ [クライアントトークンの不一致エラー](#client-token-mismatch)
+ [リモートデバイスの接続性に関する問題](#tunnel-open-device-error)

## 無効なクライアントアクセストークンのエラー
<a name="invalid-access-token"></a>

 AWS IoT セキュアトンネリングを使用する場合、同じクライアントアクセストークン (CAT) を使用して同じトンネルに再接続するときに、接続エラーが発生することがあります。この場合、ローカルプロキシはセキュアトンネリングプロキシサーバーに接続できません。クライアントを送信元モードで使用している場合は、次のエラーメッセージが表示されることがあります。

```
Invalid access token: The access token was previously used and cannot be used again
```

このエラーは、クライアントアクセストークン (CAT) がローカルプロキシで一度しか使用できず、その後無効となるために発生します。このエラーを解決するには、クライアントアクセストークンを `SOURCE` モードでローテーションさせ、送信元に新しい CAT を生成します。送信元 CAT をローテーションする方法の例については、「[送信元 CAT のローテーションの例](#rotate-token-source-example)」を参照してください。

## クライアントトークンの不一致エラー
<a name="client-token-mismatch"></a>

**注記**  
クライアントトークンを使用して CAT を再利用することは推奨されていません。代わりに、`RotateTunnelAccessToken` API を使用してクライアントアクセストークンをローテーションし、トンネルに再接続することをお勧めします。

クライアントトークンを使用している場合は、トンネルへの再接続に CAT を再利用できます。CAT を再利用するには、セキュアトンネリングに初めて接続するときに、クライアントトークンに CAT を提供する必要があります。セキュアトンネリングはクライアントトークンを保存するため、同じトークンを使用してその後に接続を試みる場合は、クライアントトークンも提供する必要があります。クライアントトークンの使用方法の詳細については、「[GitHub でのローカルプロキシリファレンスの実装](https://github.com/aws-samples/aws-iot-securetunneling-localproxy/blob/master/V2WebSocketProtocolGuide.md)」を参照してください。

クライアントトークンを使用している場合、クライアントを送信元モードで使用していると、次のエラーが表示されることがあります。

```
Invalid client token: The provided client token does not match the client token 
				that was previously set.
```

このエラーは、提供されたクライアントトークンが、トンネルにアクセスするときに CAT で提供されたクライアントトークンと一致しないために発生します。このエラーを解決するには、CAT を `SOURCE` モードでローテーションさせ、送信元に新しい CAT を生成します。例を以下に示します。

### 送信元 CAT のローテーションの例
<a name="rotate-token-source-example"></a>

以下は、`RotateTunnelAccessToken` API を `SOURCE` モードで実行して、送信元の新しい CAT を生成する方法の例です。

```
aws iotsecuretunneling rotate-tunnel-access-token \ 
    --region <region> \ 
    --tunnel-id <tunnel-id> \ 
    --client-mode SOURCE
```

このコマンドを実行すると、新しい送信元アクセストークンが生成され、トンネルの ARN が返されます。

```
{
    "sourceAccessToken": "<source-access-token>", 
    "tunnelArn": "arn:aws:iot:<region>:<account-id>:tunnel/<tunnel-id>"
}
```

これで、新しい送信元トークンを使用して、ローカルプロキシを送信元モードで接続できます。

```
export AWSIOT_TUNNEL_ACCESS_TOKEN=<source-access-token>
./localproxy -r <region> -s <port>
```

以下は、ローカルプロキシを実行したサンプル出力です。

```
...

[info]    Starting proxy in source mode
...
[info]    Successfully established websocket connection with proxy server ...
[info]    Listening for new connection on port <port>
...
```

## リモートデバイスの接続性に関する問題
<a name="tunnel-open-device-error"></a>

 AWS IoT セキュアトンネリングを使用すると、トンネルが開いている場合でもデバイスが予期せず切断される可能性があります。デバイスがトンネルにまだ接続されているかどうかを確認するには、[DescribeTunnel](https://docs.aws.amazon.com/iot/latest/apireference/API_iot-secure-tunneling_DescribeTunnel.html) API または [describe-tunnel](https://docs.aws.amazon.com/cli/latest/reference/iotsecuretunneling/describe-tunnel.html) AWS CLIを使用できます。

デバイスは、複数の理由で切断されることがあります。デバイスが以下の考えられる理由によって切断された場合、接続性の問題を解決するには、宛先の CAT をローテーションさせます。
+ 宛先の CAT が無効になった。
+ トークンがセキュアトンネリングの予約済み MQTT トピックを介してデバイスに配信されなかった。

  `$aws/things/<thing-name>/tunnels/notify`

次の例は、この問題を解決する方法を示しています。

### 宛先 CAT のローテーションの例
<a name="rotate-token-dest-example"></a>

リモートデバイス `<RemoteThing1>` を考えてみます。このモノへのトンネルを開くには、次のコマンドを使用できます。

```
aws iotsecuretunneling open-tunnel \ 
    --region <region> \ 
    --destination-config thingName=<RemoteThing1>,services=SSH
```

このコマンドを実行すると、トンネルの詳細と、送信元と宛先の CAT が生成されます。

```
{
    "sourceAccessToken": "<source-access-token>", 
    "destinationAccessToken": "<destination-access-token>", 
    "tunnelId": "<tunnel-id>", 
    "tunnelArn": "arn:aws:iot:<region>:<account-id>:tunnel/tunnel-id"
}
```

ただし、[DescribeTunnel](https://docs.aws.amazon.com/iot/latest/apireference/API_iot-secure-tunneling_DescribeTunnel.html) API の場合、次の図に示すように、出力はデバイスが切断されたことを示します。

```
aws iotsecuretunneling describe-tunnel \ 
    --tunnel-id <tunnel-id> \ 
    --region <region>
```

このコマンドを実行すると、デバイスがまだ接続されていないことが表示されます。

```
{
    "tunnel": {
        ...
        "destinationConnectionState": {
            "status": "DISCONNECTED"
        },
        ...
    }
}
```

このエラーを解決するには、クライアントを `DESTINATION` モードにし、宛先の設定を変更した状態で `RotateTunnelAccessToken` API を実行します。このコマンドを実行すると、古いアクセストークンが取り消され、新しいトークンが生成され、このトークンが MQTT トピックに再送信されます。

`$aws/things/<thing-name>/tunnels/notify`

```
aws iotsecuretunneling rotate-tunnel-access-token \ 
    --tunnel-id <tunnel-id> \ 
    --client-mode DESTINATION \ 
    --destination-config thingName=<RemoteThing1>,services=SSH \ 
    --region <region>
```

このコマンドを実行すると、次に示すように、新しいアクセストークンが生成されます。その後、デバイスエージェントが正しく設定されていれば、トークンはデバイスに配信され、トンネルに接続します。

```
{
    "destinationAccessToken": "destination-access-token", 
    "tunnelArn": "arn:aws:iot:region:account-id:tunnel/tunnel-id"
}
```