IPsec بين مضيفين: أين تبدأ الحماية وأين تتوقف
يمكن لزوج من المضيفين حماية تدفقات مختارة دون بوابة. حدّد نقاط الطرفين، والسياسة التي تختار حركة المرور، والأذونات التي تبقى منفصلة.
تبدأ الحماية على زوج من المضيفين حيث ينتهي اقتران الأمان، وهذه هي الحقيقة التي يفوتها في أغلب الأحيان الحدس المتشكل من البوابات. يمكن لخادم تطبيق وخادم قاعدة بياناته أن يحميا محادثتهما مباشرة، دون أي مركّز وصول عن بعد في المسار، وتقع حدود الحماية حينها داخل كل مضيف وليس في جدار ناري. ما يمنحك إياه ذلك هو تغطية من طرف إلى طرف لتدفقات مختارة. وما لا يمنحك إياه هو قرار بشأن من يجوز له قراءة أي صف.
الحدود حيث ينتهي اقتران الأمان
يصف RFC 4301 اقترانات الأمان في وضع النقل بأنها الترتيب المستخدم عادة بين زوج من المضيفين للحماية من طرف إلى طرف. يحتفظ هذان المضيفان بالمفاتيح، ويقرر كل منهما أي من حزمه تدخل الاقتران. وتنتهي نفق البوابة في مكان آخر تماما ويصل إلى المضيف عبر مقطع داخلي إضافي، وهو حد ثقة مختلف حتى عندما تكون الحزمة مشفرة في معظم رحلتها.
المضيف إلى المضيف ووضع النقل ليسا مترادفين مع ذلك. يمكن لمضيفين أن يبنيا اقتران أمان في وضع النفق بينهما بالصحة نفسها، لذا اختر الوضع أولا ثم صف نقاط الطرفين. اكتب الاثنين في مذكرة التصميم بجوار عناوين الأقران، لأن المراجع الذي يعرف الوضع فقط سيفترض الآخر.
تقرر قاعدة سياسة الأمان الحماية، ويقرر المسار الاتجاه
يجيب جدول التوجيه عن السؤال إلى أين تذهب الحزمة. وتجيب قاعدة بيانات سياسة الأمان عن كيفية عبور الحركة المختارة لحدود الحماية، وتفعل ذلك لكل اتجاه بمحددات خاصة بها. هذا الفصل هو سبب أن مسارا عاملا إلى قاعدة البيانات لا يثبت شيئا بشأن ما إذا كان الطلب محميا، وسبب أن مفاوضة قائمة لا تثبت شيئا بشأن ما إذا كان هذا التطبيق بعينه مطابقا لها. قارن المحددات قبل أن تقارن العدادات، لأن العدادات تصف فقط التدفقات التي وصلت إلى هذا الحد.
في Linux، يطبع ip xfrm policy تلك المدخلات مع اتجاهها وأولويتها ومحددها وإجراء السماح أو الحجب أو الإيقاع، بينما يعرض ip xfrm state الاقترانات الناتجة وعداداتها. وقراءة الاثنين معا هي الطريقة التي تجد بها التدفق الذي تجاوز النفق بصمت لأن مدخل سماح أوسع طابق أولا.
ترتيب الأولوية جزء من السياسة وليس تفصيلا تنفيذيا. المدخل الضيق الذي ينبغي أن يحمي منفذ قاعدة البيانات يخسر أمام مدخل أوسع بأولوية أعلى، ويبدو الفشل كأن السياسة لم تُستشَر قط.
يغطي وضع النقل الطبقة التالية، لا ترويسة IP
| Transport mode | Tunnel mode | |
|---|---|---|
| Original IP header | kept for routing the flow | replaced by an outer header |
| What ESP protects | the carried next-layer payload | the whole inner IP packet |
| Where it terminates | commonly the two hosts | gateway pair, or a host pair |
في وضع النقل تقع ترويسة ESP بين ترويسة IP والحمولة، وتبقى حقول العنوان في تلك الترويسة مرئية لكل جهاز على المسار. وهذا جيد عندما لا تكون العناوين هي السر وتكون الحمولة هي السر. وهو الخيار الخاطئ إذا كنت تحتاج أيضا إلى إخفاء الطوبولوجيا الداخلية، لأن وضع النفق وحده يلف الترويسة الأصلية داخل ترويسة جديدة.
يمكن لكلا الوضعين أن يحملا عدة بروتوكولات من الطبقة التالية، وسيحمي ESP ما تطابقه المحددات بدلا من كل ما يرسله المضيف.
الاختيار أضيق من الاتصال
يمكن لاقتران واحد أن يحمل تدفقات عدة، لكن فقط تلك التي تختارها السياسة. سجّل هويات الأقران، وعناوين المصدر والوجهة، والبروتوكول، ونطاق الخدمة للعلاقة التي تقصدها، ثم قرر بصورة منفصلة ما إذا كان يجوز للحركة غير المطابقة أن تمر علنا، أو يجب حمايتها، أو يجب إسقاطها عندما لا يكون الاقتران متاحا. وهذا القرار الأخير هو الذي ينتج المفاجآت، لأن قاعدة تشترط الحماية لمصدر خاطئ يمكن أن تحجب وصولك الإداري بفعالية تحجب بها متطفلا.
احتفظ بمسار خارج النطاق معتمد أثناء تغيير التطبيق، واختبره قبل أن تحتاج إليه بدلا من بعد أن يصبح المضيفان غير قابلين للوصول.
هوية الجهاز ليست إذن التطبيق
يصادق IPsec على قرين مُعدّ ويحمي حزما مختارة. وهو لا يقرر أي سجل في قاعدة البيانات يجوز لشخص تحريره، ولا يحوّل هوية خادم موثوقة إلى منح كل امتياز تطبيقي. تبقى حسابات التطبيق وأدواره وتخويله في مكانها تماما، ويحتفظ شرط TLS على مستوى التطبيق بغرضه الخاص حتى عندما يكون مسار الشبكة محميا بالفعل.
اقبل التصميم بعملية واحدة من المصدر المقصود وعملية واحدة يجب رفضها، وأدرج ما يحدث عندما يتعذر إنشاء الاقتران المطلوب. يخبرك اختبار وصول عادي بأن الحزم تتحرك؛ لكنه لا يخبرك بأنها تحركت تحت السياسة التي كتبتها.