Netgear OpenVPN: يستمع TUN وTAP إلى منفذين مختلفين

يتصل هاتف بشبكة VPN الخاصة بالراوتر دون أي شكوى، بينما تنتهي مهلة حاسوب محمول يستخدم ملفًا شخصيًا من صفحة التنزيل نفسها. لم يتغير شيء يخص الشهادات بين المحاولتين، لأن الحاسوب المحمول لم يصل قط إلى النقطة التي تصبح فيها الشهادات مهمة. ينشر الراوتر مستمعين منفصلين لـ TUN وTAP، وعلى الملف الشخصي العامل أن يختار المستمع الذي يخص نوع جهازه.

تحديد أي من الأعطال الثلاثة المحتملة يجب ملاحقته هو المهمة كلها هنا: المنفذ، أو نوع الجهاز، أو تفاوض شيفرة قناة البيانات.

ثلاثة أشياء يجب أن تتفق

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

تذكر تقارير من الميدان زوجًا مثل 12973 لـ TUN و12974 لـ TAP على إصدار واحد، ورقمًا مختلفًا على آخر. اقرأ ذلك كدليل على أن الإصدارات تختلف، لا كثوابت تُنسخ. يحتاج الملف الشخصي بعد ذلك إلى اسم مضيف مناسب للمسافة: اسم DNS الديناميكي للراوتر بدلًا من عنوان WAN سيتغير.

بعد تصحيح المنفذ وسطر الواجهة، يبدو الملف الشخصي كإعداد عميل عادي بسطر remote واحد وسطر dev واحد. إذا اختلف الاثنان، فلا مقدار من إعادة المحاولة ينتج جلسة.

اقرأ السجل بالترتيب الذي يُطبع به

يبلغ عميل OpenVPN عن الأحداث بالترتيب الذي تحدث به، لذا يحدد السطر الأخير قبل الصمت الطبقة التي يجب فحصها. عندما ينتهي التشغيل عند TLS Error: TLS key negotiation failed، أو ينتظر ببساطة ردًا أول ثم يستسلم، لم يحدث مقارنة الشهادات قط. يشير ذلك إلى الوصول، أو إلى المستمع، أو إلى منفذ لا شيء خلفه. لا يُصلح أي من ذلك باستبدال ملف CA.

التشغيل الذي يصل إلى VERIFY OK ثم يفشل يقع في مكان آخر تمامًا، بأسبابه الخاصة. فرز هاتين النتيجتين قبل لمس الملفات يمنع الانحراف الكلاسيكي عبر حزم الشهادات التي لم يُستشر فيها قط. بعد اكتمال المصافحة دون أن ينهض النفق، انظر إلى تفاوض الشيفرة بدلًا من الوصول.

أضف قائمة الشيفرات التي يتوقعها عميل حديث

ترفض عملاء OpenVPN الحديثة الإعدادات الافتراضية الأقدم التي لا تزال البرمجيات الثابتة للأجهزة الاستهلاكية تقدمها، والعَرَض هو فشل تفاوض فور نجاح مصافحة. الإصلاح سطر واحد في الملف الشخصي يسمّي ما سيقبله العميل: اضبط data-ciphers على AES-256-GCM، AES-128-GCM، CHACHA20-POLY1305، AES-128-CBC بهذا الترتيب. أي خوارزمية لا ينفذها الراوتر لا تُختار ببساطة أبدًا، لذا فقائمة أطول لا تكلف شيئًا سوى تفاوض أطول قليلًا.

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

استورد مرة واحدة بدلًا من تحرير النسخ يدويًا

استيراد الملف المصحح إلى NetworkManager يتجنب مجلدًا مليئًا بملفات شخصية مختلفة قليلًا: nmcli connection import type openvpn file client.ovpn، ثم أطلقه بالاسم. احتفظ بالملف الشخصي المستورد كالنسخة الوحيدة التي تحررها، واحذف التكرارات التي تتراكم من التنزيلات المتكررة.

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

قرر ما ستفعله بشأن التحذيرات

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

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