تخطيط وصول خاص عبر IKEv2 ثنائي المكدس باستخدام strongSwan

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

ثلاثة أنواع من العناوين تُقرَّر بشكل منفصل

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

النقل الخارجي عبر IPv4 فقط مع نقل داخلي ثنائي المكدس ترتيب طبيعي ومدعوم جيدًا.

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

خصِّص عنوانًا ظاهريًا في كل عائلة

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

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

vips = 0.0.0.0, ::

أنشئ بادئة محلية فريدة خاصة بك لمجموعة IPv6 بدلًا من تبني قيمة مثال قصيرة. المثال يوضح شكل الإعداد، لا قيمة افتراضية تُورَّث.

صِف الوجهات بمعزل عن المجموعات

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

تلك البادئات نفسها تحتاج إلى مسارات عودة وإعادة توجيه مسموح بها داخل شبكة البوابة، لكل عائلة تُفعِّلها.

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

اجعل DNS ومسارات العودة مقصودين

تحليل الأسماء لا يتبع النقل. يمكن للمحلل أن يعيد سجلات A وAAAA عبر نفق IPv4 فقط، وسيحاول العميل عندئذٍ عائلة لم تخطط لها قط. قرِّر أي أسماء خدمات ينبغي أن تحمل إجابات ثنائية المكدس صالحة واجعل هذين المسارين مقصودين. الاسم الذي يُحلَّل إلى عائلة بلا مسار عامل ينتج توقفًا لا خطأ نظيفًا، والتوقفات أصعب بكثير في التشخيص.

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

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