Lorawan-stack: Apache + tumpukan ttn pada mesin yang sama + sertifikat letsencrypt acme mendapatkan masalah
Terima kasih telah mengirimkan laporan bug. Silakan isi template di bawah ini, jika tidak, kami tidak akan dapat memproses laporan bug ini.
Ringkasan
masalah ketika Apache diinstal dan diaktifkan (mendengarkan 80/443) pada mesin ttn.
Konsol TTN diblokir pada port 80/443 dan bekerja pada port 1885,8885.
Dalam hal ini ttn tidak bisa' mendapatkan/memperbarui sertifikat.
Situasinya sangat umum, jika seseorang ingin meletakkan tumpukan TTN dan beberapa aplikasi DB/web pada perangkat yang sama.
https://github.com/TheThingsNetwork/lorawan-stack/issues/1731
TTN menunjukkan kesalahan: sertifikat tidak terjawab/atau Host tidak ada dalam Daftar Putih.
Langkah-langkah untuk Reproduksi
Bagaimana kita bisa mereproduksi masalah?1) Ketika Apache aktif (mendengarkan pada 80, 443) konfigurasi port - ttn stack tidak mengizinkan untuk mengaktifkan 80, 443 port (80.443 harus # di docker-compose.yml - port 1885, 8885 digunakan) . Dalam hal ini (docker-compose tidak mendapatkan sertifikat letsencrypt).
docker-compose.yml berkas:
ports:
(hashed) - '80:1885'
(hashed) - '443:8885'
- '1882:1882'
- '8882:8882'
- '1883:1883'
- '8883:8883'
- '1884:1884'
- '8884:8884'
- '1885:1885'
- '8885:8885'
- '8886:8886'
- '1887:1887'
- '8887:8887'
- '1700:1700/udp'
env_file: '.env'
File .env memindahkan port ke 8885 sebagai gantinya 443:
TTN_LW_IS_EMAIL_NETWORK_CONSOLE_URL=https://subdomain.example.com:8885/console
TTN_LW_IS_EMAIL_NETWORK_IDENTITY_SERVER_URL=https://subdomain.example.com:8885/oauth
TTN_LW_IS_OAUTH_UI_CANONICAL_URL=https://subdomain.example.com:8885/oauth
TTN_LW_IS_OAUTH_UI_IS_BASE_URL=https://subdomain.example.com:8885/api/v3
TTN_LW_CONSOLE_OAUTH_AUTHORIZE_URL=https://subdomain.example.com:8885/oauth/authorize
TTN_LW_CONSOLE_OAUTH_TOKEN_URL=https://subdomain.example.com:8885/oauth/token
TTN_LW_CONSOLE_UI_CANONICAL_URL=https://subdomain.example.com:8885/console
TTN_LW_CONSOLE_UI_AS_BASE_URL=https://subdomain.example.com:8885/api/v3
TTN_LW_CONSOLE_UI_GS_BASE_URL=https://subdomain.example.com:8885/api/v3
TTN_LW_CONSOLE_UI_IS_BASE_URL=https://subdomain.example.com:8885/api/v3
TTN_LW_CONSOLE_UI_JS_BASE_URL=https://subdomain.example.com:8885/api/v3
TTN_LW_CONSOLE_UI_NS_BASE_URL=https://subdomain.example.com:8885/api/v3
TTN_LW_CONSOLE_UI_EDTC_BASE_URL=https://subdomain.example.com:8885/api/v3
TTN_LW_CONSOLE_UI_QRG_BASE_URL=https://subdomain.example.com:8885/api/v3
2) Ketika kita:
hentikan apache (layanan apache2 berhenti)
konfigurasikan ulang ttn-stack untuk mengaktifkan (80, 443 port - hapus (hash) )
terhubung dengan browser web ke subdomain utama ia berhasil mendapatkan sertifikat (pada port 80/443)
docker-compose.yml berkas:
ports:
- '80:1885'
- '443:8885'
- '1882:1882'
- '8882:8882'
- '1883:1883'
- '8883:8883'
- '1884:1884'
- '8884:8884'
(hashed) - '1885:1885'
(hashed) - '8885:8885'
- '8886:8886'
- '1887:1887'
- '8887:8887'
- '1700:1700/udp'
env_file: '.env'
.env file port standar menggunakan 443 - dalam hal ini ttn dapatkan sertifikat letsencrypt
TTN_LW_IS_EMAIL_NETWORK_CONSOLE_URL=https://subdomain.example.com/console
TTN_LW_IS_EMAIL_NETWORK_IDENTITY_SERVER_URL=https://subdomain.example.com/oauth
TTN_LW_IS_OAUTH_UI_CANONICAL_URL=https://subdomain.example.com/oauth
TTN_LW_IS_OAUTH_UI_IS_BASE_URL=https://subdomain.example.com/api/v3
TTN_LW_CONSOLE_OAUTH_AUTHORIZE_URL=https://subdomain.example.com/oauth/authorize
TTN_LW_CONSOLE_OAUTH_TOKEN_URL=https://subdomain.example.com/oauth/token
TTN_LW_CONSOLE_UI_CANONICAL_URL=https://subdomain.example.com/console
TTN_LW_CONSOLE_UI_AS_BASE_URL=https://subdomain.example.com/api/v3
TTN_LW_CONSOLE_UI_GS_BASE_URL=https://subdomain.example.com/api/v3
TTN_LW_CONSOLE_UI_IS_BASE_URL=https://subdomain.example.com/api/v3
TTN_LW_CONSOLE_UI_JS_BASE_URL=https://subdomain.example.com/api/v3
TTN_LW_CONSOLE_UI_NS_BASE_URL=https://subdomain.example.com/api/v3
TTN_LW_CONSOLE_UI_EDTC_BASE_URL=https://subdomain.example.com/api/v3
TTN_LW_CONSOLE_UI_QRG_BASE_URL=https://subdomain.example.com/api/v3
3) Sekarang jika kami telah memperbarui sertifikat, kami dapat beralih kembali ke konfigurasi pertama (port 80/443 digunakan oleh Apache, ttn gunakan 1885/8885 untuk konsol) - dan konsolnya berhasil membuka di https://subdomain.domain.com :8885 /.
Apa yang kamu lihat sekarang?
Harap tempel keluaran terminal, unggah log (sebagai .txt) atau unggah tangkapan layar....
Apa yang ingin Anda lihat sebagai gantinya?
Harap tambahkan beberapa contoh atau maket jika ada....
Lingkungan
Lingkungan Anda: OS/Browser/Gateway/Device/...? Versi? ID/EUI? Rekatkan output "ttn-lw-cli version" atau "ttn-lw-stack version" jika berlaku....
Bagaimana Anda mengusulkan untuk menerapkan ini?
Apakah ada cara untuk mengkonfigurasi ttn dan Apache pada mesin yang sama?atau memaksa memungkinkan mengenkripsi untuk mendapatkan sertifikasi pada port yang berbeda?
Bisakah Anda melakukannya sendiri dan mengajukan Permintaan Tarik?
Anda juga dapat @menyebut pakar jika Anda memerlukan bantuan terkait hal ini....
ecities
Semua 5 komentar
Saat Anda menjalankan The Things Stack di belakang proxy terbalik, Anda harus sepenuhnya menonaktifkan TLS dalam konfigurasi dan membuat proxy bertanggung jawab untuk mengakhiri semua koneksi TLS (tidak hanya HTTP, tetapi juga gRPC, MQTT, dll.). Saya kira kita dapat mendokumentasikan cara menonaktifkan semua pendengar TLS dari The Things Stack, dan port apa yang perlu dipetakan di proxy terbalik.
Saya pikir kita dapat mengharapkan bahwa orang yang akan melakukan ini sudah tahu cara kerja proxy mereka, jadi saya tidak berpikir kita harus mendokumentasikan bagaimana melakukan ini secara khusus dengan Apache/nginx/haproxy/envoy/etc.
htdvisser
pada 19 Des 2019
Hai @htdvisser , Terima kasih atas tanggapannya.
Saya menguji di komputer lokal dengan alamat IP publik/statis (berbasis LTE) - Saya tidak tahu apa struktur jaringannya.
Saya juga menguji di VPS (ovh.eu) langsung di sisi internet - menurut penyedia itu tanpa proxy dan firewall (hanya beberapa DoS).
Kedua varian memerlukan hal yang sama (penginisialisasian sertifikat pada port standar 80/443 untuk setiap stasiun klien/ip).
Kemudian konsol dapat dialihkan ke port lain (1885/8885).
Ada masalah lain mengenai VPS atau perangkat
Saya melihat "layar log konsol" untuk sementara waktu dan ada banyak "uji coba aktivitas peretas" yang dilaporkan oleh tumpukan TTN (dan kami hanya melihat serangan web pada port http/htts standar di layar). Domain/subdomain hanya memiliki catatan dns dan tidak digunakan untuk halaman web yang mungkin ditemukan oleh robot/mesin telusur. Saya berasumsi robot peretas mencari semua alamat IP4 Statis untuk perangkat yang merespons, dan cepat atau lambat perangkat akan ditemukan dan diserang oleh mesin peretas. Jadi, sangat mudah untuk membuat server mana pun sibuk dengan serangan massal untuk port http/https yang diketahui, bahkan jika mereka 100% aman.
Saya pikir sangat masuk akal untuk tidak menggunakan port 80/443 untuk antarmuka konsol/web dan memiliki kemungkinan untuk mengubahnya untuk konsol tumpukan TTN. Ini untuk tujuan administrasi (bukan publik) dan administrator mengetahui pengaturan ini.
Satu-satunya pertanyaan adalah:
Paket A) Bagaimana kami dapat membuat/menyegarkan sertifikat acme/letsencrypt secara otomatis pada port yang berbeda?
Rencana B) Apakah mungkin untuk mengotomatisasi prosedur manual di atas, yang dijelaskan di sini setidaknya untuk beberapa host yang dikenal (misalnya ip statis) untuk administrasi?
ecities
pada 19 Des 2019
Spesifikasi untuk tantangan HTTP-01 dan TLS-ALPN-01 ACME memerlukan penggunaan port 80/443. Anda tidak bisa mendapatkan atau memperbarui sertifikat menggunakan tantangan tersebut jika Anda menggunakan port yang berbeda.
Anda dapat mencoba meminta sertifikat ACME menggunakan tantangan DNS-01 dengan alat seperti certbot (ini di luar cakupan dokumentasi kami) atau dari otoritas sertifikat berbayar (juga di luar cakupan dokumentasi kami).
Ketika Anda memiliki sertifikat seperti itu, Anda dapat mengonfigurasi The Things Stack sesuai dengan instruksi "Sertifikat Kustom": https://thethingsstack.io/v3.3.2/guides/getting-started/certificates/#custom -certificates dan dengan lingkungan berikut :
TTN_LW_TLS_SOURCE=file
TTN_LW_TLS_CERTIFICATE=/path/to/cert-chain.pem
TTN_LW_TLS_CERTIFICATE=/path/to/key.pem
Saya membuat masalah https://github.com/TheThingsNetwork/lorawan-stack/issues/1760 untuk mendokumentasikan cara mengonfigurasi The Things Stack untuk berjalan di belakang proxy pengakhiran TLS.
Saya membuat masalah https://github.com/TheThingsNetwork/lorawan-stack/issues/1761 untuk mendokumentasikan cara mengonfigurasi sertifikat yang diminta secara eksternal di The Things Stack.
htdvisser
pada 19 Des 2019
Terima kasih
ecities
pada 19 Des 2019
Masalah terkait
w4tsn
·
6Komentar
kschiffer
·
6Komentar
johanstokking
·
8Komentar
adriansmares
·
9Komentar
rvolosatovs
·
9Komentar
Komentar yang paling membantu
Saat Anda menjalankan The Things Stack di belakang proxy terbalik, Anda harus sepenuhnya menonaktifkan TLS dalam konfigurasi dan membuat proxy bertanggung jawab untuk mengakhiri semua koneksi TLS (tidak hanya HTTP, tetapi juga gRPC, MQTT, dll.). Saya kira kita dapat mendokumentasikan cara menonaktifkan semua pendengar TLS dari The Things Stack, dan port apa yang perlu dipetakan di proxy terbalik.
Saya pikir kita dapat mengharapkan bahwa orang yang akan melakukan ini sudah tahu cara kerja proxy mereka, jadi saya tidak berpikir kita harus mendokumentasikan bagaimana melakukan ini secara khusus dengan Apache/nginx/haproxy/envoy/etc.