Lorawan-stack: Добавьте раздел об устранении неполадок в наше руководство по началу работы.

Привет, однозначно лайк. Следуя руководству, я столкнулся с парой проблем и открытыми вопросами. На данный момент я застрял с этой ошибкой. Может быть, вы также можете указать на это в документации?

@fox27374 fox27374 , можете ли вы открыть инструменты разработчика браузера и вставить значение window.PAGE_DATA ? Вы можете ввести это в консоли браузера, увидев эту ошибку.

Кроме того, выполнили ли вы все шаги в разделе «Начало работы», т. е. для создания консольного клиента OAuth?

Привет,
вот window.PAGE_DATA, а также команда, которую я использую для создания клиента oauth. Следует упомянуть один важный момент: я использую свои собственные сертификаты (подписанные ЦС лаборатории).

ДАННЫЕ
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 настраивается в файле hosts, поэтому разрешение имен должно работать.

URL-адрес токена:
URL-адрес токена: ' https://lora01.ntslab.loc/oauth/token '

Если вам нужна дополнительная информация, вы можете напрямую просмотреть файлы docker-compose.yml и ttn-lw-stack.yml . Я также использую стартовый скрипт для инициализации ( start.sh ).

Заранее спасибо,
Даниэль

Привет @fox27374

Да, я запускаю стек TTN через Docker на сервере Linux. lora01.ntslab.loc настраивается в файле hosts, поэтому разрешение имен должно работать.

Вы имеете в виду файл /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
Спасибо Вам за информацию. Я удалил запись hosts и установил IP/имя хоста непосредственно на DNS-сервере. Кроме того, я добавил запись «extra_hosts» в файл docker-compose.yml.
Боюсь, ошибка все еще существует.

Я запустил ash shell в контейнере и проверил разрешение DNS:

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

Так что это кажется хорошим. После отказа обмена токенов сообщения об ошибке, есть ли дальнейшая отладка, которую мы можем включить для обмена токенами oauth? Извините, что отвлекаю вас этим....
Спасибо

Кстати, похоже у кого-то такая же проблема

Привет @neoaggelos
Спасибо Вам за информацию. Я удалил запись hosts и установил IP/имя хоста непосредственно на DNS-сервере. Кроме того, я добавил запись «extra_hosts» в файл docker-compose.yml.

Хм, при правильной настройке DNS вам не нужно устанавливать extra_hosts .

Боюсь, ошибка все еще существует.

Я запустил ash shell в контейнере и проверил разрешение DNS:

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

Я провожу все тесты в браузере в приватном режиме, поэтому файлы cookie не используются. Ключ и сертификат доступны для чтения пользователю "thethings":

/ $ whoami
thethings

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

Я постараюсь изменить настройки на localhost и держать вас в курсе.

извините, я не упомянул, что 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-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

добавив его в раздел томов файла 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 ), имя файла, с вашим CA. См. https://thethingsstack.io/v3.7.0/reference/configuration/the-things-stack/

@johanstokking : я добавил следующее в 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

Таким образом, файлы сертификатов будут доступны в контейнере в /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 в доверенные корневые сертификаты, все работает.
Спасибо, Даниэль

копия @adriansmares

Привет, есть новости? Я попытался отладить доступ к доверенным корневым сертификатам с помощью strace, но безуспешно.

@fox27374 fox27374 можете ли вы убедиться, что это работает?

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

@adriansmares похоже, что нам нужны две вещи;

1. Сообщите об основной причине ошибки, возможно, как атрибут причины, так как это ошибка net или что-то еще stdlib
2. Убедитесь, что мы соблюдаем tls.root-ca в клиенте OAuth.

Привет, ребята,

Я получаю ту же ошибку 403, запуская стек TTN v3 с докером в ящике Vagrant (с Virtual Box). - Просто песочница для меня, чтобы создать рецепт Saltstack.

Я пробовал много подходов, учитывая, что я позаботился о DNS.

• использовать самоподписанные сертификаты
• повторно использовать некоторые существующие сертификаты, созданные с помощью letsencrypt в стеке VPS by 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
• Сертификат ЦС, выдавший cert.pem: ca.pem

Пожалуйста, убедитесь, что сертификаты указаны правильно:

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

Убедитесь, что идентификатор ключа центра сертификации в файле 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, что приводит к сбою обмена токенами.

В настоящее время я работаю над PR, чтобы исправить это, которое должно появиться позже сегодня.

@kschiffer круто , спасибо, что посмотрели это. Просто держите меня в курсе, чтобы я мог помочь вам с тестированием.

Привет! Есть другой обходной путь, чтобы временно исправить это?

@dgraposo это должно быть исправлено в 3.8.1

На данный момент я закрою этот вопрос, поскольку основное внимание было перенесено на проблему «отказ в обмене токенами», которая была решена в # 2511 и за которой можно будет проследить в # 2521. Я подозреваю, что это была главная причина добавить раздел устранения неполадок.

Этот вопрос уже не очень полезен для обсуждения его первоначальной цели. Я предлагаю повторно открыть с надлежащим объемом, если мы считаем, что раздел устранения неполадок по-прежнему необходим.