OpenVPN TAP على macOS: تحقّق من العميل قبل أن تبدأ التصحيح

يصل ملف تعريف قديم إلى جهاز Mac حديث، يستورده العميل دون أي اعتراض، ثم ينقطع الاتصال أو لا يمرّ منه أي بيانات. قبل أن تصرف أمسية كاملة على الشهادات، اقرأ سطر الجهاز في ملف التعريف. إذا كان مكتوبًا فيه dev tap، فأنت تطلب من العميل واجهة بنمط Ethernet، وعلى macOS تنتهي معظم هذه الجلسات عند هذا الطلب.

الخطوة 1: تأكّد من أن ملف التعريف يطلب TAP فعلاً

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

grep -nE "^[[:space:]]*(dev|dev-type)[[:space:]]" client.ovpn
ls -l ~/Library/Application\ Support/ 2>/dev/null

إذا كان الملف يحتوي على dev tap أو dev tap0، فعلى العميل أن يوفّر واجهة TAP. وإذا كان يحتوي على dev tun، فلا تنطبق بقية هذه المقالة ويكون العطل في مكان آخر.

دوّن اسم العميل وإصداره، وإصدار macOS، ومصدر ملف التعريف. هذه الحقائق الثلاث تحدّد أي المسارين أدناه ممكن أصلاً.

الخطوة 2: اعرف ما يغيّره وضع الجهاز فعلاً

تحمل واجهة TUN حزم IP. يقرأ العميل الحزم المكتوبة إلى نظير IP ويكتبها، ويوجّهها نظام التشغيل مثل أي واجهة أخرى.

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

الثمن أن TAP يحتاج إلى برنامج تشغيل يقدّم واجهة Ethernet للنظام. لقد أوقفت Apple نموذج امتداد النواة الذي اعتمدت عليه برامج تشغيل TAP القديمة على Mac، وواجهة البرمجة البديلة لا تظهر تلقائيًا داخل عملاء لم يُحدَّثوا أبدًا لاستخدامها. قدرة المنصة ووجود منتج مشحون أمران مختلفان.

الخطوة 3: اختر بين عميل متوافق وترحيل

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

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

ما لا ينجح هو تحرير tap إلى tun في نسختك المحلية والأمل في أن ينجح. الخادم ما زال يجسر، والعميل صار يتحدث IP، ولا شيء يتوافق.

الخطوة 4: اجمع الحقائق قبل تغيير خدمة عاملة

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

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

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

الخطوة 5: تحقّق من الترحيل من الطرفين

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

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

أنهِ بإعادة الاتصال وإعادة التشغيل مرة واحدة، لأن ملف تعريف يعمل في المحاولة الأولى فقط يعني عادةً أن المسارات المدفوعة أو إعداد DNS لا يُطبَّقان عند إعادة الاتصال.

حين يفشل الأمر رغم ذلك، اقرأ الخطأ الأول

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

احتفظ بملف التعريف الأصلي والإعداد العامل حتى يُثبت البديل. التراجع عن تغيير في العميل سريع؛ أما إعادة بناء شبكة مجسّرة فكّكها أحدهم بناءً على حدس فليست كذلك.