macOS'ta qBittorrent'i bir VPN arayüzüne bağlama

Bir Mac mini'de qBittorrent'i açtım, Network Interface'i utun4 olarak ayarladım, yeniden başlattım ve sonra VPN hâlâ sağlıklı bir bağlantı gösterirken bir torrentin meta veri alımında takılıp kalmasını izleyerek bir öğleden sonra geçirdim. Ayar ilke olarak yanlış değildi; ad eskimişti. macOS, hizmetler başlarken utun numaralarını atar, bu yüzden bir hafta önce doğru olan utun4 artık var olmayan bir tünele işaret ediyordu ve istemci soketlerini rotası olmayan bir aygıta bağlıyordu. Aşağıdaki sıra şu anda kullandığım yöntemdir: arayüzü çalışan tünelden okuyun, istemcide seçin, oturumu yeniden başlatın ve sonra bağlamayı bir aktarım ve bilinçli bir bağlantı kesmeyle kanıtlayın.

Gelişmiş'i açın ve arayüz alanını bulun

qBittorrent penceresinde Tercihler'i Cmd+, ile açın ve Gelişmiş sayfasına gidin. Önemli olan alan Network Interface'tir: sistemin arayüz adlarını listeler ve varsayılan olarak Any Interface'tedir, yani işletim sistemi istemcinin açtığı her soket için bir rota seçer. Projenin seçenek başvurusu bu alanı ve bu varsayılanı belgeler ve içindeki adlar aynı olmasa da bu her platformda aynı ayardır.

Burada iki ayrıntı insanları yanıltır. Liste en0, en1 ve utun0 ile utun9 gibi aygıt adlarını gösterir, hiçbir zaman VPN sağlayıcısının ürün adını göstermez, bu yüzden mantıklı bir şey seçmeden önce eşleştirmeye ihtiyacınız var. Ve seçim BitTorrent oturumu başlarken uygulanır, OK'e bastığınız anda değil, bu yüzden kaydedilmiş görünen bir değişiklik hâlâ eski bağlama üzerinde çalışıyor olabilir.

Uygulamayı Cmd+Q ile düzgün kapatın ve yeniden açmadan önce sürecin gittiğini doğrulayın. Pencereyi kapatmak onu yalnızca gizler ve gizli bir istemci oturumunu, dinleme bağlantı noktasını ve eski arayüzünü korur.

pgrep -fl qbittorrent

VPN'inizin gerçekten sahip olduğu arayüzü bulun

Önce VPN'i sağlayıcının kendi istemcisi üzerinden bağlayın, sonra istemcinin menüsü yerine sistemin görünümünü okuyun. Aşağıdaki komutlar her arayüzü adresleriyle listeler, hangilerini sistemin etkin saydığını gösterir ve yönlendirme tablosunu yazdırır; sağlayıcınızın verdiği özel aralığı taşıyan utun aygıtını arıyorsunuz.

ifconfig -a | grep -A4 '^utun'
scutil --nwi
netstat -rn -f inet | head -n 5

Üç okuma hangi aygıtın tünel olduğunu söyler. utun girdisinin VPN'in havuzuna ait bir inet adresine ihtiyacı vardır. scutil --nwi hangi arayüzleri sistemin etkin saydığını ve hangisinin birincil olduğunu gösterir. netstat -rn varsayılan rotanın nereye işaret ettiğini gösterir ve bu rota bir utun adrese sahipken hâlâ en0'a işaret ediyorsa tünel tüm trafiği taşımıyordur, bu da bağlamanın sonra ne yapacağını değiştirir.

Aynı anda iki tünel olabildiğinde, örneğin bir iş profili ve bir kişisel profil, iki utun aygıtı da bulunur ve yalnızca biri işe yarar. Bayt sayaçları soruyu çözer: sayaçları not edin, bir sayfa yükleyin veya küçük bir aktarım başlatın ve hangisinin hareket ettiğini görün.

netstat -ib | grep utun

Numarayı kararlı saymayın. Yeniden bağlanma aynı tünele başka bir utun adı verebilir ve bir iCloud veya Continuity hizmeti utun0'ı VPN'iniz bağlanmadan çok önce tutabilir.

Bağlamayı tünelin kapsamına uygun hale getirin

Alan bir aygıtı bağlar ve yaptığı tek şey budur. VPN, 0.0.0.0/0'ı utun içine yönlendiren tam bir tünel ise, o aygıta bağlama her eş bağlantısını ve her izleyici isteğini VPN üzerinden gönderir. VPN yalnızca birkaç alt ağı yönlendiren bölünmüş bir tünel ise, utun'a bağlama eş trafiğini o eşler için rotası olmayan bir aygıta gönderir ve aktarımlar sızmak yerine durur. İki sonuç da Any Interface'ten daha güvenlidir, ancak yalnızca biri istemciyi çalışır durumda tutar. İstemci dışında hiçbir şey değişmez: tarayıcılar ve diğer uygulamalar kendi rotalarını korur, bu yüzden her uygulamayı kapsayan bir gereksinim VPN tarafından uygulanmalıdır.

Bir şey seçmeden önce durumu okuyun:

Adres ailesi de önemlidir. Yalnızca IPv4 atayan bir sağlayıcı, bağlı arayüzü IPv6 adresi olmadan bırakır, bu yüzden IPv6 eşleri Wi-Fi üzerinden sızmak yerine başarısız olur. Ayrıca, soketleri bağlamak ad çözümlemesini sabitlemez: izleyici ana bilgisayar adları macOS çözümleyicisi üzerinden çözülür, o da seçilen aygıtı değil sistemin DNS yapılandırmasını izler.

Doğru görünen bir seçimin başarısız olduğu üç yol

İlk başarısızlık yeniden başlatmamaktır. Alan utun4 gösterir, tercihler yapılandırılmış görünür ve bir test aktarımı hâlâ Wi-Fi üzerinden çıkar çünkü çalışan oturum eski bağlamayı korumuştur. Tamamen kapatın, pgrep ile doğrulayın, yeniden açın ve aktarımı yeniden başlatın.

İkincisi yeniden bağlanmadan sonraki eski addır. Bağlı aygıt kaybolduğunda eş bağlantıları başarısız olur ve istemci, arayüzün gittiğine dair net bir mesaj yerine izleyici hataları bildirme eğilimindedir, bu da ölü bir torrent gibi okunur. ifconfig'i yeniden okuyun, yeni adı seçin ve yeniden başlatın.

Üçüncüsü bağlamanın kapalı biçimde başarısız olduğunu varsaymaktır. Bir arayüz seçmek sistemden soketleri bir aygıt adına iliştirmesini ister; bu ad eksik olduğunda veya geri dönüştürüldüğünde ne olacağını ayarlar ekranı garanti etmez. Sonraki bölümdeki bağlantı kesme testi sayılan tek kanıttır.

Gerçek bir aktarım ve bağlantı kesmeyle doğrulayın

Çalıştırmanıza izin verilen bir aktarım kullanın, örneğin bir Linux dağıtım imajı, ve VPN bağlıyken başlatın. Önce ve sonra arayüz başına sayaçları izleyin ve VPN istemcisinin kendi veri sayacıyla karşılaştırın; eş listesi dolarken ikisi birlikte yükselmelidir.

netstat -ib | grep utun
pgrep -fl qbittorrent

Sonra VPN'i kendi arayüzünden ayırın ve aktarımı izleyin. Eşler kaybolmalı ve tünel düştükten kısa süre sonra yeni bağlantılar başarısız olmalıdır. Hız devam ediyorsa bağlama yürürlükte değildir ve güvenlik duvarında değil, yeniden başlatma adımına dönmüşsünüzdür.

Yeniden bağlanın ve seçilen adı bir kez daha kontrol edin, çünkü tünel başka bir utun altında geri gelebilir. Tünel türünü, arayüz adını ve VPN düştüğünde beklenen davranışı kaydeden kısa bir not sonraki oturumu kurtarır: bu ayar makine başına ve sağlayıcı başınadır ve ne istemci güncellemesine ne de VPN uygulaması değişikliğine dayanır.