Lorawan-stack: Agregue una sección de solución de problemas en nuestra guía de inicio

Hola, definitivamente un aprobado por esto. Me encontré con un par de problemas y preguntas abiertas mientras seguía la guía. En este momento estoy atascado con este error. ¿Tal vez también pueda señalar este en la documentación?

@fox27374 ¿puede abrir las herramientas de desarrollo del navegador y pegar el window.PAGE_DATA ? Puede ingresar eso en la consola del navegador mientras ve este error.

Además, ¿seguiste todos los pasos de Primeros pasos, es decir, para crear el cliente Console OAuth?

Hola,
aquí está window.PAGE_DATA, así como el comando que uso para crear el cliente oauth. Un punto importante a mencionar es que uso mis propios certificados (firmados por la CA del laboratorio).

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

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

¡Muchas gracias!
Salud,
Daniel

@fox27374 gracias por la información adicional.

¿Cuál es la URL de OAuth configurada, es decir, la URL /token que configuró? Puede redactar contenido confidencial.

¿Puede confirmar que lora01.ntslab.loc se resuelve en el contenedor de Docker, suponiendo que ejecuta The Things Stack a través de Docker?

Hola,

Gracias por la respuesta y por ayudarme aquí. El contenido aún no es sensible, es una configuración de laboratorio por ahora como prueba para un futuro entorno de producción. Quiero deshacerme del servidor Actility :)

Sí, ejecuto la pila TTN a través de Docker en un servidor Linux. lora01.ntslab.loc está configurado en el archivo hosts, por lo que la resolución de nombres debería funcionar.

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

Si necesita más información, puede consultar directamente los archivos docker-compose.yml y ttn-lw-stack.yml . También uso un script de inicio para realizar la inicialización ( start.sh ).

Gracias de antemano,
Daniel

Hola @fox27374

Sí, ejecuto la pila TTN a través de Docker en un servidor Linux. lora01.ntslab.loc está configurado en el archivo hosts, por lo que la resolución de nombres debería funcionar.

¿Te refieres al archivo /etc/hosts de tu máquina? Esto no afecta el contenedor de Docker donde se ejecuta la pila, lo que podría ser el origen del problema que está viendo.

Podrías verificar eso con el siguiente comando:

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

Deberías ver algo nc: bad address 'lora01.ntslab.loc' .

¿Puedes intentar agregar una sección extra_hosts en tu docker-compose.yaml, así:

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

Y reinicie con docker-compose up -d

La resolución del nombre de host debería funcionar. (Pero, si YOUR_IP_ADDRESS es algo así como 127.0.0.1 , es posible que aún obtenga algunos errores)

Hola @neoaggelos
Gracias por la información. Eliminé la entrada de hosts y configuré la IP/nombre de host directamente en el servidor DNS. Además, agregué la entrada "extra_hosts" en docker-compose.yml.
Me temo que el error sigue existiendo.

Empecé ash shell en el contenedor y verifiqué la resolución de dns:

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

Así que esto parece bueno. Después del mensaje de error intercambio de token rechazado , ¿hay alguna depuración adicional que podamos habilitar para el intercambio de token de autenticación? Perdón por mantenerte ocupado con esto....
Gracias

Por cierto, parece que alguien más también tiene el mismo problema .

Hola @neoaggelos
Gracias por la información. Eliminé la entrada de hosts y configuré la IP/nombre de host directamente en el servidor DNS. Además, agregué la entrada "extra_hosts" en docker-compose.yml.

Hmm, con la configuración de DNS adecuada, no debería tener que configurar extra_hosts .

Me temo que el error sigue existiendo.

Empecé ash shell en el contenedor y verifiqué la resolución de dns:

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

El 172.24.89.120 es el de la red creado por Docker, que también podría ser una posible razón de falla.

Así que esto parece bueno. Después del mensaje de error intercambio de token rechazado , ¿hay alguna depuración adicional que podamos habilitar para el intercambio de token de autenticación? Perdón por mantenerte ocupado con esto....
Gracias

Intente borrar sus cookies e intente desde una sesión limpia del navegador también. Además, asegúrese de que los certificados se lean correctamente desde la pila cat /var/run/secrets/cert.pem y cat /var/run/secrets/key.pem desde un shell dentro del contenedor deberían ser suficientes para comprobarlo.

Sin relación; ¿Has intentado configurar la pila en localhost? ¿Tuviste éxito?

Hola,

lo siento, no mencioné que 172.24.89.120 es la dirección IP del propio servidor en el laboratorio. Las direcciones de la ventana acoplable son 172.9.0.X

Hago todas las pruebas con un navegador en modo privado, por lo que no hay cookies involucradas. La clave y el certificado se pueden leer con el usuario "thethings":

/ $ whoami
thethings

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

Intentaré cambiar la configuración a localhost y los mantendré informados.

lo siento, no mencioné que 172.24.89.120 es la dirección IP del propio servidor en el laboratorio. Las direcciones de la ventana acoplable son 172.9.0.X

Pero, ¿puedes curl https://lora01.ntslab.loc desde el interior del contenedor? Si no, ¿cuál es el error informado?

Hola,

parece que lo conseguimos. La pista del rizo fue buena. Esto mostró que ca.pem no estaba en el almacén de certificados de confianza:

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

Así que copié el certificado ca.pem en /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

agregándolo a la sección de volúmenes del archivo 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"

Ahora puedo iniciar sesión en la consola y todos los certificados son de confianza. ¡Increíble!

¿Es esta la forma mejor o más adecuada de agregar un certificado raíz de confianza al contenedor TTN?

Lo siento por estar eufórico demasiado pronto. Parece que el token de autenticación todavía estaba en la base de datos, por eso todo funcionó. Después de que se inicie el contenedor, necesitaba ejecutar este comando para agregar el certificado ca.pem a la tienda de confianza:

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

Luego, el cliente de autenticación puede obtener un token y almacenarlo en la base de datos. Puedo trabajar por ahora, pero supongo que esta no debería ser la solución final. ¿Algunas ideas?
¡Muchas gracias!

@ fox27374 genial que hayas encontrado la causa. Eso siempre es un buen comienzo para llegar a una solución limpia.

La pila respeta TTN_LW_TLS_ROOT_CA (o tls.root-ca ), un nombre de archivo, con su CA. Consulte https://thethingsstack.io/v3.7.0/reference/configuration/the-things-stack/

@johanstokking : agregué lo siguiente a 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

De esta forma, los archivos de certificado están disponibles en el contenedor en /run/secrets y /var/run/secrets . Revisé esto directamente en el contenedor.

yo añadí
TTN_LW_TLS_ROOT_CA: "/var/run/secrets/ca.pem"
al archivo docker-compose.yml . El error sigue ahí. También traté de agregar esto a 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"

Lo mismo aqui. Aún tengo el error. ¿Podría ser que algunas aplicaciones, especialmente el cliente de autenticación, utilicen los certificados raíz de confianza internos del sistema operativo? Porque tan pronto como agrego el ca.pem a los certificados raíz de confianza, todo funciona.
gracias, daniel

cc @adriansmares

hola, alguna noticia por aqui? Intenté depurar el acceso a los certificados raíz de confianza con strace pero no tuve éxito.

@fox27374 ¿puede verificar que esto funcione?

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

@adriansmares parece que necesitamos dos cosas;

1. Informe la causa del error subyacente, potencialmente como atributo de razón, ya que es un error net o algo más stdlib
2. Verifica que estemos respetando tls.root-ca en el cliente OAuth

Hola chicos,

Recibo el mismo error 403, ejecuto TTN stack v3 con docker dentro de un cuadro Vagrant (con Virtual Box). - Solo una caja de arena para mí para crear la receta Saltstack.

Probé muchos enfoques, considerando que me encargué del DNS.

• utilizar certificados autofirmados
• reutilice algunos certificados existentes creados con letsencrypt en una pila de VPS por TTN.
• probé todas las configuraciones insecure una por una

Para mi no es un problema de root-ca , no se que es. ¿Deberíamos abrir otro número para esto?

Sin embargo, una pregunta: según su conocimiento, ¿es posible configurarlo sin TLS , solo para fines de desarrollo dentro de un cuadro de Vagrant? Si es así, ¿podría darme algunos consejos?

Puedo confirmar que en mi VPS funciona bien con letsencrypt , que por supuesto es lo que tendremos en producción.

Gracias.

Agregar c/shared porque podría no ser una cosa de configuración

Hola, lo siento por la respuesta tardía. Puedo verificar que curl solo funciona con el parámetro --cacert ya que el certificado ca.pem no está instalado en los certificados raíz probados:

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

Compruebe si el cliente OAuth respeta la configuración TLS

si usa nginx delante de la pila, nginx debe manejar todos los ssl/tls.

estas son las configuraciones para 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;
}

necesita esto en la configuración de su sitio para todos los puertos (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
}

y esto para puertos (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 puede ver, estoy usando Lets Encrypt.

¡Muchas gracias @wasn-eu!

Esto también es útil para #1760.

Hola a todos,

Tengo un problema similar al instalar TTN 3.7 en ubuntu.

Seguí la guía de fox27374 (https://github.com/fox27374/lora-stack) pero aún tengo el problema.
Mi instalación está en VM y Ubuntu. Utilizo un certificado autofirmado para el desarrollo local.

Todavía estoy atascado con este error. "Intercambio de token rechazado"
Gracias de antemano,

Hola @ramampiandra ,

como escribí en el chat de Slack, para que todo funcione, necesitas lo siguiente:

• Un certificado para el tráfico TLS: cert.pem
• La clave privada correspondiente: key.pem
• El certificado CA que emitió el cert.pem: ca.pem

Por favor, asegúrese de que los certificados sean correctos:

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

Asegúrese de que el identificador de clave de autoridad en cert.pem sea el mismo que el identificador de clave de asunto en ca.pem.

Después de que se inicie la pila y todos los contenedores docker estén activos, ejecute el siguiente comando (adapte "ttn-server_stack_1" al nombre de su contenedor TTN):
docker exec -it --user root ttn-server_stack_1 /usr/sbin/update-ca-certificates
Esto instalará el certificado ca.pem dentro del contenedor y lo agregará a los certificados de confianza.

Después de eso, inicie sesión directamente en su contenedor y pruebe si el certificado funciona:

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

NO debería ver ningún resultado o error; esto significa que su certificado es de confianza.

Espero que esto ayude,
Salud

Entonces, después de analizar esto en detalle, pude reproducir y puedo confirmar que, de hecho, hay un problema con la configuración de TLS (y específicamente los certificados raíz) que no son respetados por nuestro flujo de OAuth, lo que hace que el intercambio de tokens falle.

Actualmente estoy trabajando en un PR para arreglar esto que debería llegar más tarde hoy.

@kschiffer impresionante, gracias por echar un vistazo a esto. Solo mantenme informado para que pueda ayudarte con las pruebas.

¡Hola! ¿Hay otra solución para arreglar esto temporalmente?

@dgraposo esto debería arreglarse en 3.8.1

Cerraré este problema por ahora, ya que el enfoque se movió al problema de "intercambio de token rechazado", que se ha abordado a través de #2511 y que se puede seguir más a través de #2521. Sospecho que esta fue la principal razón para agregar una sección de resolución de problemas.

Este número ya no es muy útil para discutir su propósito inicial. Sugiero reabrir con el alcance adecuado si consideramos que aún es necesaria una sección de solución de problemas.