أفضل الممارسات لاتصالات IPsec

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

لذلك، نوصي بشدة بالتحقق من إعدادات IPsec على جهاز الحافة لديك (جهاز توجيه، جدار ناري، جهاز ظاهري، إلخ) قبل تكوين إعدادات اتصال Cato IPsec. ثم استخدم نفس الإعدادات تماماً لتكوين موقع IPsec.

واحدة من أكثر أخطاء التكوين شيوعاً هي استخدام مجموعة Diffie-Helman (DH) غير متوافقة. تحدد مجموعة DH مستوى قوة المفاتيح المستخدمة في رسائل Auth وInit بين طرفي الاتصال. إذا لم تتطابق مجموعة DH على كلا الجانبين، يفشل النفق في الاتصال. لذلك، يجب اختيار مجموعة DH التي تتطابق على كلا الجانبين من اتصال IPsec. قم بتكوين معلمة مجموعة DH في تطبيق إدارة Cato التي تتطابق مع تكوين جهاز الحافة لديك.

توصية هامة أخرى هي للتكوينات التي تستخدم PFS (Perfect Forward Secrecy) لتجديد المفاتيح. عندما يتم ضبط معلمة مجموعة DH على None، يتم تعطيل PFS. لذلك، إذا كنت تفعّل PFS، تحقق من أن مجموعة DH تم تكوينها تحت قسم Auth Message Parameters.

لقطة الشاشة التالية تظهر عينة من معلمات Auth Message وخيارات مجموعة DH:

نوصي بتجنب استخدام إعدادات التشفير الضعيفة إن أمكن واستخدام مجموعة DH أعلى لتوفير مستوى أعلى من الأمان.

عند تكوين الموقع في تطبيق إدارة Cato، إذا لم يتم تكوين مجموعة DH لـ IKEv2 في Auth Message Parameters، يمكن أن تظهر مجموعة DH في Init Message Parameters لرابطة الأمان الفرعية (SA). هذا لأن أول رابطة SA يتم إنشاؤها دائماً في تبادل IKE_AUTH الأولي وتستخدم نفس المواد المفتاحية مثل رابطة IKE. تستخدم رابطة IKE المجموعة DH التي تم تكوينها في قسم Init Message Parameters. لا يوجد تبادل مجموعة DH في IKE_AUTH.

إذا كانت مجموعة DH تم تكوينها في قسم Auth Message Parameters، فسيتم استخدامها فقط أثناء تبادلات CREATE_CHILD_SA التي إما تنشئ روابط SA فرعية إضافية أو تعيد مفتاح روابط SA الحالية.

شيء يجب الانتباه له هو تباين مجموعات DH المكونة في تطبيق إدارة Cato والأقران IKEv2. في هذه الحالة، يبدأ النفق مبدئياً بعد تبادل IKE_AUTH لكنه يفشل في إعادة المفتاح باستخدام تبادل CREATE_CHILD_SA. قد يحدث انقطاع مؤقت قبل أن تجلب تبادلات IKE_SA_INIT وIKE_AUTH النفق مرة أخرى.

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

بالنسبة لمواقع IPsec بعرض نطاق أعرض من 100Mbps، استخدم فقط خوارزميات AES 128 GCM-16 أو AES 256 GCM-16. تُستخدم خوارزميات AES CBC فقط للمواقع ذات عرض النطاق الأقل من 100Mbps.

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

يدعم Cato كلا الإصدارين IKEv1 وIKEv2 للتفاوض بين طرفي الاتصال. عند إنشاء موقع IPsec في تطبيق إدارة Cato، اختر الإصدار المدعوم لتبادل المفاتيح عبر الإنترنت (IKEv1 أو IKEv2) الذي يتطابق مع جهاز الحافة لديك. إذا تم دعم IKEv2، فإننا نوصي عموماً باستخدامه. ومع ذلك، بعض الأجهزة لا تدعم نفس معلمات IKEv2 المتاحة في تطبيق إدارة Cato. في هذه الحالة، استخدم IKEv1 بدلاً من ذلك. على سبيل المثال، إذا كان جدار الحماية لديك لا يدعم تشفير AES CBC 256، فلا تستخدمه في تكوين IPsec الخاص بك. لمزيد من المعلومات حول IKEv1 وIKEv2، انظر دليل Cato IPsec: IKEv1 مقابل IKEv2

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

لقطة الشاشة التالية تظهر خيار المبادئ IKEv2:

يمكن أن تكون تكوينات IPsec لـ VPNS لمزودي السحابة المختلفة غير متوافقة. يستخدم كل موفر سحابة (على سبيل المثال: Amazon AWS، Microsoft Azure أو GCP) إعدادات تكوين افتراضية مختلفة لأنفاق IPsec. تحقق من إعداد تكوين IPsec الخاص بموفر السحابة لديك واستخدم تكويناً يتطابق مع موقع Cato IPsec.

ملاحظة: إذا قمت بتغيير إعدادات IPsec السحابة الافتراضية، تذكر استخدام نفس الإعدادات في إعدادات موقع IPsec لتطبيق إدارة Cato.

على سبيل المثال، تتعامل Azure مع PFS بشكل مختلف يعتمد على ما إذا كانت المبادئ أو المستجيب لرابطة SA الفرعية (ESP SA). عندما تكون المبادئ، لا تقوم Azure بإرسال مجموعة DH بشكل افتراضي. عندما تكون المستجيب، تقبل Azure مجموعة DH من الطرف المقابل. هذا يعني أنه إذا تم تكوين مجموعة DH تحت قسم Auth Message Parameter في تطبيق إدارة Cato وحاولت Azure إنشاء ESP SA باستخدام تبادل CREATE_CHILD_SA، فإن Cato ترد بـ"لا يوجد اقتراح مختار" وتفشل SA في الإنشاء. ومع ذلك، إذا قامت Cato بتفعيل تبادل CREATE_CHILD_SA، فإن ESP SA يتم إنشاؤه إذا كانت مجموعة DH المكونة هي واحدة تقبلها Azure كمستجيب. لضمان أقصى توافق مع Azure، إما ضبط مجموعة DH على None في قسم Auth Message Parameter من تكوين موقع IKEv2 أو تكوين سياسة مخصصة في Azure تحدد نفس مجموعة PFS كمجموعة DH المكونة في تطبيق إدارة Cato.

لقطة الشاشة التالية تظهر مثالاً لتكوين مخصص لـ Azure:

لمزيد من المعلومات حول معلمات VPN لـ Azure، انظر حول أجهزة VPN ومعلمات IPsec.

تسمح لك Cato Networks باختيار معلمات تلقائية لـ IKEv2 Init ومعلمات رسالة Auth مثل التشفير، وRPF وخوارزميات النزاهة. إذا واجهت مشاكل في الاتصال أو التوجيه عند استخدام التكوين التلقائي، نوصي باختيار التكوين الدقيق الذي يتطابق مع إعدادات جهاز الحافة لديك وتجنب استخدام تلقائية.

ومع ذلك، للمواقع التي تم تكوينها باستخدام GCM لخوارزمية التشفير (AES GCM 128 أو AES GCM 256)، فإن خوارزمية النزاهة ليست ذات صلة لأن GCM يقدم أيضاً النزاهة. عند اختيار خوارزمية تشفير AES GCM، يتم ضبط خوارزمية النزاهة على تلقائية.