المصادقة الأساسية عبر HTTPS مقابل IPsec: ما الذي يحميه كل منهما

افتح أدوات المطور، وحمّل التطبيق الداخلي، وراقب طلبًا واحدًا يمر بأربع نقاط فحص قبل أن تُعرض الصفحة. أولًا يُحلّ الاسم، ثم يُفتح اتصال TCP، ثم يثبت مصافحة TLS هوية الخادم، وبعد ذلك فقط يسأل التطبيق من أنت. تعامل مع هذه أحداثًا منفصلة، لأن كل واحد منها يفشل بدليل مختلف ويملكه فريق مختلف. معظم الالتباس في الحوادث يأتي من قراءة 401 كمشكلة نفق، أو مشكلة نفق ككلمة مرور خاطئة.

نقطة الفحص الأولى: هل هذا هو الخادم الذي أردت التحدث إليه

تجيب مصافحة TLS عن ذلك السؤال قبل إرسال أي بيانات اعتماد. يتحقق عميلك من سلسلة الشهادات مقابل مخزن ثقة، ويتأكد من أن الاسم في الشهادة يطابق المضيف الذي كتبته. إذا فشل ذلك، يعرض المتصفح خطأ شهادة ولا يرسل ترويسة Authorization إطلاقًا. لذا فإن مطالبة كلمة المرور ليست دليلًا على أن الخادم أصلي؛ بل هي دليل على أن التطبيق قد أجاب.

هنا تظهر الحدود الأولى. يحمي TLS الاتصال حتى نقطة إنهائه. إذا أنهى موازن التحميل TLS ومرّر HTTP عاديًا إلى التطبيق، فإن المقطع المشفّر ينتهي عند الموازن، وتُحمى بيانات الاعتماد على القفزة الأولى فقط.

نقطة الفحص الثانية: ما الذي يسافر فعليًا في تبادل 401

ترسل مصادقة HTTP Basic معرّف المستخدم وكلمة المرور في ترويسة، مُرمّزة بـ Base64 كما هو موصوف في RFC 7617. Authorization: Basic dXNlcjpwYXNz هو الشكل؛ الترميز قابل للعكس من قبل أي شخص يمكنه قراءة الطلب، لذا تأتي كل السرية من النقل الذي تحته. يعرض curl -v تحدّي WWW-Authenticate: Basic والترويسة التي ترسلها في الرد.

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

أين يقع نفق IPsec في ذلك المسار

امش الآن للخارج من المتصفح. نفق IPsec بين بوابة وبوابة يحمي حركة مختارة بين بوابتي أمان، وليس بين حاسوبك المحمول وعملية التطبيق. يلفّ ESP في وضع النفق الحزمة الأصلية، وتشفّرها البوابتان وتوثّقانها، وتبقى العناوين الداخلية كي يتمكن الجانب البعيد من توجيه الطلب إلى التطبيق.

الاختيار هو الجزء الذي يربك الناس. تستخدم الأنفاق القائمة على السياسات محدّدات حركة، تُعبَّر عنها غالبًا كقوائم تحكم بالوصول، لتقرر أي الحزم تدخل النفق. أما الأنفاق القائمة على المسارات فتستخدم واجهة افتراضية وجدول التوجيه بدلًا من ذلك. على Linux يعرض ip xfrm policy المحدّدات ويعرض ip xfrm state ارتباطات الأمان القائمة؛ وعلى جهاز جدار ناري يكون المكافئ جدول SA الخاص بالنفق مع متعقّب حزم.

يستحق العاقبة أن تُقال بوضوح. يمكن لحزمة أن تبقى داخل نفق سليم تمامًا وأن تحمل مع ذلك طلب HTTPS يرفضه التطبيق، ويمكن أن تصل بيانات اعتماد صحيحة عبر مسار بلا نفق إطلاقًا إن سمح التوجيه بذلك.

اقرأ الفشل عند الطبقة التي أبلغت عنه

تعني 401 أن التطبيق لم يقبل بيانات الاعتماد. وتعني 403 أنه قبل الهوية ورفض العملية. ويعني خطأ TLS أن العميل لم يقبل الخادم. ويعني غياب المسار أو عدم تطابق السياسة أن الحزمة لم تصل قط إلى البوابة البعيدة. أربعة أعطال مختلفة، وأربعة مالكين مختلفين، ولا يُشخَّص أي منها بالتحديق في نموذج تسجيل الدخول.

استخدم الدليل الذي تنتجه كل طبقة: لوحة الشبكة في المتصفح للحالة والترويسات، وopenssl s_client -connect host:443 لسلسلة الشهادات، وعدّادات SA وسجلات البوابة لحركة النفق، وسجل التطبيق لقرار الحساب. وعندما تبلغ طبقتان عن أخطاء في الوقت نفسه، أصلح الأدنى أولًا، لأن نفقًا ميتًا يستطيع أن يحجب فشل مصادقة بسهولة والعكس صحيح.

ارسم خدمة واحدة من طرف إلى طرف

اكتب خمسة أسطر للخدمة التي تستكشفها: أي الأقران يربط النفق، وأي الشبكات الفرعية والمنافذ تسمح بها المحدّدات، وأين ينتهي TLS وأي هوية تؤكدها الشهادة، وأي حساب تطبيق ودور يُستخدمان، وأين تسجّل كل طبقة. أبقها في صفحة واحدة، لأن الغرض من الخريطة هو إظهار أين تنتهي مسؤولية طبقة وتبدأ التالية.

ثم اختبر حالة سلبية واحدة لكل طبقة. استخدم كلمة مرور خاطئة وتأكد أنك تحصل على 401 لا على مهلة. اتصل من شبكة فرعية خارج المحدّدات وتأكد أن الحزمة لا تمر عبر النفق. قدّم شهادة باسم خاطئ وتأكد أن العميل يرفض قبل إرسال بيانات الاعتماد. تلك النتائج الثلاث تخبرك عن التصميم أكثر من أي مخطط للصناديق.

أخيرًا، قرّر بتأنٍّ أي حماية تحتاجها كل علاقة. المصادقة الأساسية عبر TLS مناسبة لأداة داخلية صغيرة خلف بوابة؛ وهي ليست بديلًا عن التخويل لكل مستخدم ولا عن حماية الحركة بعد نقطة نهاية TLS. النفق يحمي المسار، والشهادة تحمي القفزة، و401 تحمي الحساب، ووحدها الأخيرة تعرف من أنت.