Lösung von Verbindungsproblemen beim AWS IoT sicheren Tunneling durch rotierende Client-Zugriffstoken

Wenn Sie AWS IoT Secure Tunneling verwenden, können Verbindungsprobleme auftreten, auch wenn der Tunnel geöffnet ist. Die folgenden Abschnitte zeigen einige mögliche Probleme und wie Sie diese durch Rotation der Client-Zugriffstoken lösen können. Um das Client Access Token (CAT) zu rotieren, verwenden Sie die RotateTunnelAccessTokenAPI oder die. rotate-tunnel-access-token AWS CLI Je nachdem, ob bei der Verwendung des Clients im Quell- oder Zielmodus ein Fehler auftritt, können Sie das CAT entweder im Quell- oder Zielmodus oder in beiden Modi rotieren.

Anmerkung

• Wenn Sie sich nicht sicher sind, ob das CAT an der Quelle oder am Ziel rotiert werden muss, können Sie das CAT sowohl an der Quelle als auch am Ziel rotieren, indem Sie ClientMode auf ALL setzen bei der Verwendung der RotateTunnelAccessToken-API.

• Durch das Rotieren des CAT wird die Tunneldauer nicht verlängert. Nehmen wir zum Beispiel an, die Tunneldauer beträgt 12 Stunden und der Tunnel ist bereits seit 4 Stunden geöffnet. Wenn Sie die Zugriffstoken rotieren, können die neu generierten Token nur für die verbleibenden 8 Stunden verwendet werden.

Fehler beim ungültigen Client-Zugriffstoken

Wenn Sie AWS IoT Secure Tunneling verwenden, kann es zu einem Verbindungsfehler kommen, wenn Sie dasselbe Clientzugriffstoken (CAT) verwenden, um die Verbindung zum gleichen Tunnel wiederherzustellen. In diesem Fall kann der lokale Proxy keine Verbindung zum Secure Tunneling-Proxyserver herstellen. Wenn Sie einen Client im Quellmodus verwenden, wird möglicherweise die folgende Fehlermeldung angezeigt:

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

Der Fehler tritt auf, weil das Client-Zugriffstoken (CAT) vom lokalen Proxy nur einmal verwendet werden kann und dann ungültig wird. Um diesen Fehler zu beheben, wechseln Sie das Client-Zugriffstoken in den SOURCE Modus, in dem ein neues CAT für die Quelle generiert wird. Ein Beispiel, das zeigt, wie Sie das Quell-CAT rotieren, finden Sie unter Beispiel für „Quell-CAT rotieren“.

Fehler bei Nichtübereinstimmung der Client-Tokens

Anmerkung

Die Verwendung von Client-Tokens zur Wiederverwendung des CAT wird nicht empfohlen. Wir empfehlen, stattdessen die RotateTunnelAccessToken-API zu verwenden, um die Client-Zugriffstoken zu rotieren, um die Verbindung zum Tunnel wiederherzustellen.

Wenn Sie Client-Token verwenden, können Sie das CAT wiederverwenden, um die Verbindung zum Tunnel wiederherzustellen. Um die CAT wiederzuverwenden, müssen Sie dem Client-Token die CAT zur Verfügung stellen, wenn Sie zum ersten Mal eine Verbindung zu Secure Tunneling herstellen. Secure Tunneling speichert das Client-Token, sodass für nachfolgende Verbindungsversuche mit demselben Token auch das Client-Token bereitgestellt werden muss. Weitere Informationen zur Verwendung von Client-Tokens finden Sie in der Referenzimplementierung für lokale Proxys unter. GitHub

Wenn Sie Client-Token verwenden und einen Client im Quellmodus verwenden, wird möglicherweise der folgende Fehler angezeigt:

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

Der Fehler tritt auf, weil das bereitgestellte Client-Token nicht mit dem Client-Token übereinstimmt, das beim Zugriff auf den Tunnel mit dem CAT bereitgestellt wurde. Um diesen Fehler zu beheben, rotieren Sie den CAT in dem SOURCE Modus, um ein neues CAT für die Quelle zu erzeugen. Im Folgenden sehen Sie ein Beispiel:

Beispiel für „Quell-CAT rotieren“

Im Folgenden finden Sie ein Beispiel dafür, wie die RotateTunnelAccessToken API im SOURCE-Modus zum Generieren einer neuen CAT für die Quelle ausgeführt wird:

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

Wenn Sie diesen Befehl ausführen, wird ein neues Quellzugriffstoken generiert und der ARN Ihres Tunnels zurückgegeben.

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

Sie können jetzt das neue Quell-Token verwenden, um den lokalen Proxy im Quellmodus zu verbinden.

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

Im Folgenden finden Sie ein Beispiel für die Ausgabe der Ausführung des lokalen Proxys:

...

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

Verbindungsprobleme bei Remote-Geräten

Bei Verwendung von AWS IoT Secure Tunneling wird die Verbindung zum Gerät möglicherweise unerwartet unterbrochen, selbst wenn der Tunnel geöffnet ist. Um festzustellen, ob ein Gerät noch mit dem Tunnel verbunden ist, können Sie die DescribeTunnelAPI oder den Describe-Tunnel verwenden. AWS CLI

Ein Gerät kann aus mehreren Gründen unterbrochen werden. Um das Verbindungsproblem zu beheben, können Sie das CAT auf das Zielgerät rotieren, falls die Verbindung zum Gerät aus den folgenden möglichen Gründen unterbrochen wurde:

• Das CAT auf dem Ziel wurde ungültig.

• Das Token wurde nicht über das für Secure Tunneling reservierte MQTT-Thema an das Gerät übermittelt:

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

Das folgende Beispiel veranschaulicht, wie dieses Problem gelöst werden kann:

Beispiel für die Rotation des Ziel-CAT

Man nehme ein Remote-Gerät, <RemoteThing1>. Um einen Tunnel für dieses Objekt zu öffnen, können Sie den folgenden Befehl verwenden:

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

Wenn Sie diesen Befehl ausführen, werden die Tunneldetails und das CAT für Ihre Quelle und Ihr Ziel generiert.

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

Wenn Sie die DescribeTunnelAPI verwenden, zeigt die Ausgabe jedoch an, dass das Gerät getrennt wurde, wie unten dargestellt:

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

Wenn Sie diesen Befehl ausführen, wird angezeigt, dass das Gerät immer noch nicht verbunden ist.

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

Um diesen Fehler zu beheben, führen Sie die RotateTunnelAccessToken API mit dem Client im DESTINATION-Modus und den Konfigurationen für das Ziel aus. Wenn Sie diesen Befehl ausführen, wird das alte Zugriffstoken gesperrt, ein neues Token generiert und dieses Token erneut an das MQTT-Thema gesendet:

$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>			
			

Durch die Ausführung dieses Befehls wird das neue Zugriffstoken wie unten dargestellt generiert. Das Token wird dann an das Gerät übermittelt, um eine Verbindung zum Tunnel herzustellen, sofern der Geräteagent korrekt eingerichtet ist.

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