Résolution des problèmes de connectivité liés au tunneling AWS IoT sécurisé en faisant pivoter les jetons d'accès client

Lorsque vous utilisez le tunneling AWS IoT sécurisé, vous pouvez rencontrer des problèmes de connectivité même si le tunnel est ouvert. Les sections suivantes présentent certains problèmes possibles et indiquent comment les résoudre en faisant pivoter les jetons d'accès client. Pour faire pivoter le jeton d'accès client (CAT), utilisez l'RotateTunnelAccessTokenAPI ou le rotate-tunnel-access-token AWS CLI. Selon que vous rencontrez une erreur lors de l'utilisation du client en mode source ou en mode destination, vous pouvez faire pivoter le CAT en mode source ou en mode destination, ou les deux.

Note

• Si vous ne savez pas si le CAT doit être pivoté sur la source ou sur la destination, vous pouvez le faire pivoter à la fois sur la source et sur la destination en réglant sur ClientMode ALL lorsque vous utilisez l'RotateTunnelAccessTokenAPI.

• La rotation du CAT ne prolonge pas la durée du tunnel. Par exemple, supposons que la durée du tunnel soit de 12 heures et que le tunnel soit déjà ouvert depuis 4 heures. Lorsque vous alternez les jetons d'accès, les nouveaux jetons générés ne peuvent être utilisés que pendant les 8 heures restantes.

Erreur de jeton d'accès client non valide

Lorsque vous utilisez le tunneling AWS IoT sécurisé, vous pouvez rencontrer une erreur de connexion lorsque vous utilisez le même jeton d'accès client (CAT) pour vous reconnecter au même tunnel. Dans ce cas, le proxy local ne peut pas se connecter au serveur proxy de tunneling sécurisé. Si vous utilisez un client en mode source, le message d'erreur suivant peut s'afficher :

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

L'erreur se produit parce que le jeton d'accès client (CAT) ne peut être utilisé qu'une seule fois par le proxy local, puis il devient invalide. Pour résoudre cette erreur, faites pivoter le jeton d'accès client dans le SOURCE mode afin de générer un nouveau CAT pour la source. Pour voir un exemple qui montre comment faire pivoter le CAT source, consultezExemple CAT de rotation de la source.

Erreur de non-concordance du jeton client

Note

Il n'est pas recommandé d'utiliser des jetons clients pour réutiliser le CAT. Nous vous recommandons plutôt d'utiliser l'RotateTunnelAccessTokenAPI pour faire pivoter les jetons d'accès client afin de vous reconnecter au tunnel.

Si vous utilisez des jetons clients, vous pouvez réutiliser le CAT pour vous reconnecter au tunnel. Pour réutiliser le CAT, vous devez fournir le jeton client au CAT la première fois que vous vous connectez au tunneling sécurisé. Le tunneling sécurisé stocke le jeton client. Ainsi, pour les tentatives de connexion ultérieures utilisant le même jeton, le jeton client doit également être fourni. Pour plus d'informations sur l'utilisation des jetons client, consultez l'implémentation de référence du proxy local dans GitHub.

Lorsque vous utilisez des jetons client, si vous utilisez un client en mode source, le message d'erreur suivant peut s'afficher :

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

L'erreur se produit parce que le jeton client fourni ne correspond pas au jeton client fourni avec le CAT lors de l'accès au tunnel. Pour résoudre cette erreur, faites pivoter le CAT dans le SOURCE mode afin de générer un nouveau CAT pour la source. Voici un exemple:

Exemple CAT de rotation de la source

L'exemple suivant montre comment exécuter l'RotateTunnelAccessTokenAPI dans le SOURCE mode permettant de générer un nouveau CAT pour la source :

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

L'exécution de cette commande génère un nouveau jeton d'accès à la source et renvoie l'ARN de votre tunnel.

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

Vous pouvez désormais utiliser le nouveau jeton source pour connecter le proxy local en mode source.

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

Voici un exemple de résultat de l'exécution du proxy local :

...

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

Problèmes de connectivité de l'appareil à distance

Lorsque vous utilisez le tunneling AWS IoT sécurisé, l'appareil peut se déconnecter de façon inattendue même si le tunnel est ouvert. Pour savoir si un appareil est toujours connecté au tunnel, vous pouvez utiliser l'DescribeTunnelAPI ou le AWS CLI describe-tunnel.

Un appareil peut être déconnecté pour plusieurs raisons. Pour résoudre le problème de connectivité, vous pouvez faire pivoter le CAT sur la destination si l'appareil a été déconnecté pour les raisons suivantes :

• Le CAT de destination est devenu invalide.

• Le jeton n'a pas été livré à l'appareil via le sujet MQTT réservé au tunneling sécurisé :

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

L'exemple suivant montre comment résoudre ce problème :

Exemple CAT de rotation de la destination

Envisagez un appareil distant,<RemoteThing1>. Pour ouvrir un tunnel à cet effet, vous pouvez utiliser la commande suivante :

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

L'exécution de cette commande génère les détails du tunnel et le CAT pour votre source et votre destination.

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

Toutefois, lorsque vous utilisez l'DescribeTunnelAPI, le résultat indique que l'appareil a été déconnecté, comme illustré ci-dessous :

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

L'exécution de cette commande indique que le périphérique n'est toujours pas connecté.

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

Pour résoudre cette erreur, exécutez l'RotateTunnelAccessTokenAPI avec le client en DESTINATION mode et les configurations pour la destination. L'exécution de cette commande révoque l'ancien jeton d'accès, génère un nouveau jeton et renvoie ce jeton à la rubrique 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>			
			

L'exécution de cette commande génère le nouveau jeton d'accès, comme indiqué ci-dessous. Le jeton est ensuite envoyé à l'appareil pour qu'il se connecte au tunnel, si l'agent du périphérique est correctement configuré.

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