איך לקשור את 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.