ما الذي يجب تسجيله في VPN من موقع إلى موقع: المحدِّدات والنطاق

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

المهيّأ ليس متفاوضًا عليه

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

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

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

أنفاق المسارات تختار بطريقة مختلفة

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

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

الترجمة تنتمي إلى الجدول نفسه

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

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

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

أرفق متطلب الخدمة

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

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

حوّل السجل إلى خطة اختبار

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

swanctl --list-sas

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

sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops

اختبار ping من البوابة وحدها ليس اختبار القبول. فهو لا يمرّن مسار العبور أبدًا، لذا قد ينجح بينما يفشل كل تدفق مُمرَّر. اختبر من مضيف على جانب إلى خدمة على الجانب الآخر وأكّد أن الرد يصل عبر النفق. إذا نجح اختبار ping وحده، فقد وجد السجل للتو مشكلة تمرير أُكتب لمنعها. توثيق strongSwan للتمرير يشرح كيفية تفاعل المحدِّدات والمسارات والتمرير على طرف Linux.