كيفية ربط qBittorrent بواجهة VPN على macOS
اضبط Network Interface في إعدادات qBittorrent المتقدمة على macOS، واربط أسماء utun بالنفق النشط، ثم أعد تشغيل العميل وأثبت الربط باختبار نقل.
فتحت qBittorrent على جهاز Mac mini، وضبطت Network Interface على utun4، ثم أعدت التشغيل وقضيت بعد ظهر كامل في مشاهدة ملف تورنت عالق عند جلب البيانات الوصفية بينما كان VPN لا يزال يعرض اتصالاً سليماً. لم يكن الإعداد خاطئاً من حيث المبدأ؛ كان الاسم قديماً. يمنح macOS أرقام utun عند بدء الخدمات، لذا كان utun4 الذي كان صحيحاً في الأسبوع السابق يشير إلى نفق لم يعد موجوداً، وكان العميل يربط مقابسه بجهاز بلا مسار. التسلسل أدناه هو ما أستخدمه الآن: اقرأ الواجهة من النفق العامل، واخترها في العميل، ثم أعد تشغيل الجلسة، وأثبت الربط باختبار نقل وقطع متعمد.
افتح Advanced واعثر على حقل الواجهة
في نافذة qBittorrent، افتح Preferences بالضغط على Cmd+، وانتقل إلى صفحة Advanced. حقل Network Interface هو المهم: فهو يسرد أسماء واجهات النظام ويأتي افتراضياً على Any Interface، أي أن نظام التشغيل يختار مساراً لكل مقبس يفتحه العميل. ومرجع الخيارات الخاص بالمشروع يوثق هذا الحقل وهذا الافتراضي، وهو الإعداد نفسه على كل منصة وإن اختلفت الأسماء داخله.
هناك تفصيلان يوقعان الناس في الخطأ هنا. تعرض القائمة أسماء أجهزة مثل en0 وen1 وutun0 حتى utun9، ولا تعرض أبداً اسم منتج مزود VPN، لذا تحتاج إلى الربط بينها قبل أن تختار شيئاً معقولاً. كما يُطبَّق الاختيار عند بدء جلسة BitTorrent، لا في لحظة الضغط على OK، لذا قد يظل تغيير يبدو محفوظاً يعمل على الربط القديم.
أغلق التطبيق إغلاقاً صحيحاً بـ Cmd+Q وتأكد من زوال العملية قبل إعادة فتحه. إغلاق النافذة يخفيه فقط، والعميل المخفي يحتفظ بجلسته ومنفذ الاستماع وواجهته القديمة.
pgrep -fl qbittorrentاعثر على الواجهة التي يملكها VPN فعلاً
اتصل بـ VPN أولاً عبر عميل المزود نفسه، ثم اقرأ رؤية النظام بدلاً من قائمة العميل. تسرد الأوامر أدناه كل واجهة مع عناوينها، وتظهر ما يعتبره النظام نشطاً، وتطبع جدول التوجيه؛ أنت تبحث عن جهاز utun الذي يحمل النطاق الخاص الذي يمنحه مزودك.
ifconfig -a | grep -A4 '^utun'
scutil --nwi
netstat -rn -f inet | head -n 5ثلاث قراءات تخبرك أي جهاز هو النفق. يحتاج مدخل utun إلى عنوان inet ينتمي إلى مجموعة عناوين VPN. يظهر scutil --nwi أي الواجهات يعتبرها النظام نشطة وأيها أساسية. يظهر netstat -rn أين يشير المسار الافتراضي، وإذا كان ذلك المسار لا يزال يشير إلى en0 بينما يملك utun عنواناً، فالنفق لا يحمل كل الحركة، وهذا يغيّر ما سيفعله الربط لاحقاً.
عندما يمكن أن يوجد نفقان في وقت واحد، مثل ملف تعريف للعمل وآخر شخصي، يكون جهازا utun موجودين ولا يكون مفيداً إلا واحد منهما. عدادات البايتات تحسم السؤال: سجل العدادات، وحمّل صفحة أو ابدأ نقلاً صغيراً، وانظر أيهما تحرك.
netstat -ib | grep utunلا تعتبر الرقم مستقراً أيضاً. قد يمنح إعادة الاتصال النفق نفسه اسم utun مختلفاً، وقد تحتجز خدمة iCloud أو Continuity اسم utun0 قبل أن يتصل VPN الخاص بك بوقت طويل.
طابق الربط مع نطاق النفق
الحقل يربط جهازاً، وهذا كل ما يفعله. إذا كان VPN نفقاً كاملاً يوجه 0.0.0.0/0 إلى utun، فإن الربط بذلك الجهاز يرسل كل اتصال نظير وكل طلب متتبع عبر VPN. إذا كان VPN نفقاً منقسماً يوجه شبكات فرعية قليلة فقط، فإن الربط بـ utun يرسل حركة الأقران إلى جهاز بلا مسار لهؤلاء الأقران، فتتوقف عمليات النقل بدلاً من أن تتسرب. كلا النتيجتين أأمن من Any Interface، لكن واحدة فقط منهما تبقي العميل يعمل. لا شيء خارج العميل يتغير: المتصفحات والتطبيقات الأخرى تحتفظ بمساراتها، لذا فإن شرطاً يغطي كل التطبيقات يحتاج إلى فرض من جهة VPN.
اقرأ الحالة قبل أن تختار أي شيء:
| What you see | What it means for the bind |
|---|---|
| A utun with a provider address and the default route pointing at it | Full tunnel; the bind covers peer and tracker traffic |
| A utun with a provider address but the default route still on en0 | Split tunnel; the bind will stall transfers unless the provider routes 0.0.0.0/0 |
| No utun carrying a provider address | The VPN is down or connects on demand; bring it up before selecting |
| A utun number that changed since the last session | The saved name is stale; reselect and restart |
عائلة العناوين مهمة أيضاً. المزود الذي يمنح IPv4 فقط يترك الواجهة المربوطة بلا عنوان IPv6، لذا تفشل أقران IPv6 بدلاً من أن تتسلل عبر Wi-Fi. وبشكل منفصل، فإن ربط المقابس لا يثبت تحليل الأسماء: تُحل أسماء مضيفي المتتبعات عبر محلل macOS، الذي يتبع إعداد DNS في النظام لا الجهاز المختار.
ثلاث طرق يفشل بها اختيار يبدو صحيحاً
الفشل الأول هو عدم إعادة التشغيل. يعرض الحقل utun4، وتبدو التفضيلات مهيأة، ومع ذلك يخرج نقل تجريبي عبر Wi-Fi لأن الجلسة العاملة احتفظت بالربط القديم. أغلق تماماً، وتأكد بـ pgrep، وأعد الفتح، وابدأ النقل مرة أخرى.
الثاني هو الاسم القديم بعد إعادة الاتصال. بمجرد اختفاء الجهاز المربوط، تفشل اتصالات الأقران ويميل العميل إلى الإبلاغ عن أخطاء متتبع بدلاً من رسالة واضحة بأن الواجهة اختفت، وهو ما يبدو كتورنت ميت. أعد قراءة ifconfig، واختر الاسم الجديد، وأعد التشغيل.
الثالث هو افتراض أن الربط يفشل مغلقاً. اختيار واجهة يطلب من النظام ربط المقابس باسم جهاز؛ وما يحدث عندما يكون ذلك الاسم مفقوداً أو معاداً استخدامه ليس شيئاً تضمنه شاشة الإعدادات. اختبار القطع في القسم التالي هو الدليل الوحيد الذي يعتد به.
تحقق بنقل حقيقي وقطع للاتصال
استخدم نقلاً مسموحاً لك بتشغيله، مثل صورة توزيعة Linux، وابدأه و VPN متصل. راقب عدادات كل واجهة قبل وبعد، وقارنها بعداد البيانات في عميل VPN نفسه؛ ينبغي أن يرتفعا معاً بينما تمتلئ قائمة الأقران.
netstat -ib | grep utun
pgrep -fl qbittorrentثم اقطع VPN من واجهته الخاصة وراقب النقل. ينبغي أن تختفي الأقران، وأن تفشل الاتصالات الجديدة بعد وقت قصير من سقوط النفق. إذا استمرت السرعة، فالربط غير ساري وأنت عائد إلى خطوة إعادة التشغيل، لا إلى الجدار الناري.
أعد الاتصال وافحص الاسم المختار مرة أخرى، لأن النفق قد يعود باسم utun مختلف. ملاحظة قصيرة تسجل نوع النفق واسم الواجهة والسلوك المتوقع عند سقوط VPN توفر الجلسة التالية: هذا الإعداد لكل جهاز ولكل مزود، وهو لا يصمد أمام ترقية العميل ولا أمام تغيير تطبيق VPN.