როგორ დავუკავშიროთ qBittorrent VPN ინტერფეისს macOS-ზე
macOS-ზე qBittorrent-ის Advanced-ში დააყენეთ Network Interface, 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-ში მარშრუტიზებს, მაშინ ამ მოწყობილობაზე მიბმა ყოველ peer კავშირს და ყოველ tracker მოთხოვნას VPN-ის გავლით აგზავნის. თუ VPN გაყოფილი გვირაბია, რომელიც მხოლოდ რამდენიმე ქვექსელს მარშრუტიზებს, utun-ზე მიბმა peer ტრაფიკს აგზავნის მოწყობილობაზე, რომელსაც ამ peer-ებისთვის მარშრუტი არ აქვს, და გადაცემები ჩერდება გაჟონვის ნაცვლად. ორივე შედეგი 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 peer-ები ჩავარდებიან Wi-Fi-ით გაძვრის ნაცვლად. ცალკე: სოკეტების მიბმა სახელების გარჩევას არ აფიქსირებს: tracker ჰოსტების სახელები იხსნება macOS-ის ამომხსნელით, რომელიც სისტემის DNS კონფიგურაციას მიჰყვება და არა არჩეულ მოწყობილობას.
სამი გზა, რომლითაც სწორად მოჩვენებული არჩევანი ჩავარდება
პირველი მარცხი გადატვირთვის არქონაა. ველი utun4-ს აჩვენებს, პარამეტრები კონფიგურირებულად გამოიყურება, და სატესტო გადაცემა მაინც Wi-Fi-ით გადის, რადგან მოქმედმა სესიამ ძველი მიბმა შეინარჩუნა. სრულად დახურე, დაადასტურე pgrep-ით, ხელახლა გახსენი და გადაცემა თავიდან დაიწყე.
მეორე ხელახალი დაკავშირების შემდეგ მოძველებული სახელია. როგორც კი მიბმული მოწყობილობა გაქრება, peer კავშირები ჩავარდება და კლიენტი უფრო tracker შეცდომებს აცნობებს, ვიდრე სუფთა შეტყობინებას, რომ ინტერფეისი წავიდა, რაც მკვდარ ტორენტს ჰგავს. ხელახლა წაიკითხე ifconfig, აირჩიე ახალი სახელი და გადატვირთე.
მესამე არის ვარაუდი, რომ მიბმა დახურულად ჩავარდება. ინტერფეისის არჩევა სისტემას სთხოვს სოკეტები მოწყობილობის სახელს მიამაგროს; რა ხდება, როცა ეს სახელი აკლია ან ხელახლა გამოიყენება, პარამეტრების ეკრანი არ იძლევა გარანტიას. შემდეგი ნაწილის გათიშვის ტესტი ერთადერთი მტკიცებულებაა, რომელიც ითვლება.
შეამოწმე ნამდვილი გადაცემით და გათიშვით
გამოიყენე გადაცემა, რომლის გაშვებაც დაშვებული გაქვს, მაგალითად Linux დისტრიბუტივის იმიჯი, და დაიწყე ის VPN-ის ჩართული მდგომარეობით. დააკვირდი ინტერფეისების მთვლელებს მანამდე და შემდეგ და შეადარე ისინი VPN კლიენტის საკუთარ მონაცემთა მთვლელს; ორივე ერთად უნდა იზრდებოდეს, სანამ peer სია ივსება.
netstat -ib | grep utun
pgrep -fl qbittorrentშემდეგ გათიშე VPN მისივე ინტერფეისიდან და დააკვირდი გადაცემას. peer-ები უნდა წავიდნენ, და ახალი კავშირები უნდა ჩავარდეს გვირაბის ვარდნიდან ცოტა ხანში. თუ გამტარობა გრძელდება, მიბმა ძალაში არ არის და თქვენ დაბრუნდით გადატვირთვის საფეხურზე და არა firewall-ზე.
ხელახლა დაუკავშირდი და კიდევ ერთხელ შეამოწმე არჩეული სახელი, რადგან გვირაბი შეიძლება სხვა utun-ის ქვეშ დაბრუნდეს. მოკლე ჩანაწერი გვირაბის ტიპის, ინტერფეისის სახელის და VPN-ის ვარდნისას მოსალოდნელი ქცევის შესახებ ზოგავს შემდეგ სესიას: ეს პარამეტრი თითოეული მანქანისა და თითოეული მომწოდებლისთვისაა, და ის არ გადაურჩება არც კლიენტის განახლებას და არც VPN აპლიკაციის შეცვლას.