Lorawan-stack: Tambahkan bagian pemecahan masalah di panduan Memulai kami

Hai, pasti diacungi jempol untuk ini. Saya mengalami beberapa masalah dan pertanyaan terbuka saat mengikuti panduan ini. Saat ini saya terjebak dengan kesalahan ini. Mungkin Anda juga bisa menunjuk yang ini di dokumentasi?

@fox27374 dapatkah Anda membuka alat pengembang browser dan menempelkan nilai window.PAGE_DATA ? Anda dapat memasukkannya di konsol browser saat melihat kesalahan ini.

Juga, apakah Anda mengikuti semua langkah di Memulai, yaitu untuk membuat klien OAuth Konsol?

Hai,
di sini adalah window.PAGE_DATA serta perintah yang saya gunakan untuk membuat klien oauth. Satu hal penting untuk disebutkan adalah, bahwa saya menggunakan sertifikat saya sendiri (ditandatangani oleh lab CA).

DATA
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 }] } };

MEMERINTAH
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"

Terima kasih banyak!
Bersulang,
Daniel

@ fox27374 terima kasih atas informasi tambahannya.

Apa URL OAuth yang dikonfigurasi, yaitu URL /token yang Anda konfigurasikan? Anda dapat menyunting konten sensitif.

Bisakah Anda mengonfirmasi bahwa lora01.ntslab.loc diselesaikan di wadah Docker, dengan asumsi Anda menjalankan The Things Stack melalui Docker?

Hai,

Terima kasih atas jawabannya dan telah membantu saya di sini. Kontennya belum masuk akal, ini adalah pengaturan lab untuk saat ini sebagai ujian untuk lingkungan produksi di masa depan. Saya ingin menyingkirkan server Actility :)

Ya, saya menjalankan tumpukan TTN melalui Docker di server Linux. lora01.ntslab.loc dikonfigurasi dalam file host, jadi resolusi nama harus bekerja.

URL /token adalah:
token-url: ' https://lora01.ntslab.loc/oauth/token '

Jika Anda memerlukan informasi lebih lanjut, Anda dapat langsung melihat file docker- compose.yml dan ttn-lw-stack.yml . Saya juga menggunakan skrip start untuk melakukan inisialisasi ( start.sh ).

Terima kasih sebelumnya,
Daniel

Hai @fox27374

Ya, saya menjalankan tumpukan TTN melalui Docker di server Linux. lora01.ntslab.loc dikonfigurasi dalam file host, jadi resolusi nama harus bekerja.

Apakah maksud Anda file /etc/hosts dari mesin Anda? Ini tidak memengaruhi wadah Docker tempat tumpukan berjalan, yang bisa menjadi sumber masalah yang Anda lihat.

Anda dapat memeriksanya dengan perintah berikut:

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

Anda akan melihat sesuatu di sepanjang baris nc: bad address 'lora01.ntslab.loc' .

Bisakah Anda mencoba menambahkan bagian extra_hosts di docker-compose.yaml Anda, seperti:

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

Dan mulai ulang dengan docker-compose up -d

Resolusi nama host kemudian akan berfungsi. (Tetapi, jika YOUR_IP_ADDRESS adalah sesuatu seperti 127.0.0.1 , maka Anda mungkin masih mendapatkan beberapa kesalahan)

Hai @neoaggelos
Terima kasih atas infonya. Saya menghapus entri host dan mengatur IP/nama host langsung di server DNS. Selain itu saya menambahkan entri "extra_hosts" di docker-compose.yml.
Saya khawatir, kesalahan masih ada.

Saya memulai ash Shell dalam wadah dan dan memeriksa resolusi dns:

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

Jadi ini sepertinya bagus. Mengikuti pesan kesalahan pertukaran token yang ditolak , apakah ada debugging lebih lanjut yang dapat kami aktifkan untuk pertukaran token oauth? Maaf membuatmu sibuk dengan ini....
Terima kasih

Ngomong-ngomong, sepertinya orang lain juga memiliki masalah yang sama

Hai @neoaggelos
Terima kasih atas infonya. Saya menghapus entri host dan mengatur IP/nama host langsung di server DNS. Selain itu saya menambahkan entri "extra_hosts" di docker-compose.yml.

Hmm, dengan konfigurasi DNS yang tepat, Anda tidak perlu mengatur extra_hosts .

Saya khawatir, kesalahan masih ada.

Saya memulai ash Shell dalam wadah dan dan memeriksa resolusi dns:

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

172.24.89.120 adalah salah satu dari jaringan yang dibuat oleh Docker, yang juga bisa menjadi kemungkinan alasan kegagalan.

Jadi ini sepertinya bagus. Mengikuti pesan kesalahan pertukaran token yang ditolak , apakah ada debugging lebih lanjut yang dapat kami aktifkan untuk pertukaran token oauth? Maaf membuatmu sibuk dengan ini....
Terima kasih

Coba bersihkan cookie Anda, dan coba juga dari sesi browser yang bersih. Juga, pastikan sertifikat dibaca dengan benar dari tumpukan cat /var/run/secrets/cert.pem dan cat /var/run/secrets/key.pem dari shell di dalam wadah harus cukup untuk memeriksa yang itu.

Menyimpang dari topik; Sudahkah Anda mencoba mengatur tumpukan di localhost? Apakah kamu berhasil?

Hai,

maaf, saya tidak menyebutkan bahwa 172.24.89.120 adalah alamat IP dari server itu sendiri di lab. Alamat buruh pelabuhan adalah 172.9.0.X

Saya melakukan semua tes dengan browser dalam mode privat, jadi tidak ada cookie yang terlibat. Kunci dan sertifikat dapat dibaca oleh pengguna "thethings":

/ $ whoami
thethings

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

Saya akan mencoba mengubah pengaturan ke localhost dan membuat Anda tetap diposting.

maaf, saya tidak menyebutkan bahwa 172.24.89.120 adalah alamat IP dari server itu sendiri di lab. Alamat buruh pelabuhan adalah 172.9.0.X

Tapi bisakah Anda curl https://lora01.ntslab.loc dari dalam wadah? Jika tidak, apa kesalahan yang dilaporkan?

Hai,

sepertinya kita mendapatkannya. Petunjuk ikal itu bagus. Ini menunjukkan, bahwa ca.pem tidak ada di toko sertifikat tepercaya:

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

Jadi saya menyalin sertifikat ca.pem ke /usr/local/share/ca-certificates/

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

dengan menambahkannya ke bagian volume dari file docker-compose.yml:

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

Sekarang saya bisa masuk ke konsol dan semua sertifikat dipercaya. Luar biasa!

Apakah ini cara terbaik/yang dimaksudkan untuk menambahkan sertifikat root tepercaya ke wadah TTN?

Maaf karena euforia terlalu dini. Sepertinya token auth masih ada di DB, itu sebabnya semuanya berfungsi. Setelah wadah dimulai, saya perlu menjalankan perintah ini untuk menambahkan sertifikat ca.pem ke toko tepercaya:

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

Kemudian klien oauth bisa mendapatkan token dan menyimpannya di DB. Saya dapat bekerja untuk saat ini, tetapi saya kira ini seharusnya bukan solusi terakhir. Ada ide?
Terima kasih banyak!

@ fox27374 bagus bahwa Anda menemukan penyebabnya. Itu selalu merupakan awal yang baik untuk menemukan solusi yang bersih.

Tumpukan menghormati TTN_LW_TLS_ROOT_CA (atau tls.root-ca ), nama file, dengan CA Anda. Lihat https://thethingsstack.io/v3.7.0/reference/configuration/the-things-stack/

@johanstokking : Saya menambahkan berikut ke docker-compose.yml

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

Dengan cara ini, file sertifikat tersedia dalam wadah di /run/secrets dan /var/run/secrets . Saya memeriksa ini langsung di wadah.

saya tambahkan
TTN_LW_TLS_ROOT_CA: "/var/run/secrets/ca.pem"
ke file docker-compose.yml . Kesalahan itu masih ada. Saya juga mencoba menambahkan ini ke ttn-lw-stack.yml :

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

Hal yang sama di sini. Saya masih mendapatkan kesalahan. Mungkinkah, beberapa aplikasi, terutama klien oauth menggunakan sertifikat root tepercaya internal OS? Karena segera setelah saya menambahkan cap.pem ke root certificate tepercaya, semuanya berfungsi.
Terima kasih, Daniel

cc @adriansmares

Hai, ada kabar di sini? Saya mencoba men-debug akses ke root certificate tepercaya dengan strace tetapi tidak berhasil.

@ fox27374 dapatkah Anda memverifikasi bahwa ini berfungsi?

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

@adriansmares sepertinya kita membutuhkan dua hal;

1. Laporkan penyebab kesalahan yang mendasarinya, berpotensi sebagai atribut alasan, karena ini adalah kesalahan net atau sesuatu yang lain stdlib
2. Verifikasi bahwa kami menghormati tls.root-ca di klien OAuth

Hai kawan,

Saya mendapatkan kesalahan 403 yang sama, menjalankan TTN stack v3 dengan buruh pelabuhan di dalam kotak Vagrant (dengan Kotak Virtual). - Hanya kotak pasir bagi saya untuk membuat resep Saltstack.

Saya mencoba banyak pendekatan, mengingat saya mengurus DNS.

• gunakan sertifikat yang ditandatangani sendiri
• menggunakan kembali beberapa sertifikat yang ada yang dibuat dengan letsencrypt pada tumpukan VPS oleh TTN.
• mencoba semua konfigurasi insecure satu per satu

Bagi saya itu bukan masalah root-ca , saya tidak tahu apa itu. Haruskah kita membuka masalah lain untuk ini?

Satu pertanyaan: Dari pengetahuan Anda, apakah mungkin untuk mengonfigurasinya tanpa TLS , hanya untuk tujuan dev di dalam kotak Vagrant? Jika demikian, tolong beri saya beberapa petunjuk?

Saya dapat mengonfirmasi bahwa pada VPS saya itu berfungsi dengan baik dengan letsencrypt , yang tentu saja akan kami produksi.

Terima kasih.

Menambahkan c/shared karena itu mungkin bukan hal konfigurasi

Hai, maaf atas keterlambatan balasan. Saya dapat memverifikasi bahwa curl hanya berfungsi dengan parameter --cacert karena sertifikat ca.pem tidak diinstal di sertifikat root tusted:

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

Harap periksa apakah klien OAuth mematuhi konfigurasi TLS

jika Anda menggunakan nginx di depan tumpukan, nginx harus menangani semua ssl/tls.

ini adalah konfigurasi untuk 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;
}

anda memerlukan ini di konfigurasi situs Anda untuk semua port (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
}

dan ini untuk port (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
}

seperti yang Anda lihat saya menggunakan memungkinkan mengenkripsi.

Terima kasih banyak @wasn-eu!

Ini juga berguna untuk #1760.

Halo semua,

Saya memiliki masalah serupa ketika menginstal TTN 3.7 di ubuntu.

Saya mengikuti panduan fox27374 ( https://github.com/fox27374/lora-stack ) tetapi masih memiliki masalah.
Instalasi saya ada di VM dan Ubuntu. Saya menggunakan sertifikat yang ditandatangani sendiri untuk pengembangan lokal.

Saya masih terjebak dengan kesalahan ini. "Penukaran Token Ditolak"
Terima kasih sebelumnya,

Hai @ramampiandra ,

seperti yang saya tulis di obrolan Slack, agar semuanya berfungsi, Anda memerlukan yang berikut:

• Sertifikat untuk lalu lintas TLS: cert.pem
• Kunci pribadi yang sesuai: key.pem
• Sertifikat CA yang menerbitkan cert.pem: ca.pem

Harap pastikan bahwa sertifikat sudah benar:

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

cap.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

Pastikan Authority Key Identification di cert.pem sama dengan Subject Key Identification di cap.pem.

Setelah tumpukan dimulai dan semua wadah buruh pelabuhan aktif, jalankan perintah berikut (sesuaikan "ttn-server_stack_1" dengan nama wadah TTN Anda):
docker exec -it --user root ttn-server_stack_1 /usr/sbin/update-ca-certificates
Ini akan menginstal sertifikat ca.pem di dalam wadah dan menambahkannya ke sertifikat tepercaya.

Setelah itu, langsung masuk ke wadah Anda dan uji apakah sertifikat berfungsi:

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

Anda TIDAK akan melihat hasil atau kesalahan apa pun - ini berarti sertifikat Anda tepercaya.

Semoga membantu,
Bersulang

Jadi setelah melihat ini secara mendetail, saya dapat mereproduksi dan dapat mengonfirmasi bahwa memang ada masalah dengan konfigurasi TLS (dan khususnya sertifikat root) yang tidak dipatuhi oleh aliran OAuth kami, yang menyebabkan pertukaran token gagal.

Saat ini saya sedang mengerjakan PR untuk memperbaiki ini yang seharusnya mendarat hari ini.

@kschiffer luar biasa, terima kasih telah melihat ini. Biarkan saya tetap diposting sehingga saya dapat membantu Anda dengan pengujian.

Hai! Ada solusi lain, untuk memperbaikinya sementara?

@dgraposo ini harus diperbaiki di 3.8.1

Saya akan menutup masalah ini untuk saat ini, karena fokus beralih ke masalah "penukaran token ditolak", yang telah ditangani melalui #2511 dan yang dapat diikuti lebih lanjut melalui #2521. Saya menduga ini adalah alasan terbesar untuk menambahkan bagian pemecahan masalah.

Masalah ini tidak terlalu berguna lagi untuk membahas tujuan awalnya. Saya sarankan membuka kembali dengan cakupan yang tepat jika kami menganggap bagian pemecahan masalah masih diperlukan.