Sådan binder du qBittorrent til en VPN-grænseflade på macOS

Jeg åbnede qBittorrent på en Mac mini, satte Network Interface til utun4, genstartede og brugte derefter en eftermiddag på at se en torrent hænge på at hente metadata, mens VPN'en stadig viste en sund forbindelse. Indstillingen var ikke forkert i princippet; navnet var forældet. macOS tildeler utun-numre, når tjenester starter, så det utun4, der havde været korrekt ugen før, pegede på en tunnel, der ikke længere fandtes, og klienten bandt sine sockets til en enhed uden rute. Rækkefølgen nedenfor er den, jeg bruger nu: læs grænsefladen fra den kørende tunnel, vælg den i klienten, genstart sessionen, og bevis derefter bindingen med en overførsel og en bevidst afbrydelse.

Åbn Avanceret, og find grænsefladefeltet

I qBittorrent-vinduet åbner du Indstillinger med Cmd+, og går til siden Avanceret. Network Interface er feltet, der betyder noget: det viser systemets grænsefladenavne og står som standard på Any Interface, hvilket betyder, at styresystemet vælger en rute for hver socket, klienten åbner. Projektets oversigt over indstillinger dokumenterer feltet og den standard, og det er den samme indstilling på alle platforme, selv om navnene i den ikke er ens.

To detaljer får folk til at falde her. Listen viser enhedsnavne som en0, en1 og utun0 til utun9, aldrig VPN-udbyderens produktnavn, så du har brug for koblingen, før du kan vælge noget fornuftigt. Og valget anvendes, når BitTorrent-sessionen starter, ikke i det øjeblik du trykker OK, så en ændring, der ser gemt ud, kan stadig køre på den gamle binding.

Afslut programmet ordentligt med Cmd+Q, og bekræft, at processen er væk, før du åbner det igen. At lukke vinduet skjuler det blot, og en skjult klient beholder sin session, sin lyttende port og sin gamle grænseflade.

pgrep -fl qbittorrent

Find den grænseflade, din VPN faktisk ejer

Tilslut VPN'en først via udbyderens egen klient, og læs derefter systemets syn i stedet for klientens menu. Kommandoerne nedenfor viser hver grænseflade med dens adresser, viser hvilke systemet anser for aktive, og udskriver rutetabellen; du leder efter den utun-enhed, der bærer det private interval, din udbyder tildeler.

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

Tre aflæsninger fortæller dig, hvilken enhed der er tunnelen. utun-posten skal have en inet-adresse, der hører til VPN'ens pulje. scutil --nwi viser, hvilke grænseflader systemet anser for aktive, og hvilken der er primær. netstat -rn viser, hvor standardruten peger, og hvis den rute stadig peger på en0, mens en utun har en adresse, bærer tunnelen ikke al trafik, hvilket ændrer, hvad bindingen senere gør.

Når to tunneler kan eksistere samtidig, for eksempel en arbejdsprofil og en personlig, er begge utun-enheder til stede, og kun den ene er nyttig. Byttetællere afgør spørgsmålet: noter tællerne, indlæs en side eller start en lille overførsel, og se hvilken der flyttede sig.

netstat -ib | grep utun

Betragt heller ikke nummeret som stabilt. En genopkobling kan give den samme tunnel et andet utun-navn, og en iCloud- eller Continuity-tjeneste kan holde utun0 længe før din VPN opretter forbindelse.

Tilpas bindingen til tunnelens omfang

Feltet binder en enhed, og det er alt, det gør. Hvis VPN'en er en fuld tunnel, der ruter 0.0.0.0/0 ind i utun'en, sender binding til den enhed hver peer-forbindelse og hver tracker-anmodning gennem VPN'en. Hvis VPN'en er en delt tunnel, der kun ruter få subnets, sender binding til utun'en peer-trafik til en enhed uden rute til disse peers, og overførsler stopper i stedet for at lække. Begge udfald er sikrere end Any Interface, men kun det ene holder klienten kørende. Intet uden for klienten ændres: browsere og andre apps beholder deres egne ruter, så et krav, der dækker alle programmer, skal håndhæves fra VPN-siden.

Læs situationen, før du vælger noget:

Adressefamilien betyder også noget. En udbyder, der kun tildeler IPv4, efterlader den bundne grænseflade uden IPv6-adresse, så IPv6-peers fejler i stedet for at smutte ud over Wi-Fi. Separat fastlåser binding af sockets ikke navneopløsning: tracker-værtsnavne opløses gennem macOS' resolver, som følger systemets DNS-konfiguration og ikke den valgte enhed.

Tre måder, en korrekt udseende valg fejler på

Den første fejl er ikke at genstarte. Feltet viser utun4, indstillingerne ser konfigurerede ud, og en testoverførsel forlader alligevel over Wi-Fi, fordi den kørende session beholdt den gamle binding. Afslut helt, bekræft med pgrep, åbn igen, og start overførslen igen.

Den anden er det forældede navn efter en genopkobling. Når den bundne enhed forsvinder, fejler peer-forbindelser, og klienten har tendens til at rapportere tracker-fejl i stedet for en ren besked om, at grænsefladen er væk, hvilket lyder som en død torrent. Læs ifconfig igen, vælg det nye navn, og genstart.

Den tredje er at antage, at bindingen fejler lukket. At vælge en grænseflade beder systemet om at knytte sockets til et enhedsnavn; hvad der sker, når det navn mangler eller genbruges, garanterer indstillingsskærmen ikke. Afbrydelsestesten i næste afsnit er det eneste bevis, der tæller.

Verificer med en rigtig overførsel og en afbrydelse

Brug en overførsel, du har lov til at køre, som et Linux-distributionsimage, og start den med VPN'en tilsluttet. Se tællerne pr. grænseflade før og efter, og sammenlign dem med VPN-klientens egen datatæller; begge bør stige sammen, mens peer-listen fyldes.

netstat -ib | grep utun
pgrep -fl qbittorrent

Afbryd derefter VPN'en fra dens egen grænseflade, og se overførslen. Peers bør forsvinde, og nye forbindelser bør fejle kort efter, at tunnelen går ned. Hvis gennemstrømningen fortsætter, er bindingen ikke i kraft, og du er tilbage ved genstarts-trinnet, ikke ved firewallingen.

Genopkobl, og tjek det valgte navn igen, for tunnelen kan komme tilbage under en anden utun. En kort note med tunneltype, grænsefladenavn og den forventede adfærd, når VPN'en falder, sparer den næste session: denne indstilling er pr. maskine og pr. udbyder, og den overlever hverken en klientopgradering eller et skift af VPN-app.