Avasin qBittorrentin Mac minissä, asetin Network Interfacen arvoon utun4, käynnistin uudelleen ja vietin sitten iltapäivän katsellen, kun torrent jäi odottamaan metatietojen hakua samalla kun VPN näytti edelleen tervettä yhteyttä. Asetus ei ollut periaatteessa väärä; nimi oli vanhentunut. macOS antaa utun-numerot palvelujen käynnistyessä, joten utun4, joka oli ollut oikein edellisellä viikolla, osoitti tunneliin, jota ei enää ollut, ja asiakas sitoi pistokkeensa laitteeseen, jolla ei ollut reittiä. Alla oleva järjestys on se, mitä käytän nyt: lue liitäntä käynnissä olevasta tunnelista, valitse se asiakkaassa, käynnistä istunto uudelleen ja todista sitten sidonta siirrolla ja tarkoituksellisella katkaisulla.

Avaa Lisäasetukset ja etsi liitäntäkenttä

Avaa qBittorrentin ikkunassa Asetukset näppäinyhdistelmällä Cmd+, ja siirry Lisäasetukset-sivulle. Network Interface on se kenttä, jolla on merkitystä: se luettelee järjestelmän liitäntänimet ja on oletuksena Any Interface, mikä tarkoittaa, että käyttöjärjestelmä valitsee reitin jokaiselle pistokkeelle, jonka asiakas avaa. Projektin asetusviite dokumentoi kentän ja tämän oletuksen, ja se on sama asetus kaikilla alustoilla, vaikka sen sisältämät nimet eivät ole samoja.

Kaksi yksityiskohtaa kompastuttaa ihmisiä tässä. Luettelo näyttää laitenimiä kuten en0, en1 ja utun0–utun9, ei koskaan VPN-palveluntarjoajan tuotenimeä, joten tarvitset kohdistuksen ennen kuin voit valita mitään järkevää. Ja valinta otetaan käyttöön, kun BitTorrent-istunto alkaa, ei sillä hetkellä kun painat OK, joten tallennetulta näyttävä muutos voi yhä toimia vanhalla sidonnalla.

Sulje sovellus kunnolla näppäinyhdistelmällä Cmd+Q ja varmista, että prosessi on poissa ennen kuin avaat sen uudelleen. Ikkunan sulkeminen vain piilottaa sen, ja piilotettu asiakas pitää istuntonsa, kuunteluporttinsa ja vanhan liitäntänsä.

pgrep -fl qbittorrent

Etsi liitäntä, jonka VPN todella omistaa

Yhdistä ensin VPN palveluntarjoajan oman asiakkaan kautta ja lue sitten järjestelmän näkemys asiakkaan valikon sijaan. Alla olevat komennot luettelevat jokaisen liitännän osoitteineen, näyttävät mitkä järjestelmä katsoo aktiivisiksi ja tulostavat reititystaulukon; etsit utun-laitetta, joka kantaa palveluntarjoajasi antamaa yksityistä aluetta.

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

Kolme lukemaa kertovat, mikä laite on tunneli. utun-merkintä tarvitsee inet-osoitteen, joka kuuluu VPN:n pooliin. scutil --nwi näyttää, mitkä liitännät järjestelmä katsoo aktiivisiksi ja mikä on ensisijainen. netstat -rn näyttää, mihin oletusreitti osoittaa, ja jos se reitti osoittaa yhä en0:aan samalla kun utunilla on osoite, tunneli ei kanna kaikkea liikennettä, mikä muuttaa sitä, mitä sidonta myöhemmin tekee.

Kun kaksi tunnelia voi olla olemassa yhtä aikaa, esimerkiksi työprofiili ja henkilökohtainen, molemmat utun-laitteet ovat läsnä ja vain toinen niistä on hyödyllinen. Tavulaskurit ratkaisevat kysymyksen: kirjaa laskurit, lataa sivu tai aloita pieni siirto ja katso, kumpi liikkui.

netstat -ib | grep utun

Älä pidä numeroa vakaana. Uudelleenyhdistäminen voi antaa samalle tunnelille eri utun-nimen, ja iCloud- tai Continuity-palvelu voi pitää utun0:aa kauan ennen kuin VPN yhdistyy.

Sovita sidonta tunnelin laajuuteen

Kenttä sitoo laitteen, ja se on kaikki mitä se tekee. Jos VPN on täystunneli, joka reitittää 0.0.0.0/0 utuniin, sidonta siihen laitteeseen lähettää jokaisen vertaisyhteyden ja jokaisen tracker-pyynnön VPN:n kautta. Jos VPN on jaettu tunneli, joka reitittää vain muutaman aliverkon, sidonta utuniin lähettää vertaisliikenteen laitteeseen, jolla ei ole reittiä näille vertaisille, ja siirrot pysähtyvät vuotamisen sijaan. Molemmat tulokset ovat turvallisempia kuin Any Interface, mutta vain toinen pitää asiakkaan toimivana. Mikään asiakkaan ulkopuolella ei muutu: selaimet ja muut sovellukset pitävät omat reittinsä, joten kaikki sovellukset kattava vaatimus on pakotettava VPN:n puolelta.

Lue tilanne ennen kuin valitset mitään:

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

Osoiteperheellä on myös merkitystä. Palveluntarjoaja, joka antaa vain IPv4:n, jättää sidotun liitännän ilman IPv6-osoitetta, joten IPv6-vertaiset epäonnistuvat sen sijaan että luiskahtaisivat ulos Wi-Fin kautta. Erillisenä asiana: pistokkeiden sitominen ei kiinnitä nimien selvitystä: tracker-isäntänimet selvitetään macOS:n selvittimen kautta, joka noudattaa järjestelmän DNS-asetuksia eikä valittua laitetta.

Kolme tapaa, joilla oikealta näyttävä valinta epäonnistuu

Ensimmäinen epäonnistuminen on uudelleenkäynnistyksen puute. Kenttä näyttää utun4:n, asetukset näyttävät määritetyiltä, ja testisiirto lähtee silti Wi-Fin kautta, koska käynnissä oleva istunto piti vanhan sidonnan. Sulje kokonaan, varmista pgrepillä, avaa uudelleen ja aloita siirto uudelleen.

Toinen on vanhentunut nimi uudelleenyhdistämisen jälkeen. Kun sidottu laite katoaa, vertaisyhteydet epäonnistuvat ja asiakas ilmoittaa yleensä tracker-virheitä puhtaan liitäntä-kadonnut-viestin sijaan, mikä näyttää kuolleelta torrentilta. Lue ifconfig uudelleen, valitse uusi nimi ja käynnistä uudelleen.

Kolmas on olettaa, että sidonta epäonnistuu suljetusti. Liitännän valitseminen pyytää järjestelmää liittämään pistokkeet laitenimeen; mitä tapahtuu, kun nimi puuttuu tai kierrätetään, ei asetusnäyttö takaa. Seuraavan osan katkaisutesti on ainoa todiste, jolla on merkitystä.

Vahvista oikealla siirrolla ja katkaisulla

Käytä siirtoa, jonka saat suorittaa, esimerkiksi Linux-jakelun levykuvaa, ja käynnistä se VPN:n ollessa yhdistettynä. Tarkkaile liitäntäkohtaisia laskureita ennen ja jälkeen ja vertaa niitä VPN-asiakkaan omaan datalaskuriin; molempien pitäisi nousta yhdessä vertaisluettelon täyttyessä.

netstat -ib | grep utun
pgrep -fl qbittorrent

Katkaise sitten VPN sen omasta liitännästä ja tarkkaile siirtoa. Vertaisten pitäisi kadota ja uusien yhteyksien epäonnistua pian tunnelin kaatumisen jälkeen. Jos läpäisy jatkuu, sidonta ei ole voimassa ja olet takaisin uudelleenkäynnistysvaiheessa, et palomuurissa.

Yhdistä uudelleen ja tarkista valittu nimi vielä kerran, koska tunneli voi palata eri utunin alla. Lyhyt muistiinpano tunnelityypistä, liitännän nimestä ja odotetusta käyttäytymisestä VPN:n pudotessa säästää seuraavan istunnon: tämä asetus on konekohtainen ja palveluntarjoajakohtainen, eikä se selviä asiakkaan päivityksestä eikä VPN-sovelluksen vaihdosta.

Aiheeseen liittyvät artikkelit