وكيل HTTP أو نفق SSH أو VPN: اختر الطبقة المناسبة

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

قرر من حقيقتين: أي البروتوكولات يجب أن تعبر، ومن يستطيع تحليل الأسماء المعنية. وكل ما عدا ذلك تفضيل.

الوكيل ينقل فقط ما يفهمه

وكيل الويب يحلل البروتوكول الذي بني من أجله. يسلمه العميل طلبا فيسلم ذلك الطلب إلى الأمام، لذا لا يشارك تطبيق بلا إعداد وكيل إطلاقا. بالنسبة إلى HTTPS يحتاج العميل قناة معتمة، يوفرها الوكيل عبر CONNECT بدلا من قراءة الطلب.

فتح SSH الديناميكي يفتح منفذا محليا يتحدث SOCKS، وذلك المنفذ يمرر تدفق TCP إلى أي وجهة يسميها العميل. البروتوكولات المبنية على TCP تعمل عبره عادة. أما UDP فلا، إلا إذا أضافت أداة دعما صريحا. الفتح المحلي أضيق من ذلك: منفذ محلي واحد مربوط بمضيف ومنفذ ثابتين، يخدم خدمة معروفة واحدة ولا شيء غيرها.

ssh -D 1080 user@bastion
ssh -L 8443:fileserver.internal:443 user@bastion

VPN ينقل الحزم. كل ما يوجهه العميل إلى النفق يعبره، بما في ذلك UDP وICMP، ولهذا يناسب متطلب شبكة لا اتصالا واحدا.

لا بد أن يحلل أحد ما الاسم

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

يوضح curl الفصل بوضوح: علم واحد يمرر اسم المضيف إلى الوكيل، وآخر يحلله محليا أولا. مع التحليل المحلي يفشل اسم داخلي فقط قبل لمس أي نفق، ويحمل الخطأ الوكيل مسؤولية ما كان في الحقيقة قرار DNS.

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

حين تسمح الشبكة بمخرج واحد فقط

شبكات مؤسسية كثيرة لا تسمح بالاتصالات الصادرة إلا عبر وكيل ويب موثق. OpenVPN وSSH يمكن جعلهما يعملان هناك، الأول بنفق نقلها الخاص عبر الوكيل والثاني عبر أمر وكيل يشغل مساعد CONNECT صغيرا.

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

تسلسل الوسطاء سؤال مختلف عن اختيار طبقة. إضافة وكيل ثان أو Tor تغير من يراقب ماذا، وموقعك في السلسلة يحدد أي قفزة ترى النص المشفر.

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

العنوان المزور ليس أحد الخيارات

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

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

قرر حسب البروتوكولات والأسماء

اختر وكيلا عندما يحتاج عميل ويب واحد إلى خدمة ويب واحدة ولديه إعدادات وكيل. اختر نفق SSH عندما تكفي حفنة من خدمات TCP معروفة ويكون وصول SSH موجودا أصلا. اختر VPN عندما تكون عدة تطبيقات أو حركة غير TCP أو DNS خاصة أو مسار قابل لإعادة الاستخدام جزءا من المتطلب.

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