Am deschis qBittorrent pe un Mac mini, am setat Network Interface pe utun4, am repornit și apoi am petrecut o după-amiază urmărind un torrent blocat la obținerea metadatelor în timp ce VPN-ul arăta în continuare o conexiune sănătoasă. Setarea nu era greșită în principiu; numele era învechit. macOS atribuie numere utun la pornirea serviciilor, așa că utun4 care fusese corect săptămâna trecută indica un tunel care nu mai exista, iar clientul își lega socketurile de un dispozitiv fără rută. Secvența de mai jos este cea pe care o folosesc acum: citiți interfața din tunelul care rulează, selectați-o în client, reporniți sesiunea și apoi demonstrați legarea printr-un transfer și o deconectare deliberată.

Deschideți Avansat și găsiți câmpul de interfață

În fereastra qBittorrent, deschideți Preferințe cu Cmd+, și mergeți la pagina Avansat. Network Interface este câmpul care contează: listează numele interfețelor sistemului și implicit stă pe Any Interface, ceea ce înseamnă că sistemul de operare alege o rută pentru fiecare socket deschis de client. referința opțiunilor proiectului documentează acest câmp și acea valoare implicită, și este aceeași setare pe fiecare platformă, deși numele din ea nu sunt aceleași.

Două detalii îi încurcă aici pe oameni. Lista arată nume de dispozitive precum en0, en1 și utun0 până la utun9, niciodată numele produsului furnizorului de VPN, așa că aveți nevoie de corespondență înainte de a alege ceva rezonabil. Iar selecția se aplică la pornirea sesiunii BitTorrent, nu în momentul în care apăsați OK, așa că o modificare care pare salvată poate rula încă pe legarea veche.

Închideți aplicația corect cu Cmd+Q și confirmați că procesul a dispărut înainte de a o redeschide. Închiderea ferestrei doar o ascunde, iar un client ascuns își păstrează sesiunea, portul de ascultare și interfața veche.

pgrep -fl qbittorrent

Găsiți interfața pe care VPN-ul dvs. o deține cu adevărat

Conectați mai întâi VPN-ul, prin clientul propriu al furnizorului, apoi citiți vederea sistemului în locul meniului clientului. Comenzile de mai jos listează fiecare interfață cu adresele ei, arată pe care sistemul le consideră active și tipăresc tabela de rutare; căutați dispozitivul utun care transportă intervalul privat pe care vi-l atribuie furnizorul.

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

Trei citiri vă spun care dispozitiv este tunelul. Intarea utun are nevoie de o adresă inet care aparține pool-ului VPN-ului. scutil --nwi arată ce interfețe consideră sistemul active și care este primară. netstat -rn arată unde indică ruta implicită, iar dacă acea rută indică în continuare en0 în timp ce un utun are adresă, tunelul nu transportă tot traficul, ceea ce schimbă ce va face legarea mai târziu.

Când pot exista două tuneluri simultan, de exemplu un profil de lucru și unul personal, ambele dispozitive utun sunt prezente și doar unul este util. Contoarele de octeți decid întrebarea: notați contoarele, încărcați o pagină sau porniți un transfer mic și vedeți care s-a mișcat.

netstat -ib | grep utun

Nu considerați numărul stabil. O reconectare poate da aceluiași tunel un alt nume utun, iar un serviciu iCloud sau Continuity poate ține utun0 cu mult înainte ca VPN-ul dvs. să se conecteze.

Potriviți legarea cu sfera tunelului

Câmpul leagă un dispozitiv, și atât face. Dacă VPN-ul este un tunel complet care rutează 0.0.0.0/0 în utun, legarea la acel dispozitiv trimite fiecare conexiune peer și fiecare cerere tracker prin VPN. Dacă VPN-ul este un tunel divizat care rutează doar câteva subrețele, legarea la utun trimite traficul peer către un dispozitiv fără rută pentru acei peeri, iar transferurile se opresc în loc să scurgă. Ambele rezultate sunt mai sigure decât Any Interface, dar doar unul menține clientul funcțional. Nimic din afara clientului nu se schimbă: browserele și alte aplicații își păstrează propriile rute, așa că o cerință care acoperă toate aplicațiile trebuie impusă din partea VPN-ului.

Citiți situația înainte de a selecta ceva:

What you seeWhat it means for the bind
A utun with a provider address and the default route pointing at itFull tunnel; the bind covers peer and tracker traffic
A utun with a provider address but the default route still on en0Split tunnel; the bind will stall transfers unless the provider routes 0.0.0.0/0
No utun carrying a provider addressThe VPN is down or connects on demand; bring it up before selecting
A utun number that changed since the last sessionThe saved name is stale; reselect and restart

Familia de adrese contează și ea. Un furnizor care atribuie doar IPv4 lasă interfața legată fără adresă IPv6, așa că peerii IPv6 eșuează în loc să se strecoare prin Wi-Fi. Separat, legarea socketurilor nu fixează rezolvarea numelor: numele gazdă ale trackerelor sunt rezolvate prin resolverul macOS, care urmează configurația DNS a sistemului și nu dispozitivul selectat.

Trei moduri în care o selecție care pare corectă eșuează

Primul eșec este să nu reporniți. Câmpul arată utun4, preferințele par configurate, iar un transfer de test tot iese prin Wi-Fi pentru că sesiunea care rulează a păstrat legarea veche. Închideți complet, confirmați cu pgrep, redeschideți și porniți din nou transferul.

Al doilea este numele învechit după o reconectare. Imediat ce dispozitivul legat dispare, conexiunile peer eșuează, iar clientul tinde să raporteze erori de tracker în locul unui mesaj clar că interfața a dispărut, ceea ce se citește ca un torrent mort. Recitiți ifconfig, selectați noul nume și reporniți.

Al treilea este să presupuneți că legarea eșuează închis. Selectarea unei interfețe cere sistemului să atașeze socketuri la un nume de dispozitiv; ce se întâmplă când acel nume lipsește sau este reciclat nu garantează ecranul de setări. Testul de deconectare din secțiunea următoare este singura dovadă care contează.

Verificați cu un transfer real și o deconectare

Folosiți un transfer pe care aveți voie să îl rulați, cum ar fi o imagine de distribuție Linux, și porniți-l cu VPN-ul conectat. Urmăriți contoarele pe interfață înainte și după și comparați-le cu contorul de date al clientului VPN; ambele ar trebui să crească împreună în timp ce lista de peeri se umple.

netstat -ib | grep utun
pgrep -fl qbittorrent

Apoi deconectați VPN-ul din propria interfață și urmăriți transferul. Peerii ar trebui să dispară, iar conexiunile noi ar trebui să eșueze la scurt timp după căderea tunelului. Dacă debitul continuă, legarea nu este în vigoare și sunteți din nou la pasul de repornire, nu la firewall.

Reconectați-vă și verificați din nou numele selectat, pentru că tunelul poate reveni sub alt utun. O notă scurtă cu tipul tunelului, numele interfeței și comportamentul așteptat când VPN-ul cade economisește sesiunea următoare: această setare este pe mașină și pe furnizor și nu supraviețuiește nici unei actualizări a clientului, nici unei schimbări de aplicație VPN.

Articole similare