قبل استبدال IPsec بـ Shadowsocks، اكتب المهام التي ستفقدها

ثلاث خدمات ونفق واحد: تطبيق ويب وقاعدة بيانات ومشاركة ملفات. يقترح أحدهم استبدال IPsec بـ Shadowsocks لأنه أبسط في التشغيل. النقاش حول التشفير الذي يليه يفوّت النقطة، لأن النفق يؤدي عدة مهام في وقت واحد وواحدة فقط منها تتعلق بالشفرة. اكتب هذه المهام قبل مقارنة المنتجات. القائمة قصيرة، وأي بند فيها قد يُبطل الاستبدال.

ابدأ بكيفية التقاط الحركة

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

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

سمِّ كل وجهة وبروتوكول

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

أضف الحالات التي تكسر التصاميم المرتّبة: DNS الداخلي، والتطبيقات التي تتجاهل إعدادات الوكيل، وأي تدفق يجب أن يبدأ من الخادم نحو العميل. كل واحد منها يحتاج ترتيباً صريحاً، لا افتراضاً.

التشفير ليس تفويضاً

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

ضع إعداد IPsec الحالي أمام المعيار نفسه. اسمه لا يثبت أن قواعده صحيحة، ومقارنة نسخة مصقولة من تصميم بنسخة غامضة من الآخر لا تحسم شيئاً.

اسرد الضوابط الموجودة اليوم على الجانبين، ثم احكم أي الفجوات يمكنك التعايش معها.

عُدّ العمل التشغيلي

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

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

القرار ليس أي منتج يبدو أكثر أماناً. بل أي تصميم ينجز المهام المدرجة بضوابط سيتولى الفريق صيانتها فعلاً.