TLS الأصلي أو إعادة توجيه SSH أو VPN لخدمة سحابية واحدة

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

ابدأ بالخدمة، لا بالشبكة

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

خذ واجهة برمجة داخلية صغيرة تقدّم HTTPS بالفعل على المنفذ 8443 بشهادة لـ api.internal.example. يُظهر ss -ltnp على المضيف ما ترتبط به، ويُظهر openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example ما إذا كانت الشهادة صالحة للاسم الذي سيستخدمه العميل فعليًا. إذا كان كلاهما سليمًا، يمكن للخدمة حماية تدفقها بنفسها ويكون العمل المتبقي هو الوصول فقط. وهذه مشكلة أصغر بكثير من بناء شبكة.

الخطوة 1: هل تحمي الخدمة نفسها؟

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

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

الخطوة 2: هل منفذ TCP واحد هو المتطلب كله؟

عندما يكون المتطلب حقًا منفذ TCP واحدًا، فإن إعادة التوجيه هي أصغر ما ينجح. تعيد إعادة التوجيه المحلية عبر SSH حمل ذلك المنفذ عبر اتصال موثّق موجود بالفعل.

الشكل هو ssh -N -L 8443:127.0.0.1:8443 [email protected]، والتفصيل المهم هو عنوان الهدف: يُحلّ 127.0.0.1 على الجانب البعيد، لذا يُفتح الاتصال بالخدمة من الباستيون لا من حاسوبك المحمول. اربط المستمع المحلي بشكل ضيق كـ -L 127.0.0.1:8443:... حتى لا تنشر الخدمة على شبكتك المحلية عن طريق الخطأ. على جانب الخادم، قيّد ما يجوز للحساب إعادة توجيهه بدلًا من الثقة بسلوك العميل. الإعدادات الثلاثة التي تحوّل مرحّلًا عامًا إلى قناة محددة هي PermitOpen و AllowTcpForwarding local و GatewayPorts no كافتراضي.

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

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

الخطوة 3: هل التوجيه هو المتطلب الفعلي؟

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

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

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

ما تملكه بعد ذلك

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

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