Lorawan-stack: एक ही मशीन पर apache + ttn स्टैक + letsencrypt acme प्रमाणपत्र में समस्या आती है

को निर्मित 19 दिस॰ 2019 · 5टिप्पणियाँ · स्रोत: TheThingsNetwork/lorawan-stack

बग रिपोर्ट सबमिट करने के लिए धन्यवाद. कृपया नीचे दिया गया टेम्प्लेट भरें, अन्यथा हम इस बग रिपोर्ट को संसाधित नहीं कर पाएंगे।

सारांश

समस्या जब ttn मशीन पर apache स्थापित और सक्षम (80/443 सुन रहा है)।
टीटीएन कंसोल 80/443 बंदरगाहों पर अवरुद्ध है और 1885,8885 बंदरगाहों पर काम कर रहा है।

इस मामले में ttn 'प्रमाणपत्र प्राप्त/अद्यतन नहीं कर सकता है।
यह बहुत ही सामान्य स्थिति है, अगर कोई एक ही डिवाइस पर टीटीएन स्टैक और कुछ डीबी/वेब ऐप रखना चाहता है।

https://github.com/TheThingsNetwork/lorawan-stack/issues/1731

TTN त्रुटि दिखाता है: छूटा हुआ प्रमाणपत्र / या होस्ट श्वेत सूची में नहीं है।

प्रजनन के चरण

हम समस्या का पुनरुत्पादन कैसे कर सकते हैं?

1) जब अपाचे सक्रिय होता है (80, 443 पर सुन रहा होता है) पोर्ट विन्यास - ttn स्टैक 80, 443 बंदरगाहों को सक्षम करने की अनुमति नहीं देता (80,443 docker-compose.yml में # होना चाहिए - पोर्ट 1885, 8885 का उपयोग किया जाता है)। इसमें (docker-compose को letsencrypt सर्टिफिकेट नहीं मिलता)।

docker-compose.yml फ़ाइल:

   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'

.env फ़ाइल पोर्ट को 443 के बजाय 8885 पर ले जाया गया:

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) जब हम:
अपाचे बंद करो (सेवा apache2 बंद करो)
सक्षम करने के लिए ttn-stack को पुन: कॉन्फ़िगर करें (80, 443 पोर्ट - निकालें (हैश))
वेब ब्राउज़र के साथ मुख्य उपडोमेन से कनेक्ट करें यह सफलतापूर्वक प्रमाण पत्र प्राप्त करता है (80/443 बंदरगाहों पर)

docker-compose.yml फ़ाइल:

  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 फ़ाइल मानक पोर्ट 443 का उपयोग करते हैं - इस मामले में ttn 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) अब अगर हमारे पास अद्यतन प्रमाण पत्र है तो हम पहले कॉन्फ़िगरेशन पर वापस जा सकते हैं (अपाचे द्वारा उपयोग किया गया पोर्ट 80/443, कंसोल के लिए टीटीएन 1885/8885 का उपयोग करें) - और इसका सफलतापूर्वक https://subdomain.domain.com:8885 पर कंसोल खोलें /.

अब आप क्या देखते हैं?

कृपया टर्मिनल आउटपुट पेस्ट करें, लॉग अपलोड करें (.txt के रूप में) या स्क्रीनशॉट अपलोड करें।

...

इसके बजाय आप क्या देखना चाहते हैं?

यदि लागू हो तो कृपया कुछ उदाहरण या मॉक-अप जोड़ें।

...

वातावरण

आपका परिवेश: OS/ब्राउज़र/गेटवे/डिवाइस/...? संस्करण? आईडी/ईयूआई? यदि लागू हो तो "ttn-lw-cli version" या "ttn-lw-stack version" का आउटपुट पेस्ट करें।

...

आप इसे कैसे लागू करने का प्रस्ताव रखते हैं?

क्या एक ही मशीन पर ttn और apache दोनों को कॉन्फ़िगर करने का कोई तरीका है?या बल अलग बंदरगाह पर प्रमाणीकरण प्राप्त करने के लिए एन्क्रिप्ट करने देता है?

क्या आप इसे स्वयं कर सकते हैं और पुल अनुरोध सबमिट कर सकते हैं?

यदि आपको इसके लिए सहायता की आवश्यकता हो तो आप @ विशेषज्ञों का भी

...

documentation

स्रोत

ecities

सबसे उपयोगी टिप्पणी

जब आप रिवर्स प्रॉक्सी के पीछे द थिंग्स स्टैक चलाते हैं, तो आपको कॉन्फ़िगरेशन में टीएलएस को पूरी तरह से अक्षम करना होगा और सभी टीएलएस कनेक्शन (न केवल HTTP, बल्कि जीआरपीसी, एमक्यूटीटी आदि) को समाप्त करने के लिए प्रॉक्सी को जिम्मेदार बनाना होगा। मुझे लगता है कि हम दस्तावेज कर सकते हैं कि द थिंग्स स्टैक के सभी टीएलएस श्रोताओं को कैसे अक्षम किया जाए, और रिवर्स प्रॉक्सी में किन बंदरगाहों को मैप करने की आवश्यकता है।

मुझे लगता है कि हम उम्मीद कर सकते हैं कि ऐसा करने वाले लोग पहले से ही जानते हैं कि उनकी प्रॉक्सी कैसे काम करती है, इसलिए मुझे नहीं लगता कि हमें इसे विशेष रूप से अपाचे/nginx/haproxy/envoy/आदि के साथ कैसे करना है।

htdvisser 19 दिस॰ 2019

👍2

सभी 5 टिप्पणियाँ

htdvisser 19 दिस॰ 2019

👍2

हाय @htdvisser , प्रतिक्रिया के लिए धन्यवाद।

मैंने स्थानीय कंप्यूटर पर सार्वजनिक/स्थिर आईपी पते (एलटीई आधारित) के साथ परीक्षण किया - मुझे नहीं पता कि नेटवर्क की संरचना क्या है।
मैंने इंटरनेट पर सीधे वीपीएस (ovh.eu) पर भी परीक्षण किया - प्रदाता के अनुसार यह प्रॉक्सी और फायरवॉल (केवल कुछ DoS) के बिना है।

दोनों प्रकारों के लिए समान की आवश्यकता होती है (प्रत्येक क्लाइंट/आईपी स्टेशन के लिए मानक 80/443 पोर्ट पर प्रमाणपत्र का आरंभीकरण)।
बाद में कंसोल को अन्य बंदरगाहों (1885/8885) पर स्विच किया जा सकता था।

वीपीएस या किसी सार्वजनिक/स्थिर आईपी डिवाइस के संबंध में एक और समस्या है - चाहे नेटवर्क की संरचना कोई भी हो।

मैं थोड़ी देर के लिए "कंसोल लॉग स्क्रीन" देखता हूं और टीटीएन स्टैक द्वारा रिपोर्ट किए गए बहुत से "हैकर्स गतिविधि परीक्षण" हैं (और हम स्क्रीन पर मानक http/htts पोर्ट पर केवल वेब हमले देखते हैं)। डोमेन/उपडोमेन में केवल डीएनएस रिकॉर्ड होते हैं और वेबपेज के लिए इसका उपयोग नहीं किया जाता है जिसे रोबोट/सर्च इंजन खोज सकते हैं। मुझे लगता है कि हैकर्स रोबोट प्रतिक्रिया देने वाले उपकरणों के लिए सभी स्टेटिक आईपी 4 पते खोजते हैं, और जल्दी या बाद में डिवाइस हैकर मशीनों द्वारा ढूंढा और हमला किया जाएगा। इसलिए, किसी भी सर्वर को ज्ञात http/https पोर्ट के लिए बड़े पैमाने पर हमलों में व्यस्त करना बहुत आसान है, भले ही वे 100% सुरक्षित हों।

मुझे लगता है कि कंसोल/वेब इंटरफेस के लिए 80/443 बंदरगाहों का उपयोग नहीं करना बहुत ही उचित है और टीटीएन स्टैक कंसोल के लिए उन्हें बदलने की संभावना है। यह प्रशासन के उद्देश्यों के लिए है (सार्वजनिक नहीं) और व्यवस्थापक इस सेटिंग से अवगत हैं।

केवल प्रश्न हैं:
योजना ए) हम विभिन्न बंदरगाहों पर स्वचालित रूप से एक्मे/लेटसेनक्रिप्ट प्रमाणपत्र कैसे बना/रीफ्रेश कर सकते हैं?
योजना बी) क्या प्रशासन के लिए कम से कम कुछ ज्ञात मेजबान (जैसे स्थिर आईपी) के लिए यहां वर्णित उपरोक्त मैन्युअल प्रक्रिया को स्वचालित करना संभव है?

ecities 19 दिस॰ 2019

ACME की HTTP-01 और TLS-ALPN-01 चुनौतियों के विनिर्देशों के लिए पोर्ट 80/443 का उपयोग करना आवश्यक है। यदि आप विभिन्न बंदरगाहों का उपयोग करते हैं तो आप उन चुनौतियों का उपयोग करके प्रमाणपत्र प्राप्त या नवीनीकृत नहीं कर सकते हैं।

आप सर्टबॉट (यह हमारे दस्तावेज़ीकरण के दायरे से बाहर है) या सशुल्क प्रमाणपत्र प्राधिकारी (हमारे दस्तावेज़ीकरण के दायरे से बाहर भी) जैसे टूल के साथ DNS-01 चुनौती का उपयोग करके ACME प्रमाणपत्रों का अनुरोध करने का प्रयास कर सकते हैं।

जब आपके पास ऐसे प्रमाणपत्र हों, तो आप "कस्टम प्रमाणपत्र" निर्देशों के अनुसार थिंग्स स्टैक को कॉन्फ़िगर कर सकते हैं: https://thethingsstack.io/v3.3.2/guides/getting-started/certificates/#custom -certificates और निम्नलिखित वातावरण के साथ :

TTN_LW_TLS_SOURCE=file
TTN_LW_TLS_CERTIFICATE=/path/to/cert-chain.pem
TTN_LW_TLS_CERTIFICATE=/path/to/key.pem

htdvisser 19 दिस॰ 2019

👍1

मैंने समस्या बनाई https://github.com/TheThingsNetwork/lorawan-stack/issues/1760 एक TLS-टर्मिनेटिंग प्रॉक्सी के पीछे चलने के लिए थिंग्स स्टैक को कॉन्फ़िगर करने के तरीके के दस्तावेज़ीकरण के लिए।

मैंने थिंग्स स्टैक में बाहरी रूप से अनुरोधित प्रमाणपत्रों को कॉन्फ़िगर करने के तरीके के दस्तावेजीकरण के लिए https://github.com/TheThingsNetwork/lorawan-stack/issues/1761 समस्या बनाई।

htdvisser 19 दिस॰ 2019

धन्यवाद

ecities 19 दिस॰ 2019

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Lorawan-stack: एक ही मशीन पर apache + ttn स्टैक + letsencrypt acme प्रमाणपत्र में समस्या आती है

सारांश

प्रजनन के चरण

अब आप क्या देखते हैं?

इसके बजाय आप क्या देखना चाहते हैं?

वातावरण

आप इसे कैसे लागू करने का प्रस्ताव रखते हैं?

क्या आप इसे स्वयं कर सकते हैं और पुल अनुरोध सबमिट कर सकते हैं?

सबसे उपयोगी टिप्पणी

सभी 5 टिप्पणियाँ

संबंधित मुद्दों