Lorawan-stack: Fügen Sie einen Abschnitt zur Fehlerbehebung in unserem Leitfaden „Erste Schritte“ hinzu

Hallo, auf jeden Fall ein Daumen hoch. Beim Befolgen der Anleitung bin ich auf ein paar Probleme und offene Fragen gestoßen. Im Moment hänge ich an diesem Fehler. Vielleicht können Sie in der Dokumentation auch darauf verweisen?

@fox27374 kannst du die Entwicklertools des Browsers öffnen und den window.PAGE_DATA einfügen? Sie können dies in der Browserkonsole eingeben, während dieser Fehler angezeigt wird.

Haben Sie auch alle Schritte im Getting Started befolgt, dh zum Erstellen des Console-OAuth-Clients?

Hallo,
Hier ist die window.PAGE_DATA sowie der Befehl, den ich zum Erstellen des oauth-Clients verwende. Ein wichtiger Punkt ist, dass ich meine eigenen Zertifikate verwende (signiert von der Labor-CA).

DATEN
window.PAGE_DATA = { "error": { "code": 7, "message": "error:pkg/web/oauthclient:exchange (token exchange refused)", "details": [{ "@type": "type.googleapis.com/ttn.lorawan.v3.ErrorDetails", "namespace": "pkg/web/oauthclient", "name": "exchange", "message_format": "token exchange refused", "code": 7 }] } };

BEFEHL
docker-compose run --rm stack is-db create-oauth-client --id console --name "Console" --owner admin --secret "SM2CE7335KDAIILCA76KETRHDQTTDAQTDJHBSL6RCOX3WFZFDZ4Q" --redirect-uri "https://lora01.ntslab.loc/console/oauth/callback" --redirect-uri "/console/oauth/callback"

Vielen Dank!
Prost,
Daniel

@fox27374 danke für die zusätzlichen Informationen.

Wie lautet die konfigurierte OAuth-URL, dh die von Ihnen konfigurierte /token -URL? Sie können sensible Inhalte schwärzen.

Können Sie bestätigen, dass lora01.ntslab.loc im Docker-Container aufgelöst wird, vorausgesetzt, Sie führen The Things Stack über Docker aus?

Hallo,

Danke für die Antwort und dass du mir hier geholfen hast. Der Inhalt ist noch nicht sinnvoll, es ist vorerst ein Laboraufbau als Test für eine zukünftige Produktionsumgebung. Ich möchte den Actility-Server loswerden :)

Ja, ich betreibe den TTN-Stack über Docker auf einem Linux-Server. lora01.ntslab.loc ist in der hosts-Datei konfiguriert, daher sollte die Namensauflösung funktionieren.

Die /token-URL lautet:
Token-URL: ' https://lora01.ntslab.loc/oauth/token '

Wenn Sie weitere Informationen benötigen, können Sie sich direkt die Dateien docker -compose.yml und ttn-lw-stack.yml ansehen . Ich verwende auch ein Startskript, um die Initialisierung durchzuführen ( start.sh ).

Vielen Dank im Voraus,
Daniel

Hallo @fox27374

Ja, ich betreibe den TTN-Stack über Docker auf einem Linux-Server. lora01.ntslab.loc ist in der hosts-Datei konfiguriert, daher sollte die Namensauflösung funktionieren.

Meinst du die /etc/hosts Datei deiner Maschine? Dies wirkt sich nicht auf den Docker-Container aus, in dem der Stack ausgeführt wird, was die Ursache des angezeigten Problems sein könnte.

Das könntest du mit folgendem Befehl überprüfen:

$ docker-compose stack exec nc -z lora01.ntslab.loc

Sie sollten etwas in der Art von nc: bad address 'lora01.ntslab.loc' sehen.

Können Sie versuchen, einen extra_hosts -Abschnitt in Ihrer docker-compose.yaml hinzuzufügen, etwa so:

# docker-compose.yaml
services:
  # ...
  stack:
    # ...
    extra_hosts:
      - "lora01.ntslab.loc:YOUR_IP_ADDRESS"
    # ...

Und starten Sie mit docker-compose up -d neu

Die Hostnamenauflösung sollte dann funktionieren. (Aber wenn YOUR_IP_ADDRESS so etwas wie 127.0.0.1 ist, erhalten Sie möglicherweise immer noch einige Fehler.)

Hallo @neoaggelos
Danke für die Info. Ich habe den Hosts-Eintrag entfernt und die IP/den Hostnamen direkt auf dem DNS-Server festgelegt. Zusätzlich habe ich den Eintrag „extra_hosts“ in der docker-compose.yml hinzugefügt.
Ich fürchte, der Fehler besteht immer noch.

Ich habe Ash Shell im Container gestartet und die DNS-Auflösung überprüft:

$ nslookup lora01.ntslab.loc
Name:      lora01.ntslab.loc
Address 1: 172.24.89.120 lora01.ntslab.loc

Das scheint also gut zu sein. Gibt es nach der Fehlermeldung „ Token-Austausch verweigert “ weitere Debugging-Funktionen, die wir für den OAuth-Token-Austausch aktivieren können? Tut mir leid, Sie damit zu beschäftigen....
Danke

Übrigens scheint jemand anders das gleiche Problem zu haben

Hallo @neoaggelos
Danke für die Info. Ich habe den Hosts-Eintrag entfernt und die IP/den Hostnamen direkt auf dem DNS-Server festgelegt. Zusätzlich habe ich den Eintrag „extra_hosts“ in der docker-compose.yml hinzugefügt.

Hmm, mit der richtigen DNS-Konfiguration sollten Sie extra_hosts nicht festlegen müssen.

Ich fürchte, der Fehler besteht immer noch.

Ich habe Ash Shell im Container gestartet und die DNS-Auflösung überprüft:

$ nslookup lora01.ntslab.loc
Name:      lora01.ntslab.loc
Address 1: 172.24.89.120 lora01.ntslab.loc

Das 172.24.89.120 ist dasjenige aus dem von Docker erstellten Netzwerk, was ebenfalls eine mögliche Fehlerursache sein könnte.

Das scheint also gut zu sein. Gibt es nach der Fehlermeldung „ Token-Austausch verweigert “ weitere Debugging-Funktionen, die wir für den OAuth-Token-Austausch aktivieren können? Tut mir leid, Sie damit zu beschäftigen....
Danke

Versuchen Sie, Ihre Cookies zu löschen, und versuchen Sie es auch von einer sauberen Browsersitzung aus. Stellen Sie außerdem sicher, dass die Zertifikate ordnungsgemäß aus dem Stapel cat /var/run/secrets/cert.pem und cat /var/run/secrets/key.pem aus einer Shell innerhalb des Containers gelesen werden, um dies zu überprüfen.

Off-Topic; Haben Sie versucht, den Stack auf localhost einzurichten? Warst du erfolgreich?

Hallo,

Entschuldigung, ich habe nicht erwähnt, dass 172.24.89.120 die IP-Adresse des Servers selbst im Labor ist. Die Docker-Adressen sind 172.9.0.X

Ich mache alle Tests mit einem Browser im privaten Modus, also sind keine Cookies beteiligt. Der Schlüssel und das Zertifikat sind mit dem Benutzer "thethings" lesbar:

/ $ whoami
thethings

/ $ cat /var/run/secrets/key.pem 
-----BEGIN PRIVATE KEY-----
MIIEvwIBADANBgkqhkiG9w0BAQEFAASCBKkwggSlAgEAAoIBAQC7IjZoBd2Mu4Ev
AYDrEh6mBWYw5cRDA02F10OQpbQbm6RigFbODM2owGRyCkkZfAUL2VV9xl5TzdMl
I6IecaA7/F7TpciuiJHmnfRVAbDlPI6EJYybdrU7tmfdeWc/ThuVVNolJFUeap+T
OIzv9MkGbBAF19ju4PJel6z3ef+NUhc5LKfjVQZeieQULX2b9+Hpd4ySdR2Nfzdt
......

Ich werde versuchen, das Setup auf localhost zu ändern, und Sie auf dem Laufenden halten.

Entschuldigung, ich habe nicht erwähnt, dass 172.24.89.120 die IP-Adresse des Servers selbst im Labor ist. Die Docker-Adressen sind 172.9.0.X

Aber kannst du curl https://lora01.ntslab.loc aus dem Container heraus? Wenn nicht, welcher Fehler wird gemeldet?

Hallo,

scheint, als hätten wir es. Der Curl-Hinweis war gut. Dies zeigte, dass die ca.pem nicht im vertrauenswürdigen Zertifikatsspeicher war:

/ # curl https://lora01.ntslab.loc
curl: (60) SSL certificate problem: self signed certificate in certificate chain

Also habe ich das ca.pem-Zertifikat nach /usr/local/share/ca-certificates/ kopiert.

/ $ ls -la /usr/local/share/ca-certificates/ca.pem 
-rw-r--r--    1 thething thething      1310 Apr 14 11:36 /usr/local/share/ca-certificates/ca.pem

indem Sie es zum Abschnitt „volumes“ der Datei „docker-compose.yml“ hinzufügen:

volumes:
      - "./data/blob:/srv/ttn-lorawan/public/blob"
      - "./config/stack:/config:ro"
      - "./config/stack/cert/ca.pem:/usr/local/share/ca-certificates/ca.pem"

Jetzt kann ich mich an der Konsole anmelden und allen Zertifikaten wird vertraut. Fantastisch!

Ist dies die beste/beabsichtigte Möglichkeit, dem TTN-Container ein vertrauenswürdiges Stammzertifikat hinzuzufügen?

Sorry, dass ich zu früh euphorisch bin. Es scheint, als wäre das Auth-Token noch in der DB, deshalb hat alles funktioniert. Nachdem der Container gestartet wurde, musste ich diesen Befehl ausführen, um das ca.pem-Zertifikat zum vertrauenswürdigen Speicher hinzuzufügen:

docker exec -it --user root ttn-server_stack_1 /usr/sbin/update-ca-certificates

Dann kann der OAuth-Client ein Token abrufen und in der DB speichern. Ich kann jetzt arbeiten, aber das sollte nicht die endgültige Lösung sein, denke ich. Irgendwelche Ideen?
Vielen Dank!

@fox27374 toll, dass du die Ursache gefunden hast. Das ist immer ein guter Anfang, um eine saubere Lösung zu finden.

Der Stapel respektiert TTN_LW_TLS_ROOT_CA (oder tls.root-ca ), einen Dateinamen, mit Ihrer Zertifizierungsstelle. Siehe https://thethingsstack.io/v3.7.0/reference/configuration/the-things-stack/

@johanstokking : Ich habe Folgendes zur docker-compose.yml hinzugefügt

......
    secrets:
      - cert.pem
      - key.pem
      - ca.pem

secrets:
  cert.pem:
    file: config/stack/cert/cert.pem
  key.pem:
    file: config/stack/cert/key.pem
  ca.pem:
    file: config/stack/cert/ca.pem

Auf diese Weise sind die Zertifikatsdateien im Container in /run/secrets und /var/run/secrets verfügbar. Ich habe dies direkt im Container überprüft.

Ich fügte hinzu
TTN_LW_TLS_ROOT_CA: "/var/run/secrets/ca.pem"
in die docker-compose.yml- Datei. Der Fehler ist immer noch da. Ich habe auch versucht, dies der ttn-lw-stack.yml hinzuzufügen :

tls:
  source: "file"
  root-ca: "/var/run/secrets/ca.pem"
  certificate: "/var/run/secrets/cert.pem"
  key: "/var/run/secrets/key.pem"

Das selbe hier. Ich bekomme immer noch den Fehler. Könnte es sein, dass einige Anwendungen, insbesondere der OAuth-Client, die betriebssysteminternen vertrauenswürdigen Stammzertifikate verwenden? Denn sobald ich die ca.pem zu den vertrauenswürdigen Stammzertifikaten hinzufüge, funktioniert alles.
Danke, Daniel

cc @adriansmares

Hallo, gibt es hier Neuigkeiten? Ich habe versucht, den Zugriff auf die vertrauenswürdigen Stammzertifikate mit strace zu debuggen, war aber nicht erfolgreich.

@fox27374 kannst du überprüfen, ob das funktioniert?

$ curl -cacert /var/run/secrets/ca.pem https://lora01.ntslab.loc

@adriansmares sieht so aus, als bräuchten wir zwei Dinge;

1. Melden Sie die zugrunde liegende Fehlerursache, möglicherweise als Grundattribut, da es sich um einen net -Fehler oder eine andere stdlib handelt
2. Stellen Sie sicher, dass wir tls.root-ca im OAuth-Client respektieren

Hallo Leute,

Ich erhalte den gleichen 403-Fehler, wenn ich TTN-Stack v3 mit Docker in einer Vagrant-Box (mit Virtual Box) ausführe. - Nur eine Sandbox für mich, um das Saltstack-Rezept zu erstellen.

Ich habe viele Ansätze ausprobiert, wenn man bedenkt, dass ich mich um das DNS gekümmert habe.

• Verwenden Sie selbstsignierte Zertifikate
• Verwenden Sie einige vorhandene Zertifikate, die mit letsencrypt erstellt wurden, auf einem VPS by TTN-Stack.
• habe alle insecure Konfigurationen nacheinander ausprobiert

Für mich ist es kein Problem von root-ca , ich weiß nicht, was es ist. Sollen wir dafür ein weiteres Thema aufmachen?

Eine Frage jedoch: Ist es Ihres Wissens nach möglich, es ohne TLS zu konfigurieren, nur für Entwicklungszwecke innerhalb einer Vagrant-Box? Wenn ja, würdest du mir bitte ein paar Hinweise geben?

Ich kann bestätigen, dass es auf meinem VPS gut mit letsencrypt funktioniert, was wir natürlich in der Produktion haben werden.

Danke.

Hinzufügen c/shared , da es möglicherweise keine Konfigurationssache ist

Hallo, sorry für die späte Antwort. Ich kann überprüfen, dass curl nur mit dem Parameter --cacert funktioniert, da das ca.pem-Zertifikat nicht in den tusted-Root-Zertifikaten installiert ist:

/ $ whoami
thethings
/ $ curl https://lora01.ntslab.loc
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
/ $ curl --cacert /var/run/secrets/ca.pem https://lora01.ntslab.loc
/ $ 

Bitte überprüfen Sie, ob der OAuth-Client die TLS-Konfiguration respektiert

Wenn Sie nginx vor dem Stack verwenden, muss nginx alle SSL/TLS verarbeiten.

dies sind die configs für nginx:

nginx.conf

stream {
    include stream_conf.d/*.conf;
}

stream_conf.d/mqtt.conf

log_format mqtt '$remote_addr [$time_local] $protocol $status $bytes_received '
                '$bytes_sent $upstream_addr';

upstream ttn1 {
    server stack-ip:1881;
    zone tcp_mem 64k;
}
upstream ttn2 {
    server stack-ip:1882;
    zone tcp_mem 64k;
}
upstream ttn3 {
    server stack-ip:1883;
    zone tcp_mem 64k;
}

server {
    listen 8881 ssl; # MQTT secure port
    preread_buffer_size 1k;

    ssl_certificate /etc/letsencrypt/live/FQDN/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/FQDN/privkey.pem; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
    ssl_ciphers         HIGH:!aNULL:!MD5;
    ssl_session_cache   shared:SSL:128m; # 128MB ~= 500k sessions
    ssl_session_tickets on;
    ssl_session_timeout 8h;

    proxy_pass ttn1;
    proxy_connect_timeout 1s;
}

server {
    listen 8882 ssl; # MQTT secure port
    preread_buffer_size 1k;

    ssl_certificate /etc/letsencrypt/live/FQDN/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/FQDN/privkey.pem; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
    ssl_ciphers         HIGH:!aNULL:!MD5;
    ssl_session_cache   shared:SSL:128m; # 128MB ~= 500k sessions
    ssl_session_tickets on;
    ssl_session_timeout 8h;

    proxy_pass ttn2;
    proxy_connect_timeout 1s;


server {
    listen 8883 ssl; # MQTT secure port
    preread_buffer_size 1k;

    ssl_certificate /etc/letsencrypt/live/FQDN/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/FQDN/privkey.pem; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
    ssl_ciphers         HIGH:!aNULL:!MD5;
    ssl_session_cache   shared:SSL:128m; # 128MB ~= 500k sessions
    ssl_session_tickets on;
    ssl_session_timeout 8h;

    proxy_pass ttn3;
    proxy_connect_timeout 1s;
}

server {
    listen 1881; # MQTT secure port
    preread_buffer_size 1k;

    proxy_pass ttn1;
    proxy_connect_timeout 1s;
}

server {
    listen 1882; # MQTT secure port
    preread_buffer_size 1k;

    proxy_pass ttn2;
    proxy_connect_timeout 1s;
}

server {
    listen 1883; # MQTT secure port
    preread_buffer_size 1k;

    proxy_pass ttn3;
    proxy_connect_timeout 1s;
}

Sie benötigen dies in Ihrer Site-Konfiguration für alle Ports (PORT=1884, 1885, 1887):

server {
        server_name FQDN;

        location / {
                proxy_pass      http://stack-ip:PORT;
                proxy_set_header Host $http_host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-Host $server_name;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "Upgrade";
                proxy_buffering off;
        }

       listen [::]:PORT ipv6only=on; # managed by Certbot
       listen PORT; # managed by Certbot
}

und dies für Ports (PORT/PORTSSL=1885/443, 1884/8884, 1887/8887):

server {

        server_name FQDN;

        location / {
                proxy_pass      http://stack-ip:PORT;
                proxy_set_header Host $http_host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-Host $server_name;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "Upgrade";
                proxy_buffering off;
        }

        listen [::]:PORTSSL ssl ipv6only=on; # managed by Certbot
        listen PORTSSL ssl; # managed by Certbot
        ssl_certificate /etc/letsencrypt/live/FQDN/fullchain.pem; # managed by Certbot
        ssl_certificate_key /etc/letsencrypt/live/FQDN/privkey.pem; # managed by Certbot
        include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
        ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

Wie Sie sehen können, verwende ich Lets Encrypt.

Vielen Dank @wasn-eu!

Dies ist auch für #1760 nützlich.

Hallo alle,

Ich habe ein ähnliches Problem bei der Installation von TTN 3.7 auf Ubuntu.

Ich habe die Anleitung von fox27374 (https://github.com/fox27374/lora-stack) befolgt, habe aber immer noch das Problem.
Meine Installation ist auf VM und Ubuntu. Ich verwende ein selbstsigniertes Zertifikat für die lokale Entwicklung.

Ich stecke immer noch mit diesem Fehler fest. „Token-Austausch verweigert“
Vielen Dank im Voraus,

Hallo @ramampiandra ,

wie ich im Slack-Chat geschrieben habe, damit das Ganze funktioniert, braucht man folgendes:

• Ein Zertifikat für den TLS-Verkehr: cert.pem
• Der zugehörige private Schlüssel: key.pem
• Das CA-Zertifikat, das cert.pem ausgestellt hat: ca.pem

Bitte stellen Sie sicher, dass die Zertifikate korrekt sind:

cert.pem

openssl x509 -in cert.pem -text -noout | grep -A 1 Identifier
            X509v3 Subject Key Identifier:
                26:78:63:90:E7:1C:09:B7:DA:B3:7D:81:F0:DE:47:6B:AE:16:58:79
            X509v3 Authority Key Identifier:
                keyid:86:32:F5:56:44:21:EC:E3:2A:D9:5F:6E:87:82:7A:67:C2:F1:77:E8

ca.pem

openssl x509 -in ca.pem -text -noout | grep -A 1 Identifier
            X509v3 Subject Key Identifier:
                86:32:F5:56:44:21:EC:E3:2A:D9:5F:6E:87:82:7A:67:C2:F1:77:E8

Stellen Sie sicher, dass der Authority Key Identifier in cert.pem mit dem Subject Key Identifier in ca.pem identisch ist.

Nachdem der Stack gestartet wurde und alle Docker-Container hochgefahren sind, führen Sie den folgenden Befehl aus (passen Sie „ttn-server_stack_1“ an den Namen Ihres TTN-Containers an):
docker exec -it --user root ttn-server_stack_1 /usr/sbin/update-ca-certificates
Dadurch wird das ca.pem-Zertifikat im Container installiert und zu den vertrauenswürdigen Zertifikaten hinzugefügt.

Melden Sie sich danach direkt bei Ihrem Container an und testen Sie, ob das Zertifikat funktioniert:

docker-compose exec stack "/bin/ash"
curl https://YOURSERVER.YOUR.DOMAIN

Sie sollten KEIN Ergebnis oder Fehler sehen – das bedeutet, dass Ihr Zertifikat vertrauenswürdig ist.

Ich hoffe das hilft,
Prost

Nachdem ich dies im Detail untersucht hatte, konnte ich reproduzieren und bestätigen, dass es tatsächlich ein Problem mit der TLS-Konfiguration (und insbesondere den Stammzertifikaten) gibt, die von unserem OAuth-Fluss nicht respektiert werden, wodurch der Token-Austausch fehlschlägt.

Ich arbeite derzeit an einer PR, um dies zu beheben, die später heute landen sollte.

@kschiffer super , danke, dass du dir das angesehen hast. Halte mich einfach auf dem Laufenden, damit ich dir beim Testen helfen kann.

Hallo! Gibt es eine andere Problemumgehung, um dies vorübergehend zu beheben?

@dgraposo dies sollte in 3.8.1 behoben werden

Ich werde dieses Thema vorerst schließen, da sich der Fokus auf das Problem „Token-Austausch verweigert“ verlagert hat, das über #2511 angesprochen wurde und das über #2521 weiter verfolgt werden kann. Ich vermute, dass dies der Hauptgrund war, einen Abschnitt zur Fehlerbehebung hinzuzufügen.

Dieses Thema ist nicht mehr sehr nützlich, um seinen ursprünglichen Zweck zu diskutieren. Ich schlage vor, mit angemessenem Umfang wieder zu öffnen, wenn wir einen Abschnitt zur Fehlerbehebung für notwendig halten.