أود استخدام Discourse في إعداد خاص: سيكون خادم الويب متاحًا فقط لعدد محدود من المستخدمين المعروفين ضمن شبكة VPN خاصة. ستكون عنوان IP للخادم شيئًا مثل 10.0.0.1، ومن الواضح أنني لا يمكنني الحصول على اسم نطاق عام صالح لذلك.
لقد قرأت أنه يُوصى بشدة بإعداد نقل البريد الإلكتروني بشكل صحيح. كما قرأت أنه يمكن على الأقل إكمال إنشاء حساب المسؤول باستخدام بعض الحيل دون الحاجة إلى البريد الإلكتروني.
أتساءل: ما هي أفضل طريقة للمضي قدمًا؟
أ) إعداد Discourse بالكامل دون استخدام البريد الإلكتروني. هل سيعمل ذلك؟ أعتقد أنني سأحتاج إلى اتباع إجراء يدوي على الأقل للحصول على تنشيط كل حساب، لكن هذا مقبول بالنسبة لعدد المستخدمين المحدود الذي أتوقعه. هل سيعمل ذلك؟ وما هي القيود الناتجة عن عدم عمل نقل البريد الإلكتروني؟ بالطبع، لا يمكنني إرسال إشعارات عبر البريد الإلكتروني (وهو عيب بسيط بالنسبة لي) — هل هذا كل شيء؟
ب) بينما يستخدم الخادم عنوان IP خاص، قد يكون لدي عنوان عام مخصص للبريد الإلكتروني فقط. أتوقع أن يكون كل شيء محسّنًا (أفضل ما يمكن) للإعداد السهل، لذا عند اتباع أدلة التثبيت، سأدخل عنوان الخادم مرة واحدة فقط، والذي يُستخدم على الأرجح لإعادة التوجيه عبر HTTP وكذلك لبروتوكول SMTP. هل من السهل التمييز بينهما؟ هل يمكنني إعداد خادم بعنوان IP خاص ونطاق غير مطابق يُستخدم فقط للبريد بسهولة؟
يجب أن أوضح أنني لم أكتسب بعد أي خبرة مع Discourse. أنا مستعد للبحث عن المعلومات بنفسي عندما أواجه مشاكل فعلية. لكنني أرى خيارًا جوهريًا يجب اتخاذه هنا: أي المسارين (أ أو ب) يجب أن أختار؟ وسيكون من الرائع الحصول على بعض النصائح لتجنب السير في المسار الخاطئ أولاً.
شكرًا لمحاولتكم المساعدة. أعتقد أنني بحاجة إلى توضيح الأمر أكثر قليلاً.
أولاً، يجب أن أشرح الأجزاء التي أعرفها جيدًا وتلك التي لا أعرفها؛). فأنا أفهم الجانب منخفض المستوى (low-level) جيدًا جدًا، مثل عناوين IP و TCP وما إلى ذلك. لكنني لا أملك أي خبرة في الأمور التي تقوم بها تطبيقات الويب المعقدة. وكذلك فيما يتعلق بالبريد الإلكتروني: كيف يتم مصادقة مرسل البريد الإلكتروني؟ وكيف يتم التحقق من أنه لا يرسل رسائل بريد غير مصرح بها (spam)؟ (لا أتوقع منكم شرح كل ذلك لي، بل فقط توضيح أسئلتي..)
لا أملك هنا بنية تحتية كاملة لشبكة VPN خاصة بالشركات، كل ما أملكه حاليًا هو شبكة فرعية خاصة (subnet) لـ VPN وقواعد على مستوى عناوين IP.
الإعداد كالتالي: الخادم لديه نطاق (domain) يمكن الوصول إليه علنًا، لكن جميع المنافذ مغلقة ما عدا نقطة دخول VPN. العملاء الذين يتصلون بـ VPN يحصلون على عنوان من نوع 10.0.x.x. ويمكن الوصول إلى الخادم عبر 10.0.0.1:80.
فهمي (وأعتقد أنني مخطئ هنا) هو أن الخادم يتوقع أن يكون قابلاً للوصول عبر نطاقه الخاص.
لنفترض أن لدي النطاق xyz.com الذي يحل إلى العنوان العام 8.7.6.5. يستخدم العملاء هذا النطاق/العنوان فقط لإنشاء النفق (tunnel). وبمجرد إعداد النفق، يتصل متصفحاتهم بـ 10.0.0.1.
وكما قلت، ليس لدي خبرة مع Discourse. ما أتوقع أن يستخدمه Discourse لنطاقه الخاص هو عمليات إعادة التوجيه. على سبيل المثال: توجيه العملاء الجدد الذين يفتحون 10.0.0.1 إلى 10.0.0.1/login.php. (أو ما شابه، كمثال فقط). إذا قام Discourse بإعادة توجيههم إلى .xyz Domain Names | Join Generation XYZ بدلاً من ذلك، فسيضيعون لأن الخادم غير قابل للوصول من خارج شبكة VPN. هذا هو نوع المشكلة المتوقعة التي أفترض أنه يجب فيها تكوين عنوان داخلي.
عندما يتعلق الأمر بالبريد، أحتاج إلى الاتصال بخوادم بريد خارجية. الإنترنت العام متاح في أي مرحلة! مع ذلك، لا أعرف الكثير عن هذا الموضوع. أنا فقط أتوقع أن محاولة الاتصال بخادم بريد عام بقول “مرحبًا، أنا 10.0.0.1، يرجى إرسال بعض الرسائل نيابة عني” لن تنجح لأنني أستخدم عنوان IP خاص. هنا أفترض أنني بحاجة إلى عنوان عام.
بفرض تفاؤلي من قراءتي لإجاباتكم، أعتقد أن النطاق المكون لا يُستخدم لجلسات HTTP الخاصة بالعملاء. إذا كان الخادم قابلاً للوصول عبر عنوان IP خاص، واتصلت بذلك العنوان، فإن جميع الروابط وإعادة التوجيه المرجعية تكون نسبية، وبالتالي لن يتم إعادة توجيه المستخدم إلى النطاق الذي يتوقع الخادم الاتصال به. يمكنني ببساطة تكوين xyz.com كنطاق، مع ذلك فتح Discourse في المتصفح عبر 10.0.0.1، دون أن يتم التوجيه إلى عناوين xyz.com (غير العاملة).
أتمنى أن يكون سؤالي واضحًا إلى حد ما. آسف على هذا الارتباك!
أوه، ولا يُشترط استخدام HTTPS. بل أفضل عدم استخدامه؛ فأنا داخل نفقي، ولا يحتاج المستخدمون إلى فصل آمن. أود تجنب كل هذه المشاكل المتعلقة بالشهادات (certificates) وتطابق أسماء المضيفين.
يعتمد ذلك على خادم البريد الإلكتروني. لنفترض أنك ستستخدم خدمة بريد مثل MailGun أو SendGrid وما إلى ذلك. عادةً ما تقوم هذه الخدمات بالمصادقة عبر واجهة برمجة تطبيقات (API) مثل عنوان URL بالإضافة إلى اسم المستخدم وكلمة المرور.
هنا، وبما أن الخادم يمكنه الوصول إلى عناوين IP خارجية (مع تصفية الواردات فقط)، فلا ينبغي أن تواجه مشكلة في الاتصال بخدمة البريد.
خاصة إذا كان المجال يحل إلى عنوان IP الصحيح.
لن تحتاج حتى إلى فتح المنافذ للتثبيت. لأنه يمكنك الوصول إلى النطاق example.com عبر الشبكة الخاصة الافتراضية (VPN) إذا كان النطاق يشير إلى عنوان IP الخاص عند استخدام نفق VPN.
لست متأكدًا تمامًا مما إذا كان Discourse سيستخدم عناوين URL نسبية فقط؛ فمن المؤكد تقريبًا أنه لن يفعل ذلك. ولكن يمكنك تغيير سجلات DNS في النطاق بحيث يكون لديك سجلان من نوع A: الأول يشير إلى عنوان 10.0.0.1، والثاني يشير إلى العنوان العام 8.7.6.5. قد يكون هذا الأمر محيرًا أحيانًا عند حل العناوين وتخزينها مؤقتًا وما شابه، لكن يمكنك تجربته.
بالنسبة لخادم ويب يعمل داخل الشبكة الخاصة الافتراضية (VPN)، يجب أن يعمل خادم الشبكة الخاصة الافتراضية أيضًا كخادم أسماء نطاقات (DNS). يجب أن يحل خادم أسماء النطاقات الداخلي نفس النطاق إلى عنوان IP داخلي، بينما يتم حله علنًا إلى عنوان IP خارجي. وينبغي أن أتوقف عن استخدام عنوان IP للخادم في أي مكان، ودع خادم أسماء النطاقات يتولى هذه التعقيدات. حاليًا، تعمل شبكتي الخاصة الافتراضية فقط على مستوى عنوان IP، ولم أكن على دراية بهذه التفاصيل حتى الآن.
العيوب: قد أفسد موقع الويب الخاص بجميع المستخدمين.
يمكنني أيضًا تشغيل خادم الويب على منفذ عام، والسماح لبروتوكول SSL بتوفير الحماية.
العيوب: سأكون معرضًا لكل شرور العالم الحقيقي.