واجهة utun في VPN على Mac قائمة لكن حركة البيانات تفشل؟ افحص ifconfig

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

ما الذي يحتويه سطر utun فعلاً

شغّل ifconfig -a عندما تريد الصورة كاملة. وعند استدعائه بلا وسائط، لا يطبع ifconfig إلا الواجهات القائمة الآن، ولهذا قد يغيب من المخرجات التي يلصقها الناس في تذاكر الدعم نفقٌ لم يبدأ. ويعيد ifconfig -l الأسماء وحدها، وهذه أسرع طريقة لمعرفة ما إذا ظهر utun جديد بعد اتصالك.

قراءة واجهة واحدة هي حيث تقبع التفاصيل المفيدة. النفق المتصل يبدو عادةً هكذا:

utun4: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
    inet 10.8.0.6 --> 10.8.0.5 netmask 0xffffffff
    inet6 fe80::ce81:b1c:bd2c:69e%utun4 prefixlen 64 scopeid 0x15

ثلاثة حقول تحمل الجواب. UP مع RUNNING يقولان إن النواة مستعدة لاستخدام الواجهة. POINTOPOINT مع عنوان النظير --> هما بصمة النفق لا الرابط الفيزيائي. وقيمة mtu تفسّر فئة كاملة من تقارير «يتصل ثم يتوقف»، لأن واجهات utun تنهض عادةً بـ MTU مخفض، 1380 في عدة بنى macOS، وقد يتجاوزها العميل. وقائمة الحقول قصيرة بما يكفي لتصفّحها مرة واحدة في دليل ifconfig الذي توزعه Apple.

اعثر على العملية التي تقف خلف الواجهة

ليس لدى ifconfig أي مفهوم للتطبيق المالك. عميلان للـ VPN وخدمة نظام ونفق متبق من الأسبوع الماضي كلها تنتج مداخل متطابقة في هذا المستوى. على جهاز Mac الخاص بي كانت utun0 حتى utun3 موجودة قبل أن أضبط أي شيء؛ فـ Continuity وiCloud Private Relay يستخدمان أنفاقًا أيضًا، وليس أي منها الاتصال الذي تشخّصه.

بالنسبة إلى الأنفاق التي تسجّل إعدادًا لدى النظام، يعدّ scutil --nc list أسرع وسيلة للربط. فهو يطبع كل إعداد مع حالته ومعرّف خدمته، ويُعلَّم الإعداد المتصل على هذا النحو:

scutil --nc list
* (Connected)   5F2A9C10-...   VPN  Work IKEv2

العملاء الذين يشغّلون عملية نفق خاصة بهم بدل تسجيل إعداد لا يظهرون هناك أبدًا. ويقع Tunnelblick ونسخة openvpn من سطر الأوامر في تلك المجموعة، لذا افحص جدول العمليات أيضًا: ps -Ao pid,comm | grep -i openvpn. وبمجرد أن تملك عملية ما النفق، يصبح رقم utun ملكًا لتلك العملية ولا شيء غيرها.

اختبر العنوان قبل أن تختبر المسار

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

تستحق MTU فحصًا منفصلًا، لأن الفشل لا يبدو مشكلة في الحجم. إنه يبدو اتصالًا يصادق ثم يصمت بمجرد أن يبدأ نقل كبير. أرسل مسبارًا لا يجوز تجزئته، بحجم يجعل الحزمة تطابق MTU الواجهة؛ فمع MTU قدره 1400 تكون الحمولة 1372 بايت:

ping -D -s 1372 10.8.0.5

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

أثبت أن الوجهة تختار النفق

السؤال المهم ليس هل يوجد utun4، بل هل تغادر حركة المرور المتجهة إلى عنوان واحد بعينه عبره. يجيب route -n get عن ذلك لوجهة واحدة ويطبع البوابة والواجهة التي سيستخدمها:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

إذا أبلغ الأمر نفسه عن en0، فإعداد النفق المنقسم لديك يفعل ما طُلب منه، ولن يغيّره أي قدر من فحص الواجهات. استخدم netstat -rn -f inet عندما تحتاج المسار الافتراضي والجدول كله في عرض واحد.

تحسم العدادات ما إذا كانت الحزم تتحرك فعلاً. يبلّغ netstat -ib عن إجماليات الحزم والبايتات لكل واجهة، بما فيها مداخل utun؛ والأرقام تراكمية، لذا اقرأها مرتين بفاصل وقارن:

netstat -ib | grep utun4

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

حين لا يظهر أي utun على الإطلاق

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

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

أبقِ جانب القراءة للقراءة فقط. يقطع sudo ifconfig utun4 down النفق، وفي ملف تعريف نفق كامل يأخذ جلستك البعيدة معه، وهي مقايضة رديئة حين كنت تحاول جمع الأدلة فقط. لا شيء تحتاجه هنا يتطلب الجذر: فقراءة الأعلام والعناوين والعدادات كلها تعمل كمستخدمك العادي.

نفّذ الفحوص بالترتيب في المرة القادمة التي يسيء فيها نفق Mac التصرف: تأكد من ظهور utun عبر ifconfig -l، واقرأ أعلامه وعناوينه وMTU، وانسبه إلى عملية، واسأل route -n get أي واجهة تستخدمها الوجهة، ثم راقب netstat -ib يتحرك. كل خطوة تستبعد طبقة مختلفة، وأول خطوة تعود خاطئة هي حيث ينتمي الإصلاح.