Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
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 derRotateTunnelAccessToken
-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.
Themen
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
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:
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:
Man nehme ein Remote-Gerät,
. Um einen Tunnel für dieses Objekt zu öffnen, können Sie den folgenden Befehl verwenden:<RemoteThing1>
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
" }