لماذا يحتاج عنوان URL إلى مدخل على المنفذ 80 أو 443، وليس 45000
يختار المتصفح المنفذ 80 أو 443 من المخطط، لا المنفذ المرتفع الذي يمنحك إياه المزود. تتبّع مسار الدخول والأصل الذي يتركه لك كل خيار نشر.
اكتب اسم مضيف في متصفح، وسيحدد المخطط منفذ الوجهة: 80 لـ http و443 لـ https. لا شيء في إجابة DNS يتجاوز ذلك، ولا يمكن لأي قاعدة إعادة توجيه على جهازك أن تخترع مستمعًا عند حافة المزود. عندما يمنحك مزود VPN منفذًا عامًا مرتفعًا مثل 45000، يعمل عنوان URL الصريح ولا يعمل العنوان النظيف. الفجوة تقع عند نقطة الدخول، لا داخل التطبيق.
تتبّع المسار من المتصفح إلى العملية مرة واحدة، وستتوقف خيارات النشر الثلاثة عن الظهور كلغز.
انظر أين يذهب الطلب فعلًا
يحل المتصفح الاسم إلى عنوان، ثم يتصل بذلك العنوان على المنفذ الافتراضي للمخطط ما لم يذكر عنوان URL منفذًا آخر. تقرر حافة مزودك ما يحدث للاتصال الوارد. إذا كان جدول إعادة التوجيه لديها يربط 45000 فقط بعنوانك الداخلي، فلن يجد اتصال بالمنفذ 80 إلى أين يذهب، ويُرفض أو يُسقط قبل أن يشارك جهازك.
يحدث هذا الرفض عند الحافة، ولهذا لا تُظهر سجلات تطبيقك شيئًا على الإطلاق. غياب السجلات دليل على أين توقف الحزمة، لا دليل على أن التطبيق معطل.
لماذا لا تستطيع قاعدة محلية إصلاح الحافة
لا تستطيع قاعدة إعادة توجيه أو DNAT على مضيف التطبيق إلا العمل على الحزم التي وصلت بالفعل. الحزم المرسلة إلى المنفذ 80 عند المزود لا تصل أبدًا، لذلك لا تُقيَّم القاعدة أبدًا. هذه هي الساعة الأكثر إهدارًا في المشكلة كلها.
لا يستطيع DNS حمل المنفذ أيضًا. يحدد مواصفة HTTP القيم الافتراضية للمخطط، ويعيد سجل A أو AAAA عنوانًا بينما يعيد CNAME اسمًا آخر. لا يزال المتصفح يلصق منفذ المخطط، لذلك لا يغيّر الوجهة سوى منفذ صريح في عنوان URL.
الخيار الأول: الإبقاء على المنفذ الصريح
غالبًا ما تكون الإجابة الصحيحة هي الخيار غير اللامع. انشر عنوان URL الكامل مع المنفذ، وأنهِ TLS على مدخل يدعم ذلك، وتأكد من أن كل رابط مُنشأ يحتفظ بالأصل نفسه. لجمهور صغير ومضبوط، هذا كافٍ، ولا يكلف شيئًا يتجاوز رقم منفذ ظاهر.
افحص عمليات إعادة التوجيه ونطاق ملفات تعريف الارتباط أثناء وجودك هناك، لأن الواجهة الخلفية التي تكتب اسم المضيف الخاص بها في رأس Location تلغي الترتيب.
الخيار الثاني: الحصول على مدخل حقيقي على المنفذ الافتراضي
بعض المزودين وترتيبات الاستضافة يمررون 80 و443 على عنوان مشترك أو مخصص كخدمة موثقة. اسأل عما هو مشمول فعلًا بدلًا من افتراض أن عنوان خروج عام يعني منافذ واردة عشوائية. عنوان صادر مخصص لا يقول شيئًا عن إعادة التوجيه الواردة.
أكّد الملكية والتوافر كتابيًا، بما في ذلك ما يحدث للمدخل عندما يعيد النفق الاتصال بعنوان مختلف. المدخل الذي يتحرك مع النفق ينتج انقطاعات تبدو كأعطال DNS.
الخيار الثالث: وضع واجهة أمامية في المقدمة
يمكن للوكيل العكسي على عنوان يمكن الوصول إليه أن يستمع على 443 وينهي TLS، ويفتح اتصالًا منفصلًا بالواجهة الخلفية عبر VPN. يرى الزوار اسم الواجهة الأمامية ومنفذها الافتراضي، بينما تتحدث الواجهة الأمامية إلى منفذ الواجهة الخلفية المرتفع نيابة عنك. هذا يعمل لأنه يغيّر البنية بدلًا من محاربة نقطة الدخول. ثم لا تحتاج الواجهة الخلفية إلى أي منفذ وارد على الإنترنت العام.
يغيّر هذا أيضًا ما تشغّله. تملك الواجهة الأمامية TLS العام وسياسة الوصول والسجلات والتوافر، وعليها أن تقصر اختيار الواجهة الخلفية على الخدمة المقصودة. إذا استخدم الانتقال من الواجهة الأمامية إلى الخلفية HTTPS، فأبقِ التحقق من الشهادة على ذلك الانتقال.
احتفظ بأصل واحد
يشكل اسم المضيف العام للواجهة الأمامية ومخططها ومنفذها الأصل الذي يستخدمه الزوار، لذا اضبط عنوان URL الخارجي للتطبيق وعمليات إعادة التوجيه وملفات تعريف الارتباط على ذلك الأصل. أرسل المضيف الأصلي والمخطط المعاد توجيهه إذا كان التطبيق يبني روابط مطلقة. الاستجابة التي تعيد المستخدمين إلى اسم خاص أو منفذ مرتفع تلغي المدخل النظيف الذي بنيته للتو.
ثم قرر مع وضع الجمهور في الاعتبار. يمكن لعنوان URL قصير أن يبرر واجهة أمامية مُدارة، ولا يستحق أن تحوّل عن غير قصد خدمة خاصة عبر VPN فقط إلى خدمة عامة.