qBittorrent unter macOS an ein VPN-Interface binden

Ich öffnete qBittorrent auf einem Mac mini, stellte Network Interface auf utun4, startete neu und verbrachte dann einen Nachmittag damit, zuzusehen, wie ein Torrent bei der Metadaten-Abfrage stehen blieb, während das VPN weiterhin eine gesunde Verbindung meldete. Die Einstellung war im Prinzip nicht falsch; der Name war veraltet. macOS vergibt utun-Nummern, wenn Dienste starten, deshalb zeigte das utun4, das eine Woche zuvor korrekt gewesen war, auf einen Tunnel, den es nicht mehr gab, und der Client band seine Sockets an ein Gerät ohne Route. Die folgende Reihenfolge nutze ich heute: das Interface am laufenden Tunnel ablesen, im Client auswählen, die Sitzung neu starten und die Bindung dann mit einem Transfer und einer bewussten Trennung belegen.

Erweitert öffnen und das Interface-Feld finden

Öffnen Sie im qBittorrent-Fenster die Einstellungen mit Cmd+, und gehen Sie auf die Seite Erweitert. Network Interface ist das entscheidende Feld: Es listet die Interface-Namen des Systems auf und steht standardmäßig auf Any Interface, das heißt, das Betriebssystem wählt für jeden Socket, den der Client öffnet, eine Route aus. Die Optionsreferenz des Projekts dokumentiert dieses Feld und diesen Standardwert, und es ist auf jeder Plattform dieselbe Einstellung, auch wenn die Namen darin andere sind.

Zwei Details bringen hier viele ins Stolpern. Die Liste zeigt Gerätenamen wie en0, en1 und utun0 bis utun9, nie den Produktnamen des VPN-Anbieters, deshalb brauchen Sie die Zuordnung, bevor Sie etwas Sinnvolles auswählen können. Und die Auswahl wird beim Start der BitTorrent-Sitzung angewendet, nicht in dem Moment, in dem Sie OK drücken, sodass eine Änderung, die gespeichert aussieht, möglicherweise noch auf der alten Bindung läuft.

Beenden Sie die Anwendung richtig mit Cmd+Q und prüfen Sie, dass der Prozess weg ist, bevor Sie sie erneut öffnen. Das Fenster zu schließen blendet es nur aus, und ein ausgeblendeter Client behält seine Sitzung, seinen Listening-Port und sein altes Interface.

pgrep -fl qbittorrent

Das Interface finden, das Ihr VPN wirklich besitzt

Stellen Sie zuerst die VPN-Verbindung her, über den eigenen Client des Anbieters, und lesen Sie dann die Sicht des Systems statt des Menüs im Client. Die folgenden Befehle listen jedes Interface mit seinen Adressen auf, zeigen, welche das System als aktiv betrachtet, und geben die Routing-Tabelle aus; Sie suchen das utun-Gerät, das den privaten Bereich trägt, den Ihr Anbieter vergibt.

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

Drei Lesarten sagen Ihnen, welches Gerät der Tunnel ist. Der utun-Eintrag braucht eine inet-Adresse, die zum Pool des VPN gehört. scutil --nwi zeigt, welche Interfaces das System als aktiv ansieht und welches das primäre ist. netstat -rn zeigt, wohin die Standardroute zeigt, und wenn diese Route weiter auf en0 zeigt, während ein utun eine Adresse hat, trägt der Tunnel nicht den gesamten Verkehr, was ändert, was die Bindung später bewirkt.

Wenn zwei Tunnel gleichzeitig existieren können, etwa ein Arbeitsprofil und ein privates, sind beide utun-Geräte vorhanden und nur eines davon ist nützlich. Byte-Zähler klären die Frage: Notieren Sie die Zähler, laden Sie eine Seite oder starten Sie einen kleinen Transfer und sehen Sie, welcher sich bewegt hat.

netstat -ib | grep utun

Halten Sie die Nummer auch nicht für stabil. Eine neue Verbindung kann demselben Tunnel einen anderen utun-Namen geben, und ein iCloud- oder Continuity-Dienst kann utun0 lange vor Ihrer VPN-Verbindung belegen.

Die Bindung an den Umfang des Tunnels anpassen

Das Feld bindet ein Gerät, und mehr tut es nicht. Ist das VPN ein Full Tunnel, der 0.0.0.0/0 in das utun routet, schickt die Bindung an dieses Gerät jede Peer-Verbindung und jede Tracker-Anfrage durch das VPN. Ist das VPN ein Split Tunnel, der nur wenige Subnetze routet, schickt die Bindung an das utun den Peer-Verkehr an ein Gerät ohne Route für diese Peers, und Transfers bleiben stehen, statt zu leaken. Beide Ergebnisse sind sicherer als Any Interface, aber nur eines davon hält den Client funktionsfähig. Außerhalb des Clients ändert sich nichts: Browser und andere Apps behalten ihre eigenen Routen, eine Vorgabe für jede Anwendung braucht also Durchsetzung von der VPN-Seite.

Lesen Sie die Lage, bevor Sie etwas auswählen:

Auch die Adressfamilie zählt. Ein Anbieter, der nur IPv4 vergibt, lässt das gebundene Interface ohne IPv6-Adresse, sodass IPv6-Peers scheitern, statt über WLAN hinauszurutschen. Unabhängig davon legt das Binden von Sockets die Namensauflösung nicht fest: Tracker-Hostnamen werden über den Resolver von macOS aufgelöst, der der DNS-Konfiguration des Systems folgt und nicht dem ausgewählten Gerät.

Drei Arten, wie eine scheinbar korrekte Auswahl scheitert

Der erste Fehler ist, nicht neu zu starten. Das Feld zeigt utun4, die Einstellungen sehen konfiguriert aus, und ein Testtransfer geht trotzdem über WLAN hinaus, weil die laufende Sitzung die alte Bindung behalten hat. Vollständig beenden, mit pgrep prüfen, neu öffnen und den Transfer erneut starten.

Der zweite ist der veraltete Name nach einer neuen Verbindung. Sobald das gebundene Gerät verschwindet, scheitern Peer-Verbindungen, und der Client meldet eher Tracker-Fehler als eine saubere Meldung, dass das Interface weg ist, was wie ein toter Torrent aussieht. ifconfig erneut lesen, den neuen Namen auswählen und neu starten.

Der dritte ist die Annahme, die Bindung scheitere geschlossen. Ein Interface auszuwählen bittet das System, Sockets an einen Gerätenamen zu hängen; was passiert, wenn dieser Name fehlt oder wiederverwendet wird, garantiert der Einstellungsdialog nicht. Der Trennungstest im nächsten Abschnitt ist der einzige Beleg, der zählt.

Mit einem echten Transfer und einer Trennung prüfen

Nutzen Sie einen Transfer, den Sie ausführen dürfen, etwa ein Linux-Distributionsimage, und starten Sie ihn bei verbundenem VPN. Beobachten Sie die Zähler pro Interface davor und danach und vergleichen Sie sie mit dem Datenzähler des VPN-Clients; beide sollten gemeinsam steigen, während sich die Peer-Liste füllt.

netstat -ib | grep utun
pgrep -fl qbittorrent

Trennen Sie dann das VPN über seine eigene Oberfläche und beobachten Sie den Transfer. Peers sollten verschwinden, und neue Verbindungen sollten kurz nach dem Ausfall des Tunnels scheitern. Läuft der Durchsatz weiter, wirkt die Bindung nicht, und Sie sind wieder beim Neustart-Schritt, nicht bei der Firewall.

Verbinden Sie neu und prüfen Sie den gewählten Namen erneut, denn der Tunnel kann unter einem anderen utun zurückkommen. Eine kurze Notiz mit Tunneltyp, Interface-Namen und dem erwarteten Verhalten beim VPN-Abbau erspart die nächste Sitzung: Diese Einstellung gilt pro Rechner und pro Anbieter, und sie übersteht weder ein Client-Upgrade noch einen Wechsel der VPN-App.