TLS يعمل داخل قناة التحكم، لا داخل النفق بأكمله

إن قراءة كلمة TLS في وصف شبكة VPN والاستنتاج بأن وكيل ويب سيفهم هذا المرور اختصار شائع. داخل هذا البروتوكول يتبادل الطرفان حزمهما الخاصة، ويعمل TLS كجزء من قناة واحدة ضمن ذلك التبادل. أما الحمولة التي تهم المستخدم فتسير في صيغة رسائل مختلفة، ولهذا لا تتطابقان أبداً مع جلسة HTTPS عادية.

الغلاف يأتي أولاً

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

outer transport (UDP datagram or TCP stream)
  -> OpenVPN header (opcode, key id, length where needed)
    -> control message (reliability wrapper, TLS exchange)
    -> data message (protected inner packet)

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

طبقة الموثوقية تنتمي إلى البروتوكول

تحتاج رسائل التحكم إلى تسليم مرتب ومُقرّ به، والبروتوكول يوفر ذلك بنفسه عبر الإقرارات وإعادة الإرسال. وقد يصل الإقرار كرسالة مستقلة أو يسافر مع رسالة تحكم أخرى، ما يجعل الآثار تبدو غير منتظمة لمن يتوقع تبادلاً واحداً نظيفاً.

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

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

حزم البيانات تستخدم صيغة مختلفة

بعد وجود الجلسة، تصل الحمولة المفيدة كرسائل بيانات تحمل حزم IP داخلية أو إطارات Ethernet. وهي محمية بمفاتيحها الخاصة ومعالجتها الخاصة، وليست سجلات تطبيق TLS بأي معنى تقبله مكتبة TLS.

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

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

لماذا لا يستطيع وكيل HTTPS المساعدة

الوكيل الذي ينهي TLS يتوقع دفق سجلات TLS ثم بروتوكول تطبيق داخله. قناة التحكم في هذا البروتوكول تُحمل داخل تأطيرها الخاص مع طبقة موثوقية حولها، لذا يقرأ الوكيل المنهي ذلك التأطير كمدخل تالف.

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

قراءة الأثر بشكل صحيح

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

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