qBittorrent aan een VPN-interface koppelen op macOS

Ik opende qBittorrent op een Mac mini, zette Network Interface op utun4, herstartte en bracht vervolgens een middag door met kijken hoe een torrent bleef hangen bij het ophalen van metadata terwijl de VPN nog steeds een gezonde verbinding toonde. De instelling was principieel niet fout; de naam was verouderd. macOS deelt utun-nummers uit wanneer diensten starten, dus de utun4 die een week eerder correct was, wees naar een tunnel die niet meer bestond, en de client bond zijn sockets aan een apparaat zonder route. De volgorde hieronder is wat ik nu gebruik: lees de interface van de actieve tunnel, selecteer hem in de client, herstart de sessie en bewijs de binding daarna met een overdracht en een bewuste verbindingsverbreking.

Open Geavanceerd en zoek het interfaceveld

Open in het qBittorrent-venster de Voorkeuren met Cmd+, en ga naar de pagina Geavanceerd. Network Interface is het veld dat ertoe doet: het toont de interfacenamen van het systeem en staat standaard op Any Interface, wat betekent dat het besturingssysteem voor elke socket die de client opent een route kiest. De optiereferentie van het project documenteert dat veld en die standaard, en het is dezelfde instelling op elk platform, ook al zijn de namen erin dat niet.

Twee details laten mensen hier struikelen. De lijst toont apparaatnamen zoals en0, en1 en utun0 tot utun9, nooit de productnaam van de VPN-provider, dus je hebt de koppeling nodig voordat je iets verstandigs kunt kiezen. En de selectie wordt toegepast wanneer de BitTorrent-sessie start, niet op het moment dat je op OK drukt, dus een wijziging die opgeslagen lijkt, kan nog op de oude binding draaien.

Sluit de toepassing netjes af met Cmd+Q en controleer of het proces weg is voordat je hem opnieuw opent. Het venster sluiten verbergt het alleen, en een verborgen client houdt zijn sessie, zijn luisterende poort en zijn oude interface.

pgrep -fl qbittorrent

Zoek de interface die je VPN echt bezit

Verbind eerst de VPN via de eigen client van de provider en lees daarna de weergave van het systeem in plaats van het menu van de client. De opdrachten hieronder tonen elke interface met zijn adressen, laten zien welke het systeem als actief beschouwt en drukken de routetabel af; je zoekt het utun-apparaat dat de privéreeks draagt die je provider uitgeeft.

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

Drie uitlezingen vertellen je welk apparaat de tunnel is. De utun-regel heeft een inet-adres nodig dat bij de pool van de VPN hoort. scutil --nwi laat zien welke interfaces het systeem als actief beschouwt en welke primair is. netstat -rn laat zien waar de standaardroute naartoe wijst, en als die route nog naar en0 wijst terwijl een utun een adres heeft, draagt de tunnel niet al het verkeer, wat verandert wat de binding later doet.

Wanneer er twee tunnels tegelijk kunnen bestaan, bijvoorbeeld een werkprofiel en een persoonlijk profiel, zijn beide utun-apparaten aanwezig en is er maar één nuttig. Bytetellers beslechten de vraag: noteer de tellers, laad een pagina of start een kleine overdracht en kijk welke is opgeschoven.

netstat -ib | grep utun

Beschouw het nummer ook niet als stabiel. Een herverbinding kan dezelfde tunnel een andere utun-naam geven, en een iCloud- of Continuity-dienst kan utun0 al lang vasthouden voordat je VPN verbindt.

Stem de binding af op de reikwijdte van de tunnel

Het veld bindt een apparaat, en dat is alles wat het doet. Als de VPN een volledige tunnel is die 0.0.0.0/0 in de utun routeert, stuurt binding aan dat apparaat elke peerverbinding en elk trackerverzoek via de VPN. Als de VPN een gesplitste tunnel is die slechts enkele subnetten routeert, stuurt binding aan de utun het peerverkeer naar een apparaat zonder route voor die peers, en overdrachten stoppen in plaats van te lekken. Beide uitkomsten zijn veiliger dan Any Interface, maar slechts één ervan houdt de client werkend. Niets buiten de client verandert: browsers en andere apps behouden hun eigen routes, dus een eis die elke toepassing dekt, moet van de VPN-kant worden afgedwongen.

Lees de situatie voordat je iets selecteert:

De adresfamilie is ook van belang. Een provider die alleen IPv4 uitgeeft, laat de gebonden interface zonder IPv6-adres, dus IPv6-peers falen in plaats van via Wi-Fi naar buiten te glippen. Los daarvan legt het binden van sockets de naamresolutie niet vast: tracker-hostnamen worden opgelost via de resolver van macOS, die de DNS-configuratie van het systeem volgt en niet het geselecteerde apparaat.

Drie manieren waarop een correct lijkende selectie faalt

De eerste fout is niet herstarten. Het veld toont utun4, de voorkeuren lijken geconfigureerd, en een testoverdracht gaat toch via Wi-Fi naar buiten omdat de lopende sessie de oude binding behield. Sluit volledig af, controleer met pgrep, open opnieuw en start de overdracht opnieuw.

De tweede is de verouderde naam na een herverbinding. Zodra het gebonden apparaat verdwijnt, falen peerverbindingen en meldt de client eerder trackerfouten dan een duidelijke melding dat de interface weg is, wat als een dode torrent leest. Lees ifconfig opnieuw, selecteer de nieuwe naam en herstart.

De derde is aannemen dat de binding gesloten faalt. Een interface selecteren vraagt het systeem om sockets aan een apparaatnaam te koppelen; wat er gebeurt als die naam ontbreekt of wordt hergebruikt, garandeert het instellingenscherm niet. De verbindingsverbrekingstest in de volgende paragraaf is het enige bewijs dat telt.

Verifieer met een echte overdracht en een verbindingsverbreking

Gebruik een overdracht die je mag uitvoeren, zoals een Linux-distributie-image, en start die met de VPN verbonden. Kijk naar de tellers per interface voor en na en vergelijk ze met de eigen datateller van de VPN-client; beide zouden samen moeten stijgen terwijl de peerlijst volloopt.

netstat -ib | grep utun
pgrep -fl qbittorrent

Verbreek daarna de VPN vanuit zijn eigen interface en kijk naar de overdracht. Peers zouden moeten wegvallen, en nieuwe verbindingen zouden kort na het wegvallen van de tunnel moeten falen. Als de doorvoer doorgaat, is de binding niet actief en ben je terug bij de herstartstap, niet bij de firewall.

Verbind opnieuw en controleer de geselecteerde naam nog eens, want de tunnel kan onder een andere utun terugkomen. Een korte notitie met het tunneltype, de interfacenaam en het verwachte gedrag wanneer de VPN wegvalt, bespaart de volgende sessie: deze instelling is per machine en per provider, en ze overleeft noch een clientupgrade noch een wissel van VPN-app.