Lorawan-stack: Adicione uma seção de solução de problemas em nosso guia de introdução

Olá, definitivamente um polegar para isso. Eu me deparei com alguns problemas e perguntas em aberto enquanto seguia o guia. No momento estou com esse erro. Talvez você também possa apontar para este na documentação?

@fox27374 você pode abrir as ferramentas de desenvolvedor do navegador e colar o window.PAGE_DATA ? Você pode inserir isso no console do navegador enquanto vê este erro.

Além disso, você seguiu todas as etapas do Guia de Introdução, ou seja, para criar o cliente OAuth do Console?

Oi,
aqui está o window.PAGE_DATA, bem como o comando que uso para criar o cliente oauth. Um ponto importante a mencionar é que eu uso meus próprios certificados (assinados pela CA do laboratório).

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

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

Muito obrigado!
Saúde,
Daniel

@fox27374 obrigado pelas informações adicionais.

Qual é a URL OAuth configurada, ou seja, a URL /token que você configurou? Você pode redigir conteúdo sensível.

Você pode confirmar que lora01.ntslab.loc resolve no contêiner do Docker, supondo que você execute o The Things Stack via Docker?

Oi,

Obrigado pela resposta e por me ajudar aqui. O conteúdo ainda não é sensato, é uma configuração de laboratório por enquanto como teste para um futuro ambiente de produção. Eu quero me livrar do servidor Actility :)

Sim, eu executo a pilha TTN via Docker em um servidor Linux. lora01.ntslab.loc está configurado no arquivo hosts, então a resolução de nomes deve funcionar.

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

Se precisar de mais informações, você pode dar uma olhada diretamente nos arquivos docker- compose.yml e ttn-lw-stack.yml . Eu também uso um script de início para fazer a inicialização ( start.sh ).

Agradeço antecipadamente,
Daniel

Olá @fox27374

Sim, eu executo a pilha TTN via Docker em um servidor Linux. lora01.ntslab.loc está configurado no arquivo hosts, então a resolução de nomes deve funcionar.

Você quer dizer o arquivo /etc/hosts da sua máquina? Isso não afeta o contêiner do Docker em que a pilha está sendo executada, que pode ser a origem do problema que você está vendo.

Você pode verificar isso com o seguinte comando:

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

Você deve ver algo nc: bad address 'lora01.ntslab.loc' .

Você pode tentar adicionar uma seção extra_hosts em seu docker-compose.yaml, assim:

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

E reinicie com docker-compose up -d

A resolução do nome do host deve funcionar. (Mas, se YOUR_IP_ADDRESS for algo como 127.0.0.1 , você ainda poderá receber alguns erros)

Olá @neoaggelos
obrigado pela informação. Eu removi a entrada de hosts e configurei o IP/hostname diretamente no servidor DNS. Além disso, adicionei a entrada "extra_hosts" no docker-compose.yml.
Estou com medo, o erro ainda existe.

Eu iniciei o shell de cinzas no contêiner e verifiquei a resolução do dns:

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

Então isso parece bom. Após a mensagem de erro troca de token recusada , há alguma depuração adicional que possamos habilitar para a troca de token oauth? Desculpe mantê-lo ocupado com isso ....
Obrigado

A propósito, parece que outra pessoa também tem o mesmo problema

Olá @neoaggelos
obrigado pela informação. Eu removi a entrada de hosts e configurei o IP/hostname diretamente no servidor DNS. Além disso, adicionei a entrada "extra_hosts" no docker-compose.yml.

Hmm, com a configuração de DNS adequada, você não deve definir extra_hosts .

Estou com medo, o erro ainda existe.

Eu iniciei o shell de cinzas no contêiner e verifiquei a resolução do dns:

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

O 172.24.89.120 é o da rede criada pelo Docker, o que também pode ser um possível motivo de falha.

Então isso parece bom. Após a mensagem de erro troca de token recusada , há alguma depuração adicional que possamos habilitar para a troca de token oauth? Desculpe mantê-lo ocupado com isso ....
Obrigado

Tente limpar seus cookies e tente também em uma sessão limpa do navegador. Além disso, certifique-se de que os certificados sejam lidos corretamente da pilha cat /var/run/secrets/cert.pem e cat /var/run/secrets/key.pem de um shell dentro do contêiner deve ser suficiente para verificar esse.

Fora do assunto; Você já tentou configurar a pilha no localhost? Você conseguiu?

Oi,

desculpe, eu não mencionei que o 172.24.89.120 é o endereço IP do próprio servidor no laboratório. Os endereços do docker são 172.9.0.X

Eu faço todos os testes com um navegador em modo privado, então não há cookies envolvidos. A chave e o certificado podem ser lidos com o usuário "thethings":

/ $ whoami
thethings

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

Vou tentar mudar a configuração para localhost e mantê-lo informado.

desculpe, eu não mencionei que o 172.24.89.120 é o endereço IP do próprio servidor no laboratório. Os endereços do docker são 172.9.0.X

Mas você pode curl https://lora01.ntslab.loc de dentro do contêiner? Se não, qual é o erro relatado?

Oi,

parece que conseguimos. A dica de cachos foi boa. Isso mostrou que o ca.pem não estava no armazenamento de certificados confiáveis:

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

Então eu copiei o certificado ca.pem para /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

adicionando-o à seção de volumes do arquivo 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"

Agora consigo fazer login no console e todos os certificados são confiáveis. Impressionante!

Essa é a maneira melhor/intencionada de adicionar um certificado raiz confiável ao contêiner TTN?

Desculpe por estar eufórico muito cedo. Parece que o token de autenticação ainda estava no banco de dados, é por isso que tudo funcionou. Após o início do contêiner, precisei executar este comando para adicionar o certificado ca.pem ao armazenamento confiável:

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

Em seguida, o cliente oauth pode obter um token e armazená-lo no banco de dados. Eu posso trabalhar por agora, mas esta não deve ser a solução final, eu acho. Alguma ideia?
Muito obrigado!

@ fox27374 ótimo que você encontrou a causa. Isso é sempre um bom começo para chegar a uma solução limpa.

A pilha respeita TTN_LW_TLS_ROOT_CA (ou tls.root-ca ), um nome de arquivo, com sua CA. Veja https://thethingsstack.io/v3.7.0/reference/configuration/the-things-stack/

@johanstokking : adicionei o seguinte ao 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

Dessa forma, os arquivos de certificado ficam disponíveis no contêiner em /run/secrets e /var/run/secrets . Eu verifiquei isso diretamente no contêiner.

Eu adicionei
TTN_LW_TLS_ROOT_CA: "/var/run/secrets/ca.pem"
para o arquivo docker-compose.yml . O erro ainda está lá. Eu também tentei adicionar isso ao 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"

Mesma coisa aqui. Eu ainda tenho o erro. Pode ser que alguns aplicativos, especialmente o cliente oauth, usem os certificados raiz confiáveis ​​internos do sistema operacional? Porque assim que adiciono o ca.pem aos certificados raiz confiáveis, tudo funciona.
Obrigado, Danilo

cc @adriansmares

Olá, alguma novidade aqui? Tentei depurar o acesso aos certificados raiz confiáveis ​​com strace, mas não obtive sucesso.

@ fox27374 você pode verificar se isso funciona?

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

@adriansmares parece que precisamos de duas coisas;

1. Relate a causa do erro subjacente, potencialmente como atributo de motivo, pois é um erro net ou outra coisa stdlib
2. Verifique se estamos respeitando tls.root-ca no cliente OAuth

Oi pessoal,

Estou recebendo o mesmo erro 403, executando a pilha TTN v3 com docker dentro de uma caixa Vagrant (com Virtual Box). - Apenas um sandbox para eu criar a receita do Saltstack.

Tentei muitas abordagens, considerando que cuidei do DNS.

• usar certificados autoassinados
• reutilize alguns certificados existentes criados com letsencrypt em um VPS por pilha TTN.
• tentei todas as configurações insecure uma por uma

Para mim não é um problema de root-ca , não sei o que é. Devemos abrir outra questão para isso?

Uma pergunta, porém: Pelo seu conhecimento, é possível configurá-lo sem TLS , apenas para fins de desenvolvimento dentro de uma caixa Vagrant? Se sim, poderia me dar algumas dicas?

Posso confirmar que no meu VPS funciona bem com letsencrypt , que é claro o que teremos em produção.

Obrigado.

Adicionando c/shared porque pode não ser uma coisa de configuração

Olá, desculpe a demora na resposta. Posso verificar se o curl funciona apenas com o parâmetro --cacert, pois o certificado ca.pem não está instalado nos certificados raiz 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
/ $ 

Verifique se o cliente OAuth respeita a configuração TLS

se você usar o nginx na frente da pilha, o nginx deve lidar com todos os ssl/tls.

estas são as configurações do 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;
}

você precisa disso na configuração do seu site para todas as portas (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
}

e isso para portas (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
}

como você pode ver, estou usando permite criptografar.

Muito obrigado @wasn-eu!

Isso também é útil para #1760.

Olá a todos,

Eu tenho um problema semelhante ao instalar o TTN 3.7 no Ubuntu.

Eu segui o guia do fox27374 (https://github.com/fox27374/lora-stack), mas ainda tenho o problema.
Minha instalação está na VM e no Ubuntu. Eu uso certificado auto-assinado para desenvolvimento local.

Eu ainda estou preso com este erro. "Troca Recusada de Token"
Agradeço antecipadamente,

Olá @ramampiandra ,

como escrevi no chat do Slack, para que tudo funcione, você precisa do seguinte:

• Um certificado para o tráfego TLS: cert.pem
• A chave privada correspondente: key.pem
• O certificado CA que emitiu o cert.pem: ca.pem

Verifique se os certificados estão corretos:

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

Certifique-se de que o Identificador de Chave de Autoridade no cert.pem seja o mesmo que o Identificador de Chave de Assunto no ca.pem.

Depois que a pilha for iniciada e todos os contêineres do docker estiverem ativos, execute o seguinte comando (adapte o "ttn-server_stack_1" ao nome do seu contêiner TTN):
docker exec -it --user root ttn-server_stack_1 /usr/sbin/update-ca-certificates
Isso instalará o certificado ca.pem no contêiner e o adicionará aos certificados confiáveis.

Depois disso, faça login diretamente no seu container e teste se o certificado funciona:

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

Você NÃO deve ver nenhum resultado ou erro - isso significa que seu certificado é confiável.

Eu espero que isso ajude,
Saúde

Então, depois de analisar isso em detalhes, consegui reproduzir e posso confirmar que há realmente um problema com a configuração do TLS (e especificamente os certificados raiz) não sendo respeitado pelo nosso fluxo OAuth, fazendo com que a troca de token falhe.

Atualmente estou trabalhando em um PR para consertar isso, que deve chegar ainda hoje.

@kschiffer incrível, obrigado por dar uma olhada nisso. Apenas me mantenha informado para que eu possa ajudá-lo com os testes.

Oi! Existe outra solução alternativa, para corrigir isso temporariamente?

@dgraposo isso deve ser corrigido em 3.8.1

Vou encerrar esta questão por enquanto, já que o foco mudou para a questão "troca de token recusada", que foi abordada via #2511 e que pode ser seguida mais adiante via #2521. Eu suspeito que este foi o maior motivo para adicionar uma seção de solução de problemas.

Esta questão já não é muito útil para discutir o seu propósito inicial. Sugiro reabrir com o escopo adequado se considerarmos que uma seção de solução de problemas ainda é necessária.