Lorawan-stack: スタートガイドにトラブルシューティングセクションを追加する

こんにちは、間違いなくこれに賛成です。 ガイドをフォローしているときに、いくつかの問題が発生し、質問が開かれました。 現時点では、このエラーで立ち往生しています。 たぶん、ドキュメントでこれを指すこともできますか？

@ fox27374ブラウザ開発ツールを開いてwindow.PAGE_DATAの値を貼り付けることができますか？ このエラーが表示されている間、ブラウザコンソールに入力できます。

また、スタートガイドのすべての手順、つまりコンソールOAuthクライアントの作成を実行しましたか？

やあ、
これがwindow.PAGE_DATAと、oauthクライアントの作成に使用するコマンドです。 言及すべき重要な点の1つは、私が自分の証明書（ラボ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追加情報をありがとう。

構成されたOAuthURL、つまり構成した/token URLは何ですか？ 機密コンテンツを編集できます。

Dockerを介してThingsStackを実行していると仮定して、Dockerコンテナでlora01.ntslab.locが解決されることを確認できますか？

やあ、

返信とここで私を助けてくれてありがとう。 コンテンツはまだ意味がありません。将来の本番環境のテストとして、今のところラボのセットアップです。 Actilityサーバーを削除したい:)

はい、LinuxサーバーでDockerを介してTTNスタックを実行します。 lora01.ntslab.locはhostsファイルで構成されているため、名前解決が機能するはずです。

/ tokenURLは次のとおりです。
token-url： ' https：//lora01.ntslab.loc/oauth/token '

さらに詳しい情報が必要な場合は、docker- compose.ymlファイルとttn-lw-stack.ymlファイルを直接確認できます。 また、開始スクリプトを使用して初期化を行います（ start.sh ）。

前もって感謝します、
ダニエル

こんにちは@ fox27374

はい、LinuxサーバーでDockerを介してTTNスタックを実行します。 lora01.ntslab.locはhostsファイルで構成されているため、名前解決が機能するはずです。

あなたのマシンの/etc/hostsファイルを意味しますか？ これは、スタックが実行されているDockerコンテナには影響しません。これは、発生している問題の原因である可能性があります。

次のコマンドで確認できます。

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

nc: bad address 'lora01.ntslab.loc'の線に沿って何かが表示されるはずです。

次のように、docker-compose.yamlにextra_hostsセクションを追加してみてください。

# 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
情報ありがとうございます。 ホストエントリを削除し、DNSサーバーに直接IP /ホスト名を設定しました。 さらに、docker-compose.ymlに「extra_hosts」エントリを追加しました。
恐れ入りますが、エラーはまだ存在します。

コンテナでashshellを起動し、DNSの解像度を確認しました。

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

だからこれは良さそうだ。 トークン交換が拒否されたというエラーメッセージに続いて、oauthトークン交換に対して有効にできる追加のデバッグはありますか？ これで忙しくしてすみません...。
ありがとう

ちなみに、他の誰かも同じ問題を抱えているようです

こんにちは@neoaggelos
情報ありがとうございます。 ホストエントリを削除し、DNSサーバーに直接IP /ホスト名を設定しました。 さらに、docker-compose.ymlに「extra_hosts」エントリを追加しました。

うーん、適切なDNS構成があれば、 extra_hostsを設定する必要はありません。

恐れ入りますが、エラーはまだ存在します。

コンテナでashshellを起動し、DNSの解像度を確認しました。

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

172.24.89.120は、Dockerによって作成されたネットワークからのものであり、これも失敗の原因である可能性があります。

だからこれは良さそうだ。 トークン交換が拒否されたというエラーメッセージに続いて、oauthトークン交換に対して有効にできる追加のデバッグはありますか？ これで忙しくしてすみません...。
ありがとう

Cookieをクリアし、クリーンなブラウザセッションからも試してみてください。 また、証明書がスタックcat /var/run/secrets/cert.pemから適切に読み取られ、コンテナ内のシェルからcat /var/run/secrets/key.pemがそれをチェックするのに十分であることを確認してください。

オフトピック; ローカルホストでスタックを設定してみましたか？ 成功しましたか？

やあ、

申し訳ありませんが、172.24.89.120がラボ内のサーバー自体のIPアドレスであることについては触れませんでした。 Dockerアドレスは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
......

設定をローカルホストに変更して、投稿を続けます。

申し訳ありませんが、172.24.89.120がラボ内のサーバー自体のIPアドレスであることについては触れませんでした。 Dockerアドレスは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コンテナに追加するための最良の/意図された方法ですか？

陶酔感が早すぎてごめんなさい。 認証トークンがまだDBに残っているようです。そのため、すべてが機能しました。 コンテナの起動後、信頼できるストアにca.pem証明書を追加するには、次のコマンドを実行する必要がありました。

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

その後、oauthクライアントはトークンを取得してDBに保存できます。 私は今のところ働くことができますが、これは私が推測する最終的な解決策ではないはずです。 何か案は？
どうもありがとう！

@ 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クライアントがOS内部の信頼されたルート証明書を使用している可能性がありますか？ 信頼されたルート証明書にca.pemを追加するとすぐに、すべてが機能するためです。
ありがとう、ダニエル

cc @adriansmares

こんにちは、ここに何かニュースはありますか？ straceを使用して信頼されたルート証明書へのアクセスをデバッグしようとしましたが、成功しませんでした。

@ fox27374これが機能することを確認できますか？

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

@adriansmaresには2つのものが必要なようです。

1. netエラーまたはその他のstdlibであるため、根本的なエラーの原因を、場合によってはreason属性として報告します。
2. OAuthクライアントでtls.root-caを尊重していることを確認します

こんにちは、みんな、

同じ403エラーが発生し、Vagrantボックス内（Virtual Boxを使用）でDockerを使用してTTNスタックv3を実行しています。 -Saltstackレシピを作成するためのサンドボックスです。

DNSの面倒を見て、いろいろなアプローチを試しました。

• 自己署名証明書を使用する
• VPS by TTNスタックでletsencryptで作成された既存の証明書を再利用します。
• すべてのinsecure構成を1つずつ試しました

私にとってそれはroot-caの問題ではありません、私はそれが何であるかわかりません。 これについて別の問題を開く必要がありますか？

ただし、1つの質問：あなたの知識から、Vagrantボックス内の開発目的のためだけにTLSなしで構成することは可能ですか？ もしそうなら、私にいくつかの指針を教えていただけますか？

私のVPSでは、 letsencryptで正常に動作することを確認できます。これは、もちろん本番環境で使用するものです。

ありがとう。

c/sharedを追加すると、構成ではない可能性があります

こんにちは、返信が遅くなってすみません。 ca.pem証明書がtustedルート証明書にインストールされていないため、curlが--cacertパラメーターでのみ機能することを確認できます。

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

すべてのポート（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
}

ポートの場合（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にも役立ちます。

こんにちは、みんな、

UbuntuにTTN3.7をインストールするときにも同様の問題が発生します。

fox27374のガイド（https://github.com/fox27374/lora-stack）に従いましたが、まだ問題があります。
私のインストールはVMとUbuntuにあります。 ローカル開発には自己署名証明書を使用します。

私はまだこのエラーで立ち往生しています。 「トークン拒否交換」
前もって感謝します、

こんにちは@ramampiandra 、

Slackチャットで書いたように、すべてが機能するには、次のものが必要です。

• TLSトラフィックの証明書：cert.pem
• 対応する秘密鍵：key.pem
• cert.pemを発行したCA証明書：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のAuthorityKeyIdentifierがca.pemのSubjectKeyIdentifierと同じであることを確認してください。

スタックが開始され、すべてのDockerコンテナーが起動したら、次のコマンドを実行します（「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でさらにフォローできる「トークン交換拒否」の問題に焦点が移ったため、この問題は今のところ閉じます。 これがトラブルシューティングセクションを追加する最大の理由だったと思います。

この問題は、その最初の目的を議論するのにもはやあまり役に立ちません。 トラブルシューティングのセクションがまだ必要であると思われる場合は、適切なスコープで再開することをお勧めします。