วิธีผูก qBittorrent กับอินเทอร์เฟซ VPN บน macOS
ตั้งค่า Network Interface ใน Advanced ของ 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