المنافذ 443/80 تظهر مغلقة بعد التثبيت

تثبيت
1

مرحباً،
لقد انتهيت للتو من تثبيت Discourse لأول مرة على خادم Ubuntu 22.04.4 على Proxmox VE (بيئة افتراضية).
سار التثبيت بشكل جيد، دون أي أخطاء، ولكن بعد الانتهاء منه - لم يتمكن موقع المنتدى من الفتح، مشيراً إلى أن الخدمة غير متاحة.

عند التحقق من شبكتي، أرى المنافذ مغلقة:

PS C:\Users\mwojt> nmap 192.168.131.211

PORT    STATE  SERVICE
22/tcp  open   ssh
80/tcp  closed http
443/tcp closed https

ولكن عند تشغيل نفس الأمر للمضيف المحلي من داخل جهاز Ubuntu، يظهر أنها مفتوحة:

root@ubuntu-discourse:~# nmap localhost

PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https

ومع ذلك، إذا قمت بتشغيل التحقق من عنوان IP من نفس جهاز Ubuntu الافتراضي إلى عنوان IP، أرى هذا:

root@ubuntu-discourse:~# nmap 192.168.131.211

PORT    STATE    SERVICE
22/tcp  open     ssh
80/tcp  filtered http
443/tcp filtered https

لذلك، تظهر المنافذ كـ “filtered”.
تم فتح المنافذ في جدار الحماية:

root@ubuntu-discourse:~# ufw status
Status: active

To                         Action      From
--                         ------      ----
80                         ALLOW       Anywhere
443                        ALLOW       Anywhere
22                         ALLOW       Anywhere
80 (v6)                    ALLOW       Anywhere (v6)
443 (v6)                   ALLOW       Anywhere (v6)
22 (v6)                    ALLOW       Anywhere (v6)

ويبدو أن إعادة توجيه منافذ Docker تم ضبطها بشكل صحيح:

root@ubuntu-discourse:~# docker port 6922c7802903
80/tcp -> 0.0.0.0:80
80/tcp -> [::]:80
443/tcp -> 0.0.0.0:443
443/tcp -> [::]:443

ماذا أفعل بشكل خاطئ؟ أين المشكلة؟

2

لقد أمضيت 90 دقيقة أخرى في تثبيت Discourse. هذه المرة على جهاز مادي منفصل لاستبعاد البيئة الافتراضية وحصلت على مشكلة مماثلة، على الرغم من أنني اتبعت التعليمات من GitHub بعناية.

هل من المستحيل تشغيل هذا؟

3

هل يمكن أن تكون المشكلة من طرفك؟ أرى نتائج مشابهة جدًا لنتائجك، مع مثيل Discourse الذي يعمل بشكل صحيح لدي.

هل يمكنك الوصول إلى مثيلك باستخدام وكيل، مثل Browserling؟

تعديل: لحظة، عنوانك 192.168.131.211 هو عنوان محلي، لا يتوقع أن يكون قابلاً للوصول إليه من العالم الخارجي.

تعديل: ماذا ترى على مضيف Discourse الخاص بك عند تجربة netstat -rn

4

هذه هي نتيجة netstat الخاصة بي:

root@ubuntu-forum:/var/discourse# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.131.1   0.0.0.0         UG        0 0          0 enp1s0
172.17.0.0      0.0.0.0         255.255.0.0     U         0 0          0 docker0
192.168.130.0   0.0.0.0         255.255.254.0   U         0 0          0 enp1s0
192.168.131.1   0.0.0.0         255.255.255.255 UH        0 0          0 enp1s0
192.168.131.152 0.0.0.0         255.255.255.255 UH        0 0          0 enp1s0

بالإضافة إلى Discourse على Ubuntu، قمت بتثبيت Talkyard على Debian (Talkyard هو محرك منتديات مشابه لـ Discourse)، أيضًا على Docker، وهو يعمل بشكل رائع. لذلك أعتقد أنني سأحاول تثبيت Discourse على Debian أيضًا.

تبدو نتيجة Netstat -rn على Debian الخاصة بي كالتالي:

root@debian-12:~# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.131.1   0.0.0.0         UG        0 0          0 ens18
172.17.0.0      0.0.0.0         255.255.0.0     U         0 0          0 docker0
172.26.0.0      0.0.0.0         255.255.255.128 U         0 0          0 br-886bebfa13ae
192.168.130.0   0.0.0.0         255.255.254.0   U         0 0          0 ens18

لست متأكدًا مما إذا كان هذا مفيدًا.

5

أعتقد أنه صحيح أن Discourse يعمل فقط عند الوصول إليه عبر نطاق، فهل لديك إعداد يمكنك من خلاله الوصول إلى موقعك باستخدام متصفح ونطاق؟ إذا كنت محليًا بالكامل على شبكتك المحلية الخاصة، فيمكنك ربما القيام بذلك باستخدام ملف hosts، لكنني لست متأكدًا. أعتقد أن الخادم والعميل (وربما أيضًا docker) بحاجة إلى أن يكونا قادرين على إجراء بحث عن الاسم.

6

لدي خادم DNS محلي يقوم بحل اسم شبكتي إلى هذا المضيف، لذا فهو يعمل تمامًا كما هو الحال من العالم الخارجي.

لقد قمت للتو بتثبيت Discourse بنجاح على جهاز افتراضي في DigitalOcean. سأستخدمه كمرجع لتكويني المحلي. أحد الأشياء التي لاحظتها على الفور هو ملف المضيفين على الجهاز الافتراضي - لديه الإدخال التالي:

image
image646×161 4.16 KB

آمل أن يكون هذا هو كل شيء. سأعلمك.

7

لا، فشل… لقد هُزمت تمامًا بعد 3 أيام من الكفاح وأنا متعب… :slightly_frowning_face:
بدأت أفكر أنه ليس من الممكن تثبيت Discourse على جهازك المحلي، وليس مستضافًا من قبل مزود :frowning:

تحقق من هذا الفيديو الذي سجلته أثناء تثبيته وأخبرني من فضلك - ما الذي أفعله بشكل خاطئ.

8

قد يكون من المفيد تجربة
lsof -i
على الخادم

يبدو من المحتمل جدًا أن Discourse يعمل ولكن هناك مشكلة في وضع الشبكة تجعله غير قابل للوصول.

9

حسنًا، لقد وجدت السبب الجذري… لقد تحققت من سجلات docker واتضح أن خادم nginx لا يبدأ على الإطلاق لأنه يفشل في الحصول على شهادة Let’s Encrypt (انظر السجلات المرفقة)
docker_logs_not_working.txt (10.0 KB)

الآن أحتاج إلى معرفة كيفية إصلاح ذلك. في الواقع، أنا لا أحتاج حتى إلى SSL لأنني أستخدم وكيلًا عكسيًا بشهادات SSL الخاصة به. لذلك يمكنه التحدث بسهولة مع Discourse عبر المنفذ 80. لست متأكدًا مما إذا كان خادم Discourse سيحب ذلك.

10

إذا قمت بالبحث، ستجد أن هذا هو السبب الأكثر شيوعًا لفشل الإعدادات المحلية ذات البيئات المغلقة، المعروفة باسم الإنترانت. يحتاج Discourse إلى SSL.

11

يتم استضافة نظام أسماء النطاقات (DNS) الخاص بي بواسطة Cloudflare، لذا يمكنني بسهولة الحصول على شهادات LetsEncrypt الخاصة بي حيث يمكنني توفير مفتاح API لذلك. هل يمكنني تكوين ACME في Discourse لجعل توفير الشهادات الخاص بي يعمل بسلاسة؟ لم أتمكن من العثور في الدليل، ولكن ربما لا أبحث جيدًا.

12

بعد صراع طويل تمكنت أخيرًا من إصلاحه.

إليك ما يجب فعله:
من جلسة SSH قم بتشغيل الأمر التالي للعثور على معرفات الحاويات أو أسمائها:

docker ps

استخدم الأمر التالي للوصول إلى shell الخاص بحاوية docker
docker exec -it [container_id or name] bash

قم بتصدير مفتاح Cloudflare API والبريد الإلكتروني كمتغيرات بيئة. هذا للسماح لبرنامج ‘acme.sh’ بالمصادقة مع Cloudflare API لإنشاء وحذف سجلات DNS اللازمة لتحدي DNS. لقد استخدمت عنوان بريدي الإلكتروني الفعلي ومفتاح Global API من حساب Cloudflare الخاص بك.

export CF_Key="your_cloudflare_global_api_key"
export CF_Email="your_cloudflare_email_address"

غيّر الدليل إلى:

cd /shared/letsencrypt

قم بتشغيل acme.sh مع الأمر --issue، مع تحديد أنك تريد استخدام وضع dns_cf (DNS Cloudflare) للتعامل مع تحديات DNS. استبدل yourdomain.com بالنطاق الذي تريد الشهادة له.

./acme.sh --issue --dns dns_cf -d yourdomain.com -d *.yourdomain.com

بعد إنشاء الشهادة بنجاح، سيعرض البرنامج النصي الدليل الذي تم نسخه إليه. في حالتي كان:

Your cert is in: /root/.acme.sh/sprawy.info.pl_ecc/sprawy.info.pl.cer
Your cert key is in: /root/.acme.sh/sprawy.info.pl_ecc/sprawy.info.pl.key
The intermediate CA cert is in: /root/.acme.sh/sprawy.info.pl_ecc/ca.cer
And the full chain certs is there: /root/.acme.sh/sprawy.info.pl_ecc/fullchain.cer

قم بتحرير ملف discourse.conf لتحديث المسار إلى الشهادة:

nano /etc/nginx/conf.d/discourse.conf

يجب استبدال سطري ssl_certificate و ssl_certificate_key الحاليين بـ:

ssl_certificate /root/.acme.sh/sprawy.info.pl_ecc/sprawy.info.pl.cer;
ssl_certificate_key /root/.acme.sh/sprawy.info.pl_ecc/sprawy.info.pl.key;

بحيث يشير الآن إلى مواقع الشهادات الجديدة.

قم بتشغيل هذا لاختبار التكوين:

nginx -t

إذا لم تكن هناك أخطاء - قم بإعادة تحميل خادم الويب:

nginx -s reload

وهكذا!

image
image862×245 17 KB

إعجابَين (2)
13

أخبار ممتازة، أحسنتم في اكتشاف الحل. تجدر الإشارة إلى أنه مع LetsEncrypt، إذا كان لديك سلسلة من طلبات الشهادات غير الناجحة، فسيتم حظرك (لمدة 7 أيام، أعتقد). لذا، من المفيد توخي الحذر لضمان صحة هذه الطلبات.

إعجابَين (2)