Lorawan-stack: أضف قسم استكشاف الأخطاء وإصلاحها في دليل الشروع في العمل

مرحبا ، بالتأكيد ممتاز لهذا. واجهت مشكلتين وفتحت أسئلة أثناء اتباع الدليل. أنا عالق في الوقت الحالي مع هذا الخطأ. ربما يمكنك أيضًا الإشارة إلى هذا في الوثائق؟

@ fox27374 هل يمكنك فتح أدوات مطور المتصفح ولصق القيمة window.PAGE_DATA ؟ يمكنك إدخال ذلك في وحدة تحكم المتصفح أثناء رؤية هذا الخطأ.

أيضًا ، هل اتبعت جميع الخطوات في "البدء" ، أي لإنشاء عميل OAuth لوحدة التحكم؟

أهلا،
ها هي النافذة PAGE_DATA بالإضافة إلى الأمر الذي أستخدمه لإنشاء عميل oauth. من النقاط المهمة التي يجب ذكرها ، أنني أستخدم شهاداتي الخاصة (الموقعة من مختبر CA).

بيانات
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 }] } };

أمر
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"

شكرا جزيلا!
هتافات،
دانيال

@ fox27374 شكرا على المعلومات الإضافية.

ما هو عنوان URL لـ OAuth الذي تمت تهيئته ، أي عنوان URL /token الذي قمت بتكوينه؟ يمكنك تنقيح المحتوى الحساس.

هل يمكنك تأكيد أن lora01.ntslab.loc يتم حله في حاوية Docker ، بافتراض أنك تقوم بتشغيل The Things Stack عبر Docker؟

أهلا،

شكرا لك على الرد ومساعدتي هنا. المحتوى ليس معقولاً بعد ، إنه إعداد معمل في الوقت الحالي كاختبار لبيئة الإنتاج المستقبلية. اريد التخلص من خادم Actility :)

نعم ، أقوم بتشغيل مكدس TTN عبر Docker على خادم Linux. تم تكوين lora01.ntslab.loc في ملف المضيفين ، لذا يجب أن يعمل تحليل الاسم.

/ URL هو:
عنوان url المميز: " https: //lora01.ntslab.loc/oauth/token "

إذا كنت بحاجة إلى مزيد من المعلومات ، يمكنك إلقاء نظرة مباشرة على docker -compose.yml وملفات ttn-lw-stack.yml . كما أنني أستخدم برنامج نصي لبدء التهيئة ( start.sh ).

شكرا لكم مقدما،
دانيال

مرحبا @ fox27374

نعم ، أقوم بتشغيل مكدس TTN عبر Docker على خادم Linux. تم تكوين lora01.ntslab.loc في ملف المضيفين ، لذا يجب أن يعمل تحليل الاسم.

هل تقصد ملف /etc/hosts الخاص بجهازك؟ لا يؤثر هذا على حاوية Docker حيث يتم تشغيل المكدس ، والذي قد يكون مصدر المشكلة التي تراها.

يمكنك التحقق من ذلك باستخدام الأمر التالي:

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

يجب أن ترى شيئًا على غرار nc: bad address 'lora01.ntslab.loc' .

هل يمكنك محاولة إضافة قسم extra_hosts في docker-compose.yaml ، مثل:

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

وإعادة التشغيل بـ docker-compose up -d

يجب أن يعمل تحليل اسم المضيف بعد ذلك. (ولكن ، إذا كان YOUR_IP_ADDRESS شيئًا مثل 127.0.0.1 ، فربما لا يزال بإمكانك الحصول على بعض الأخطاء)

مرحباneoaggelos
شكرا لك على المعلومات. قمت بإزالة إدخال المضيفين وقمت بتعيين IP / اسم المضيف مباشرة على خادم DNS. بالإضافة إلى ذلك ، أضفت الإدخال "extra_hosts" في docker-compose.yml.
أخشى أن الخطأ لا يزال موجودا.

لقد بدأت قذيفة الرماد في الحاوية وتحققت من دقة نظام أسماء النطاقات:

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

لذلك يبدو هذا جيدًا. بعد رفض تبادل الرمز المميز لرسالة الخطأ ، هل هناك أي تصحيح أخطاء إضافي يمكننا تمكينه لتبادل رمز oauth؟ آسف لإبقائك مشغولا بهذا ....
شكرا

بالمناسبة ، يبدو أن شخصًا آخر لديه نفس المشكلة أيضًا

مرحباneoaggelos
شكرا لك على المعلومات. قمت بإزالة إدخال المضيفين وقمت بتعيين IP / اسم المضيف مباشرة على خادم DNS. بالإضافة إلى ذلك ، أضفت الإدخال "extra_hosts" في docker-compose.yml.

حسنًا ، مع تكوين DNS المناسب ، لا يجب عليك تعيين extra_hosts .

أخشى أن الخطأ لا يزال موجودا.

لقد بدأت قذيفة الرماد في الحاوية وتحققت من دقة نظام أسماء النطاقات:

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

172.24.89.120 هو المبلغ من الشبكة التي أنشأها Docker ، والذي قد يكون أيضًا سببًا محتملاً للفشل.

لذلك يبدو هذا جيدًا. بعد رفض تبادل الرمز المميز لرسالة الخطأ ، هل هناك أي تصحيح أخطاء إضافي يمكننا تمكينه لتبادل رمز oauth؟ آسف لإبقائك مشغولا بهذا ....
شكرا

حاول مسح ملفات تعريف الارتباط الخاصة بك ، والمحاولة من جلسة متصفح نظيفة أيضًا. تأكد أيضًا من قراءة الشهادات بشكل صحيح من المكدس cat /var/run/secrets/cert.pem و cat /var/run/secrets/key.pem من غلاف داخل الحاوية يجب أن يكون كافيًا للتحقق من ذلك.

خارج الموضوع؛ هل حاولت إعداد المكدس على مضيف محلي؟ هل نجحت؟

أهلا،

آسف ، لم أذكر أن 172.24.89.120 هو عنوان IP للخادم نفسه في المعمل. عناوين عامل الإرساء هي 172.9.0.X

أقوم بجميع الاختبارات باستخدام متصفح في الوضع الخاص ، لذلك لا توجد ملفات تعريف ارتباط. المفتاح والشهادة يمكن قراءتهما بواسطة مستخدم "الأشياء":

/ $ whoami
thethings

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

سأحاول تغيير الإعداد إلى المضيف المحلي وإطلاعك على آخر المستجدات.

آسف ، لم أذكر أن 172.24.89.120 هو عنوان IP للخادم نفسه في المعمل. عناوين عامل الإرساء هي 172.9.0.X

ولكن هل يمكنك curl https://lora01.ntslab.loc من داخل الحاوية؟ إذا لم يكن كذلك ، ما هو الخطأ المبلغ عنه؟

أهلا،

يبدو أننا حصلنا عليه. كان تلميح الضفيرة جيدًا. أظهر هذا أن ca.pem لم يكن في مخزن الشهادات الموثوق به:

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

لذلك قمت بنسخ شهادة ca.pem إلى / usr / local / share / ca-الشهادات /

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

بإضافته إلى قسم المجلدات في ملف 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"

أنا الآن قادر على تسجيل الدخول إلى وحدة التحكم ويتم الوثوق بجميع الشهادات. مدهش!

هل هذه هي الطريقة الأفضل / المقصودة لإضافة شهادة جذر موثوق بها إلى حاوية TTN؟

آسف لكوني مبتهجا في وقت مبكر جدا. يبدو أن رمز المصادقة كان لا يزال في قاعدة البيانات ، ولهذا السبب نجح كل شيء. بعد بدء الحاوية ، كنت بحاجة إلى تشغيل هذا الأمر لإضافة شهادة ca.pem إلى المتجر الموثوق به:

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

ثم يكون عميل oauth قادرًا على الحصول على رمز مميز وتخزينه في قاعدة البيانات. يمكنني العمل الآن ، لكن لا ينبغي أن يكون هذا هو الحل النهائي على ما أعتقد. أيه أفكار؟
شكرا جزيلا!

@ fox27374 العظيم أنك وجدت السبب. هذه دائمًا بداية جيدة للتوصل إلى حل نظيف.

المكدس يحترم TTN_LW_TLS_ROOT_CA (أو tls.root-ca ) ، اسم ملف ، مع المرجع المصدق الخاص بك. انظر https://thethingsstack.io/v3.7.0/reference/configuration/the-things-stack/

johanstokking : لقد أضفت التالي إلى عامل البناء 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

بهذه الطريقة ، تتوفر ملفات الشهادات في الحاوية في / run / secrets و / var / run / secrets . راجعت هذا الدليل في الحاوية.

أضفت
TTN_LW_TLS_ROOT_CA: "/var/run/secrets/ca.pem"
إلى ملف docker-compose.yml . الخطأ لا يزال هناك. حاولت أيضًا إضافة هذا إلى 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"

نفس الشيء هنا. مازلت اقع في الخطأ نفسه. هل يمكن أن تستخدم بعض التطبيقات ، وخاصة عميل oauth الشهادات الجذرية الموثوقة الداخلية لنظام التشغيل؟ لأنه بمجرد إضافة ca.pem إلى الشهادات الجذرية الموثوقة ، يعمل كل شيء.
شكرا دانيال

ccadriansmares

مرحبا اي اخبار هنا حاولت تصحيح الوصول إلى الشهادات الجذرية الموثوقة ذات الاتزان لكنني لم أنجح.

@ fox27374 هل يمكنك التحقق من أن هذا يعمل؟

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

adriansmares يبدو أننا بحاجة إلى شيئين ؛

1. الإبلاغ عن سبب الخطأ الأساسي ، ربما باعتباره سمة السبب ، لأنه خطأ net أو شيء آخر stdlib
2. تحقق من أننا نحترم tls.root-ca في عميل OAuth

اهلا ياجماعة،

أحصل على نفس الخطأ 403 ، تشغيل TTN stack v3 مع عامل إرساء داخل صندوق Vagrant (مع Virtual Box). - مجرد رمل بالنسبة لي لإنشاء وصفة سالتستاك.

لقد جربت العديد من الأساليب ، مع الأخذ في الاعتبار أنني اهتمت بـ DNS.

• استخدام الشهادات الموقعة ذاتيا
• إعادة استخدام بعض الشهادات الموجودة التي تم إنشاؤها باستخدام letsencrypt على VPS بواسطة مكدس TTN.
• جرب كل التكوينات insecure واحدًا تلو الآخر

بالنسبة لي ليست مشكلة root-ca ، لا أعرف ما هي. هل يجب أن نفتح قضية أخرى لهذا؟

سؤال واحد: من معرفتك ، هل من الممكن تهيئته بدون TLS ، فقط لأغراض التطوير داخل مربع Vagrant؟ إذا كان الأمر كذلك ، من فضلك أعطني بعض المؤشرات؟

أستطيع أن أؤكد أنه على VPS الخاص بي يعمل بشكل جيد مع letsencrypt ، وهو بالطبع ما سنقوم به في الإنتاج.

شكرا.

إضافة c/shared لأنه قد لا يكون شيئًا تكوينًا

مرحبا، آسف على التأخر في الرد. يمكنني التحقق من أن curl يعمل فقط مع المعلمة --cacert لأن شهادة ca.pem غير مثبتة في الشهادات الجذرية الموثوقة:

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

الرجاء التحقق مما إذا كان عميل OAuth يحترم تهيئة TLS

إذا كنت تستخدم nginx أمام المكدس ، يجب أن يتعامل nginx مع كل ssl / tls.

هذه هي تكوينات 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;
}

تحتاج إلى هذا في تهيئة موقعك لجميع المنافذ (المنفذ = 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
}

وهذا بالنسبة للمنافذ (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
}

كما ترون أنا أستخدم يتيح تشفير.

شكرا جزيلا @ wasn-eu!

هذا مفيد أيضًا لـ # 1760.

أهلا بكم،

لدي مشكلة مماثلة عند تثبيت TTN 3.7 على ubuntu.

لقد اتبعت دليل fox27374 (https://github.com/fox27374/lora-stack) ولكن ما زلت أواجه المشكلة.
التثبيت الخاص بي على VM و Ubuntu. أستخدم شهادة موقعة ذاتيًا للتنمية المحلية.

ما زلت عالقا مع هذا الخطأ. "رمز صرف مرفوض"
شكرا لكم مقدما،

مرحبًا ramampiandra ،

كما كتبت في دردشة Slack ، لكي يعمل كل شيء ، فأنت بحاجة إلى ما يلي:

• شهادة لحركة مرور TLS: cert.pem
• المفتاح الخاص المقابل: key.pem
• شهادة المرجع المصدق (CA) التي أصدرت الشهادة

يرجى التأكد من صحة الشهادات:

شهادة

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

تأكد من أن معرف مفتاح المرجع في cert.pem هو نفسه معرف مفتاح الموضوع في ca.pem.

بعد بدء المكدس وتشغيل جميع حاويات عامل الإرساء ، قم بتشغيل الأمر التالي (قم بتكييف "ttn-server_stack_1" مع اسم حاوية TTN الخاصة بك):
docker exec -it --user root ttn-server_stack_1 /usr/sbin/update-ca-certificates
سيؤدي هذا إلى تثبيت شهادة ca.pem داخل الحاوية وإضافتها إلى الشهادات الموثوقة.

بعد ذلك ، قم بتسجيل الدخول مباشرة إلى الحاوية الخاصة بك واختبر ما إذا كانت الشهادة تعمل:

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

يجب ألا ترى أي نتيجة أو خطأ - وهذا يعني أن شهادتك موثوق بها.

آمل أن يساعد هذا،
هتافات

لذلك بعد النظر في هذا بالتفصيل ، تمكنت من إعادة الإنتاج والتأكد من وجود مشكلة بالفعل في تكوين TLS (وخاصة الشهادات الجذرية) التي لا يتم احترامها من خلال تدفق OAuth الخاص بنا ، مما تسبب في فشل تبادل الرمز المميز.

أنا أعمل حاليًا على علاقات عامة لإصلاح هذا الأمر الذي يجب أن يصل لاحقًا اليوم.

kschiffer رائع ، شكرًا لإلقاء نظرة على هذا. ما عليك سوى إعلامي حتى أتمكن من مساعدتك في الاختبار.

أهلا! هل هناك حل آخر لإصلاح هذا مؤقتًا؟

dgraposo يجب إصلاح هذا في 3.8.1

سأغلق هذه المشكلة في الوقت الحالي ، حيث انتقل التركيز إلى مشكلة "رفض التبادل المميز" ، والتي تمت معالجتها عبر # 2511 والتي يمكن متابعتها بشكل أكبر عبر # 2521. أظن أن هذا كان السبب الأكبر لإضافة قسم استكشاف الأخطاء وإصلاحها.

لم تعد هذه المسألة مفيدة للغاية بعد الآن لمناقشة الغرض الأولي منها. أقترح إعادة الفتح بالنطاق المناسب إذا رأينا أن قسم تحرّي الخلل وإصلاحه لا يزال ضروريًا.