الواجهة الأمامية للنطاقات ليست شبكة VPN: اسمان وطلب واحد
اسمان في طلب HTTPS واحد لا يشكلان نفقًا. تعتمد الواجهة الأمامية على قواعد التوجيه لدى المزوّد؛ أما شبكة VPN فتختار الحزم التي تسلك المسار. ارسمهما منفصلين.
تُصنَّف التقنيتان معًا لأن كلتيهما تتضمن وسيطًا وكلتاهما تبدو كإخفاء. لكنهما تعملان على كائنين مختلفين. الواجهة الأمامية للنطاقات تتعلق بالاسم الذي يظهر في أي طبقة من طلب HTTPS واحد. أما شبكة VPN فتتعلق بالحزم التي تسلك مسارًا معينًا نحو نظير. ووصف الواجهة الأمامية بأنها نوع من الشبكات الافتراضية يؤدي إلى تصاميم لا يمكن أن تعمل، وإلى مراجعات تطرح السؤال الخطأ.
اسمان وطبقتان
يمكن لاتصال TLS أن يحمل اسم خادم في مصافحته. وبعد أن يصبح الاتصال قائمًا، يحدد طلب HTTP السلطة التي يريدها، وذلك عادةً في ترويسة Host. هذان حقلان يُقرآن في لحظتين مختلفتين بواسطة قطعتين مختلفتين من البرمجيات.
| Layer | What carries the name | Who reads it |
|---|---|---|
| TLS handshake | Server name indication | The TLS terminator in front of the service |
| HTTP request | Authority or Host header | The routing layer that picks a backend |
| Network path | Destination address and port | Routers, and the VPN peer if one is in use |
تستغل الواجهة الأمامية للنطاقات فرقًا بين الأولين بحيث تقبل خدمة الواجهة الأمامية الاتصال ثم توجّه الطلب إلى مكان آخر. وهي لا تعمل إلا حيث تكون تلك الخدمة مستعدة لتوجيهه، وهذه مسألة سياسة مزوّد لا حيلة بروتوكول.
الواجهة الأمامية تعتمد على المزوّد لا على التقنية
على سبيل المثال المحدود، فإن الأسئلة الشائعة لـ Front Door لدى Azure توثّق وسائل الحماية من الواجهة الأمامية للنطاقات. وهي تصف عدم تطابق مسموحًا به للنطاقات داخل الاشتراك نفسه والمسارات المهيّأة، واستجابة 421 Misdirected Request عندما تمنع حماية عدم التطابق أي طلب.
هذه السياسة الموثّقة الواحدة تبطل الشعارين معًا. فليس كل زوج من الأسماء المختلفة يعمل، وليس كل عدم تطابق ممنوعًا أيضًا. وللخدمات الأخرى فحوصها الخاصة ومتطلبات نشرها الخاصة ورموز أخطائها الخاصة.
وهي ليست أيضًا تعليمات لتجاوز قيود شبكة أخرى. فقراءة قواعد التوجيه لدى مزوّد لفهم ما يسمح به هي عمل معماري؛ أما التعامل مع تلك القواعد كوصفة تجاوز فهو نشاط آخر بعواقب أخرى. أبقِ هذين النشاطين منفصلين في الوثيقة التي تكتبها. فالثاني هو ما يجعل التصميم يُرفض في المراجعة.
ما تختاره شبكة VPN فعليًا
في شبكة VPN، يختار التوجيه وسياسة المنصة حركة المرور الداخلية لنفق نحو نظير. وبحسب الترتيب، يمكن أن يغطي ذلك عدة تطبيقات أو مجموعة فرعية محددة، ويمكن أن يحمل بروتوكولات لا يوجد لها طلب HTTP على الإطلاق.
الواجهة الأمامية لا تفعل شيئًا من ذلك. فترتيب طلب HTTPS واحد عبر خدمة واجهة أمامية لا يثبّت مسارًا لشبكة خاصة، ولا يحمل تطبيقات UDP عشوائية، ولا يجعل كل برنامج على الجهاز يستخدم الخدمة. وإذا كنت تحتاج إلى تلك التغطية، فأنت تحتاج إلى وكيل أو نفق، لا إلى حيلة تسمية.
ولهذا يُخلط بين الاثنين في المراجعة: فكلاهما يوصف بأنه وسيط، وكلاهما يظهر في وثائق عن الوصول. لكن الواجهة التي يقدمها كل منهما مختلفة تمامًا، وواحدة فقط منهما مسار شبكة.
الرؤية ليست ثنائية
وليست المقارنة مجرد مخفي مقابل مرئي. فاستعلامات DNS وعناوين الوجهة وسمات المصافحة وأحجام الحزم والتوقيت كلها تبقى قابلة للملاحظة لمن هو في موضع يتيح له رؤيتها، وما يتعلمه ذلك المراقب يعتمد على موقعه.
بيانات التطبيق مرئية أيضًا عند نقاط النهاية التي تُنهيها. فخدمة الواجهة الأمامية التي توجّه طلبك هي إحدى تلك النقاط، ونظير VPN نقطة أخرى. ولا يجعل أي من الترتيبين المحتوى معتمًا على الطرف الذي عليه قراءته ليخدمك.
ارسم المربعات الثلاثة
من أجل مراجعة معمارية، ارسم نقطة نهاية TLS وخدمة توجيه HTTP والتطبيق النهائي كمربعات ثلاثة منفصلة، ثم ارسم أي نظير VPN في مكان آخر مرة أخرى. فالمكان الذي يختار وجهة ويب والمكان الذي ينقل حزم الشبكة الخاصة ليسا بالضرورة النظام نفسه، وعادةً لا يكونان كذلك.
وبعد أن تصبح المربعات منفصلة، تصبح الأسئلة قابلة للإجابة: أي الأسماء يقبلها هذا المزوّد، وأي البروتوكولات تحتاج إلى نقل، وأي طرف يمكنه رؤية ماذا. أما المخطط الذي يدمجها فينتج تصميمًا لا يستطيع أحد تنفيذه ومراجعة تتجادل حول المصطلحات.