strongSwan vips: طلب عنوان افتراضي من IKEv2

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

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

ما يطلبه vips، وما لا يستطيع ضمانه

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

طلب 0.0.0.0 يعني طلب أي عنوان IPv4 افتراضي متاح، وهذا صحيح عادةً عندما لا تهم القيمة الدقيقة. طلب عنوان محدد تلميح إلى البوابة، وليس مطلبًا عليها.

مقطع swanctl وأين ينتمي

يقع الإعداد داخل كتلة الاتصال، لا في ملف خاص به ولا في ملف تعريف لنظام التشغيل. يوضح هذا المقطع المعزول الشكل:

connections {
  net {
    local_addrs = 192.0.2.10
    remote_addrs = 203.0.113.5
    vips = 10.77.0.31
    children {
      net { local_ts = dynamic remote_ts = 10.77.0.0/24 }
    }
  }
}

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

swanctl --load-all --file /etc/swanctl/swanctl.conf
swanctl --initiate --child net
swanctl --list-sas

local_ts يختار حركة المرور، ولا ينشئ عنوانًا

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

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

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

تحقق مما أسنده المستجيب فعليًا

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

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

أبقِ التصميم الثابت منفصلًا

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

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

مقالات ذات صلة