شكرا لإرسال تقرير الشوائب. يرجى ملء النموذج أدناه ، وإلا فلن نتمكن من معالجة تقرير الخطأ هذا.
مشكلة عند تثبيت Apache وتمكينه (الاستماع 80/443) على جهاز ttn.
تم حظر وحدة التحكم TTN على منافذ 80/443 وتعمل على 1885،8885 منفذًا.
في هذه الحالة لا يمكن الحصول على / تحديث شهادة ttn.
إنه موقف شائع جدًا ، إذا أراد شخص ما وضع TTN stack وبعض تطبيقات DB / web على نفس الجهاز.
https://github.com/TheThingsNetwork/lorawan-stack/issues/1731
تعرض TTN الخطأ: الشهادة الفائتة / أو المضيف ليس في القائمة البيضاء.
1) عندما يكون apache نشطًا (الاستماع إلى 80 ، 443) تكوين المنفذ - لا يسمح ttn stack بتمكين 80 ، 443 منفذًا (يجب أن يكون 80443 # في 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
نقل الملف
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 stop)
إعادة تكوين 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 المستخدم بواسطة apache ، يستخدم ttn 1885/8885 لوحدة التحكم) - ووحدة التحكم المفتوحة بنجاح على https://subdomain.domain.com : 8885 /.
...
...
...
هل هناك طريقة لتهيئة كل من ttn و apache على نفس الجهاز؟أو تسمح القوة بتشفير الحصول على ترخيص على منفذ مختلف؟
...
عند تشغيل The Things Stack خلف وكيل عكسي ، سيتعين عليك تعطيل TLS تمامًا في التكوين وجعل الوكيل مسؤولاً عن إنهاء جميع اتصالات TLS (ليس فقط HTTP ، ولكن أيضًا gRPC و MQTT وما إلى ذلك). أفترض أنه يمكننا توثيق كيفية تعطيل جميع مستمعي TLS في The Things Stack ، وما هي المنافذ التي يجب تعيينها في الوكيل العكسي.
أعتقد أنه يمكننا أن نتوقع أن الأشخاص الذين سيفعلون ذلك يعرفون بالفعل كيف يعمل وكيلهم ، لذلك لا أعتقد أنه يجب علينا توثيق كيفية القيام بذلك على وجه التحديد باستخدام apache / nginx / haproxy / envoy / إلخ.
مرحبًا htdvisser ، شكرًا على الرد.
لقد اختبرت على جهاز كمبيوتر محلي بعنوان IP عام / ثابت (يعتمد على lte) - لا أعرف ما هي بنية الشبكة.
لقد اختبرت أيضًا على VPS (ovh.eu) مباشرةً على جانب الإنترنت - وفقًا لموفر الخدمة ، فهي بدون وكلاء وجدران حماية (فقط بعض DoS).
يتطلب كلا المتغيرين نفس (تهيئة الشهادة على المنفذ القياسي 80/443 لكل عميل / محطة ip).
في وقت لاحق يمكن تحويل وحدة التحكم إلى منافذ أخرى (1885/8885).
هناك مشكلات أخرى تتعلق بـ VPS أو أي أجهزة
ألقي نظرة على "شاشة سجل وحدة التحكم" لفترة من الوقت وهناك الكثير من "تجارب نشاط المتسللين" التي تم الإبلاغ عنها بواسطة TTN stack (ونرى فقط هجمات الويب على منفذ http / htts القياسي على الشاشة). يحتوي المجال / المجال الفرعي على سجلات نظام أسماء النطاقات فقط ولم يتم استخدامه لصفحة الويب التي قد تكتشفها الروبوتات / محركات البحث. أفترض أن روبوتات المتسللين تبحث في جميع عناوين IP4 الثابتة عن الأجهزة المستجيبة ، وسيتم العثور على الجهاز عاجلاً أم آجلاً ومهاجمته بواسطة أجهزة المتسللين. لذلك ، من السهل جدًا جعل أي خادم مشغولًا بهجمات جماعية لمنافذ http / https المعروفة ، حتى لو كانت آمنة بنسبة 100٪.
أعتقد أنه من المعقول جدًا عدم استخدام منافذ 80/443 لوحدة التحكم / واجهة الويب ولديها إمكانية تغييرها لوحدة تحكم مكدس TTN. إنها لأغراض الإدارة (ليست عامة) والمسؤولون على علم بهذه الإعدادات.
الأسئلة الوحيدة هي:
الخطة أ) كيف يمكننا إنشاء / تحديث شهادات acme / Letsencrypt تلقائيًا على منافذ مختلفة؟
الخطة ب) هل من الممكن أتمتة الإجراء اليدوي أعلاه ، الموصوف هنا على الأقل لعدد قليل من المضيفين المعروفين (مثل IP الثابت) للإدارة؟
تتطلب مواصفات تحديات HTTP-01 و TLS-ALPN-01 الخاصة بـ ACME استخدام المنفذ 80/443. لا يمكنك الحصول على الشهادات أو تجديدها باستخدام هذه التحديات إذا كنت تستخدم منافذ مختلفة.
يمكنك محاولة طلب شهادات ACME باستخدام تحدي DNS-01 باستخدام أداة مثل certbot (هذا خارج نطاق وثائقنا) أو من مرجع مصدق مدفوع (خارج نطاق وثائقنا أيضًا).
عندما يكون لديك مثل هذه الشهادات ، يمكنك تكوين The Things Stack وفقًا لإرشادات "الشهادات المخصصة": 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
لقد أنشأت مشكلة https://github.com/TheThingsNetwork/lorawan-stack/issues/1760 لتوثيق كيفية تكوين The Things Stack للتشغيل خلف وكيل إنهاء TLS.
لقد قمت بإنشاء مشكلة https://github.com/TheThingsNetwork/lorawan-stack/issues/1761 لتوثيق كيفية تكوين الشهادات المطلوبة خارجيًا في The Things Stack.
شكرا
التعليق الأكثر فائدة
عند تشغيل The Things Stack خلف وكيل عكسي ، سيتعين عليك تعطيل TLS تمامًا في التكوين وجعل الوكيل مسؤولاً عن إنهاء جميع اتصالات TLS (ليس فقط HTTP ، ولكن أيضًا gRPC و MQTT وما إلى ذلك). أفترض أنه يمكننا توثيق كيفية تعطيل جميع مستمعي TLS في The Things Stack ، وما هي المنافذ التي يجب تعيينها في الوكيل العكسي.
أعتقد أنه يمكننا أن نتوقع أن الأشخاص الذين سيفعلون ذلك يعرفون بالفعل كيف يعمل وكيلهم ، لذلك لا أعتقد أنه يجب علينا توثيق كيفية القيام بذلك على وجه التحديد باستخدام apache / nginx / haproxy / envoy / إلخ.