تحذير OpenVPN AF_INET: احتياطي غير ضار أم مقبس فاشل؟

يبدأ سطران من سجل OpenVPN بالكلمات نفسها، وواحد فقط منهما يبلّغ عن مشكلة. Could not determine IPv4/IPv6 protocol. Using AF_INET إشعار احتياطي: ترك الملف الشخصي عائلة العنوان مفتوحة، فاختار الخادم واحدة ومضى قدماً. أما فرع الفشل فيبلّغ بأنه لم يُنشأ أي مقبس ويطلب إعادة التشغيل. كل ما يأتي بعد البادئة المشتركة يفصل بينهما، فاقرأ ما بعدها قبل أن تغيّر أي شيء.

ما الذي يبلّغ عنه إشعار الاحتياطي

يقبل OpenVPN عائلة صريحة عبر proto udp4 أو proto udp6، ويقبل proto udp عندما ينبغي اشتقاق العائلة عند بدء التشغيل. في الحالة الثانية يفحص الخادم معلومات الربط المحلية ويختار.

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

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

كيف يبدو فرع الفشل

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

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

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

افحص المستمع بدلاً من التحذير

الخادم العامل يجيب عن سؤال العائلة مباشرة، دون استنتاج من نص السجل.

ss -lunp | grep openvpn
ss -ltnp | grep openvpn

طابق العائلة والعنوان والمنفذ مع الملف الشخصي. صف 0.0.0.0:1194 خاص بـ IPv4 وحده، بينما صف [::]:1194 على مضيف ثنائي الحزمة قد يقبل العائلتين حسب إعداد bindv6only. إذا قال الملف الشخصي udp وكان المقبس IPv4، فإن العملاء الذين يعيد محللهم سجل AAAA فقط يفشلون قبل التفاوض على النفق أصلاً.

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

متى يكون فرض عائلة صحيحاً

تثبيت proto udp4 يناسب نشر IPv4 فقط: اسم DNS من النوع A فقط، وقواعد جدار حماية لعنوان v4 واحد، وعملاء خلف مشغلي شبكات يمنحون عناوين v4 فقط. يزيل هذا الغموض ويجعل المجموعة التالية من أسطر السجل متوقعة.

الحجة نفسها تسير في الاتجاه المعاكس لبيئة تفضّل IPv6، أما udp6 أمام قاعدة عملاء من النوع A فقط هو انقطاع تسببه لنفسك. فرض عائلة فقط لإسكات تحذير غير ضار هو النسخة الكلاسيكية من هذا الخطأ، لأنك غيّرت من يستطيع الاتصال مقابل سجل أهدأ.

اختر انطلاقاً من نقاط النهاية والعملاء الذين يجب أن يصلوا إليها. إن دليل OpenVPN 2.6 يوثّق أشكال النقل، والرسالة هي ناتج ذلك الاختيار لا مدخل إليه.

أبقِ السجل ضيقاً

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

اقتراحات الحزم التي تصل إلى جانب هذا التحذير غير ذات صلة حتى يسمّي خطأ ملفاً تنفيذياً مفقوداً.

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