MULTI: عنوان مصدر غير صالح من العميل: عنوان مَن كان؟
المصدر الداخلي لا يطابق العميل الذي أوصله. طابقه مع تخصيص نفق، أو شبكة محلية خلف العميل، أو هوية مكررة.
يطبع سجل الخادم MULTI: bad source address from client، ويُسقط الحزمة، وتبقى الجلسة متصلة. هذا المزيج يُربك من يقرأ الرسالة على أنها فشل في المصادقة. الأمر ليس كذلك: العميل قد صادق بالفعل، والحزمة التي وصلت كانت تحمل عنوان مصدر داخلي لم يستطع الخادم ربطه بتلك النسخة من العميل. تحدث المراجعة قبل التسليم، ولهذا يبدو النفق سليمًا بينما لا يعبره شيء مفيد.
ما يقارنه الخادم قبل التسليم
لكل حزمة تصل من عميل، ينظر خادم مساحة المستخدم إلى عنوان المصدر داخل النفق ويسأل حالة التوجيه الداخلية عن العميل الذي يملك ذلك العنوان. وإذا كان المالك نسخة أخرى، أو لم يكن هناك مالك على الإطلاق، تُمسح الحزمة ويصدر التحذير.
التسليم العادي عبر واجهة النفق لا يحدث أبدًا.
هذا الترتيب يفسر تفصيلًا يحيّر الناس: عدادات جدار الحماية على المضيف لا تتحرك، لأن الحزمة لم تصل إلى جدار الحماية أصلًا. وتعديل تصفية المسار العكسي على المضيف لا يغيّر شيئًا هنا، لأن الرفض حدث داخل فحص الارتباط الخاص بالخادم الخفي. اقرأ الرسالة كبيان عن الملكية، ثم اكتشف أي المواقف الثلاثة أنتجها.
ثلاثة مصادر لعنوان داخلي غير متطابق
قد يرسل العميل من عنوان لم يُخصص له، أو من شبكة لم يعلن أحد أنها تخصه، أو من نسخة مكررة من هوية لها مالك بالفعل. الثلاثة جميعًا تنتج السطر نفسه في السجل. لكنها تختلف في ما عليك تغييره. ابدأ بالعنوان وقائمة التخصيصات الحالية، ودع هاتين الحقيقتين تحددان الحالة.
يتطلب التفريق بينها حقيقتين: العنوان المرفوض في السجل، والتخصيصات التي يعتقد الخادم أنها حالية. الثانية متاحة من عرض الحالة أو الإدارة للنسخة العاملة، وهي المرجع الوحيد الجدير بالرجوع إليه، لأن ملف التهيئة يسجل النوايا لا الحالة الراهنة.
سجّل الاثنين قبل أن تغيّر أي شيء، ثم صنّف. لقطة الشاشة التي تُؤخذ بعد ذلك ليست سجلًا للحالة التي أنتجت التحذير. احتفظ بالطابع الزمني أيضًا، لأن التخصيصات تنتقل بين الجلسات.
| Rejected source is | Likely cause |
|---|---|
| The client's own tunnel address | Static assignment conflict, wrong profile, or manual address change |
| A host behind that client | Missing internal ownership for that prefix |
| An address belonging to another session | Two devices sharing one identity or one static address |
الشبكة المحلية خلف العميل و iroute
عندما يوجّه عميل موقع شبكته الخاصة، يجب إعلان تلك الشبكة على أنها تخص العميل. ملف خاص بالعميل يحتوي على مدخل iroute يفعل ذلك، والمدخل يسمّي البادئة المسموح للعميل بحملها.
المسار في النواة الذي يوجّه البادئة نفسها إلى النفق مطلب منفصل، وإضافته لا تغيّر شيئًا في الملكية الداخلية للخادم الخفي.
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0تأكد من أن الهوية الفعلية تطابق اسم الملف، لأن عدم التطابق يعني أن الملف لا يُحمَّل أبدًا، والأعراض تكون مطابقة لمدخل مفقود. لا تُضف مدخل iroute واسعًا لإسكات التحذير، لأن ذلك يحوّل مصدرًا غير متوقع إلى مصدر مصرح به دون الإجابة عن سبب إرساله. يوثّق دليل OpenVPN 2.6 كلا من iroute و duplicate-cn وربط الهوية كضوابط منفصلة.
الهوية نفسها على جهازين
الملف الشخصي المنسوخ إلى حاسوب محمول ثانٍ يحمل الشهادة نفسها والاسم الشائع نفسه. وبحسب إعدادات الخادم قد يحل الاتصال الأحدث محل الأقدم، وأي نسخة تحتفظ بالملكية تفوز في فحص الارتباط.
وهذا يجعل العطل يبدو متقطعًا، فلا يظهر إلا حين يكون الجهازان مستيقظين.
السماح بأسماء شائعة مكررة يتيح للجهازين الاتصال، لكنه لا يمنحهما عنوانين ثابتين مستقلين ولا ملكية مستقلة. إذا كان على جهازين أن يتعايشا، فسجّلهما بشكل منفصل حتى تكون لكل منهما هويته وتخصيصه. التعامل مع إعداد التكرار كإصلاح لهذا التحذير يُبقي اللغز قائمًا ويضيف لغزًا ثانيًا.
أثبت أن الارتباط تغيّر
طبّق التصحيح عبر مالك التهيئة، ثم أعد توصيل العميل المتأثر حتى تُحمَّل السياسة الجديدة.
أعد المسار نفسه وتأكد من ثلاثة أمور: المصدر الداخلي للحزمة، ونسخة العميل التي يربطها الخادم بها، وسلوك الوجهة بعد ذلك.
إذا توقف التحذير لكن التطبيق ما زال يفشل، فالمشكلة انتقلت ولم تختفِ. إعادة التوجيه وقواعد جدار الحماية ومسار العودة مراحل منفصلة، واجتياز فحص الارتباط يعني فقط أن الحزمة سُمح لها بمغادرة النفق.