چگونه qBittorrent را در macOS به یک رابط VPN مقید کنیم
در macOS، Network Interface را در Advanced qBittorrent تنظیم کنید، نام‌های 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.