Nettlesaren på telefonen rapporterer ei adresse i eit anna land, og den berbare datamaskinen på hotspoten rapporterer framleis mobiloperatøren. Ingen av dei to observasjonane er feil, og motsetninga folk ser, kjem av at ein legg til grunn at det å dele ei internettilkopling òg deler ein tunnel. Tre vilkår avgjer om trafikk frå eininga som er kopla til, hamnar i VPN-en til telefonen, og berre eitt av dei handlar om innstillingane på telefonen. Gå gjennom dei før du leitar etter ein delefunksjon som kanskje ikkje finst.

Kva hotspoten faktisk sender vidare

Tethering gjev den berbare datamaskinen ein veg til internett gjennom det mobile grensesnittet til telefonen. Telefonen sender desse pakkane vidare og omset vanlegvis adressene til datamaskinen når dei går ut. Det er ein videresendingsfunksjon, og videresending er ikkje det same som å fanga trafikk i ein tunnel.

Om dei videresende pakkane deretter hamnar i VPN-en til telefonen, kjem an på korleis VPN-programmet installerte rutene og reglane sine. Eit program som berre fangar trafikk som oppstår på telefonen, vil ikkje sjå pakkar som kjernen sender vidare på vegner av ein tilkopla klient.

Difor finst dei to observasjonane så lett side om side. Nettlesaren til telefonen sjølv brukar tunnelen, pakkane til datamaskinen tek videresendingsvegen, og ingenting på nokon av skjermane lyg til deg. Dei to einingane stiller rett og slett ikkje same spørsmål til same grensesnitt. Når du ser denne splittinga, vert klaga «kvifor er ikkje den berbare datamaskinen min verna» eit designspørsmål i staden for ein feil.

Vilkår éin: kva tunnel telefonen køyrer

Byrja med å fastslå omfanget av VPN-en på telefonen. Ein tunnel for heile eininga, ein tunnel per program og ein proxy berre for nettlesaren er tre ulike ting, og berre den fyrste har noka sjanse til å dekkja videresend trafikk. Sjå på skildringa til leverandøren av kva appen fangar, i staden for ikonet i statuslinja.

Sjekk deretter kva leverandøren seier om tethering. Nokre dokumenterer uttrykkeleg at vanleg hotspot-trafikk er utanfor tunnelen, noko som er det ærlege svaret for ei forbrukarteneste som aldri lova å vera ein ruter. Rettleiinga til Proton VPN for Android-hotspot er eitt publisert døme på den skilnaden; dokumentasjonen til din eigen leverandør er den som gjeld for eininga di.

Eit VPN-ikon i statuslinja fortel deg at telefonen har ein tunnel. Det fortel deg ikkje kva grensesnitt tunnelen dekkjer, og i det gapet bur det meste av forvirringa.

Vilkår to: om tethering er med

Jamvel ein tunnel for heile eininga kan etter designet utelata videresend trafikk, fordi rutereglane til programmet vart skrivne for lokalt genererte pakkar. Å ta med tilkopla klientar krev vanlegvis at leverandøren støttar det uttrykkeleg, eller ei roota eining med eigne reglar som dei fleste ikkje bør freista.

Å byta frå Wi-Fi til USB endrar ikkje dette. Tethering-undersystemet støttar fleire transportar, men transporten er ikkje rutedecisjonen. Ein kabel gjer sambandet meir stabilt og gjer ingenting for tunneldekninga, og difor svarar rådet «bruk berre USB» på eit anna spørsmål enn det som vert stilt.

Gamle oppskrifter som tømmer brannmurreglar og legg til grunn bestemte grensesnittnamn er ikkje flyttbare instruksjonar. Dei vart skrivne for ei bestemt eining, ein bestemt ROM og eit bestemt år, og å bruka dei på ein moderne telefon vil heller bryta tethering enn å utvida ein tunnel.

Vilkår tre: kva identitet destinasjonen treng

Dette er vilkåret som vanlegvis avgjer designet, og det har ingenting med hotspotar å gjera. Viss den berbare datamaskinen må nå eit nettverk hos ein arbeidsgjevar, høyrer identiteten som gjeld, til datamaskinen, og ein forbrukar-VPN på telefonen kan ikkje levera han.

ip -brief addr show
curl -sS https://ifconfig.me/ip
dig +short myip.opendns.com @resolver1.opendns.com

Køyr desse på datamaskinen, ikkje på telefonen, fordi spørsmålet er kva destinasjonen ser frå eininga du bryr deg om. Ei offentleg adresse som telefonen rapporterer, svarar på eit spørsmål om telefonen.

Jamvel eit samsvarande resultat frå datamaskinen er avgrensa prov. Namneoppslag, andre program og åtferd når tunnelen sviktar, høyrer alle til eininga du testar dekninga til, og éin HTTP-førespurnad karakteriserer ingen av dei. Test programmet du faktisk bryr deg om, og test det deretter på nytt med tunnelen medvite kopla frå.

Kva du bør gjera i staden, i rekkjefølgje etter innsats

Det billegaste riktige svaret er å køyra VPN-en på datamaskinen. Kopla han til hotspoten, lat telefonen levera den underliggjande mobiltilkoplinga, og set opp tunnelen frå eininga som treng identiteten. Dette fungerer med VPN-ar til arbeidsgjevarar, og det er tilfellet som gjeld mest.

Viss eininga ikkje kan køyra ein VPN-klient i det heile, sjå etter ein uttrykkeleg støtta delingsgateway eller ein reiseruter som avsluttar tunnelen. Les dokumentasjonen for den faktiske plattforma i staden for å leggja til grunn at ein hotspot-funksjon er den gatewayen.

Viss ingen av delane er mogleg, godta avgrensinga i staden for å omgå ho med ei oppskrift du ikkje kan vedlikehalda. VPN-en til telefonen dekkjer telefonen; datamaskinen treng sin eigen veg, og å vita det på førehand er meir verdt enn ein ettermiddag med grensesnitteksperiment. Dokumenter ordninga slik at neste person ikkje oppdagar ho på nytt under ei hending. Éi line i wikien til teamet er nok.

Relaterte artiklar