Tvær kröfur sem hljóma jafngildar eru það ekki: „útilokaðu þetta forrit frá VPN“ og „sendu þennan eina áfangastað út fyrir VPN fyrir tölvuna á hotspotinu mínu“. Sú fyrri breytir því hvernig samband á símanum velur net. Sú seinni verður að breyta framsendingarákvörðun fyrir pakka sem kom frá öðru tæki eftir að síminn hafði þegar samþykkt hann. Að rugla þessu tvennu er hvernig hotspot-biðlari endar með undantekningu sem átti alltaf aðeins við vafrann í símanum sjálfum.

Tvö undirkerfi eiga báðar spurningarnar

Android heldur netkerfum forrita og tengingu tölvu aðskildum. Tengikerfið úthlutar samböndum forritanna á net, og VPN-forrit ákveður hvaða sambönd þess fara inn í göngin. Framsendir pakkar frá tengdum biðlara eru meðhöndlaðir af undirkerfi tengingarinnar, sem biður netd um leiðir, stefnureglur og þýðingu á niðurstreymisviðmótinu.

Útilokun eftir forritum er metin þegar forrit opnar samband. Framsendur pakki nær aldrei þeirri athugun, því hann átti ekki uppruna í sambandi forrits á þessu tæki. Það er öll ástæðan fyrir því að stillingarnar tvær geta ekki komið í stað hvors annars, og það er ekki galli í hvorugu þeirra.

Hvað útilokun eftir forritum breytir í raun

Byggingaraðili VpnService getur nefnt pakka sem vera utan ganganna með addDisallowedApplication, eða nefnt einu pakkana sem leyfðir eru inni með addAllowedApplication. Þau forrit opna þá sambönd á undirliggjandi neti á meðan VPN heldur áfram að eiga sjálfgefna leið fyrir allt annað.

Umfangið er nákvæmt: eigin sambönd pakkans, á þessu tæki, meðan göngin eru uppi. Það segir ekkert um framsent umferð, ekkert um annað tæki og ekkert um pakka sem kerfið sendir fyrir hönd tengingarinnar.

Það er heldur ekki stjórnun á áfangastað. Að útiloka vafra útilokar hvert það vistfang sem vafrinn nær, þar á meðal það sem þú vildir halda inni í göngunum. Þegar krafan nefnir áfangastað frekar en forrit, er forritavalarið rangt verkfæri af eðlisfari.

Hvernig framsendur pakki lítur út fyrir símann

Pakki biðlarans kemur á hotspot-viðmótið með einkaupptökufangi sem síminn úthlutaði, segjum 192.168.43.20, og opinberum áfangastað. Til að framsenda hann þarf síminn leið í átt að uppstreymistengingu og þýðingarreglu svo svörin finni leið til baka, því einkavistfang biðlarans þýðir ekkert í farsímanetinu.

Android lýsir þessu með stefnureglum sem velja leiðartöflu, og netd endurbyggir viðeigandi töflur og reglur þegar netkerfi og VPN breytast. Töflunúmer, regluforsenda eða viðmótsheiti sem afritað er af vefspjalli, eða af sama líkani í eldri útgáfu, kemur ekki á varanlegri eign. Þessi endurbygging er líka ástæðan fyrir því að handskrifuð regla getur virkað í klukkustund og stöðvast eftir næstu endurtengingu.

Hvaða stefnu hotspot-undantekning þarf í raun

Skrifaðu ákvörðunina sem upptök, áfangastað og fyrirhugaða leið áður en þú snertir reglu. Lágmarksform fyrir einn samþykktan áfangastað lítur svona út:

SourceDestinationIntended path
One authorized hotspot clientOne approved public service addressOrdinary cellular uplink
The same clientAll other covered destinationsShared VPN
The phone's own appsTheir existing destinationsUnchanged phone policy

Báðar áttir verða að vera heildstæðar. Beina greinin þarf nothæfa leið um farsímauppstreymistenginguna sem er núverandi; VPN-greinin þarf leið ganganna auk leyfis til að framsenda. Sérhver þýðing upptaka verður að passa við útgönguna sem þú valdir, því NAT sem beitt er á viðmót ganganna sýnir vistfang ganganna en ekki farsímans, og þá stemmir afturleiðin ekki við útleiðina.

Svörin verða að ná til sama niðurstreymisbiðlara með raktu ástandi eða skýrri leið, og teljari útfarandi pakka sannar ekkert af því. Hafðu ytri flutning VPN sjálfs utan umfangs undantekningarinnar líka, annars erfa burðarpakkar ganganna stefnu sem skrifuð er fyrir vefbeiðni biðlara.

Eitt handsamað vistfang er ekki áfangastaður

Eitt IPv4-vistfang lesið úr vafra er skyndimynd. Stór þjónustur svara frá anycast eða úr snúningsmengi brúnarvistfanga, mörg eru tvílaga, og innskráningarflæði getur snert auðkenningar- og fjarmælingarhýsla sem síðan sýnir aldrei. Undantekning byggð í kringum vistfangið sem þú sást fyrir tilviljun brotnar næst þegar þjónustan endurjafnar álagi.

Notaðu skjalfest vistföng eiganda þjónustunnar, eða svið sem hann birtir, og reiknaðu með báðum vistfangafjölskyldum. Ef ekki er hægt að tjá kröfuna sem stöðugt mengi er það líklega stefnuspurning fyrir þjónustuna en ekki leiðarbrellur í síma.

Staðfestu frá niðurstreymishlið

Þrjár athuganir, í þessari röð: valin þjónusta frá tölvunni, venjulegur áfangastaður sem verður að vera inni í VPN, og símaforrit sem verður að vera ósnortið. Endurtaktu svo eftir endurtengingu og eftir breytingu á uppstreymistengingu, því þá eru stefnutöflurnar endurbyggðar.

Ef deilingarútfærsla símans getur ekki haldið þessum samningi yfir endurtengingu, færðu sértæku stefnuna á studdan niðurstreymisbeini í stað þess að safna root-reglum á tækið. Beini getur tjáð samræmi upptaka og áfangastaðar með stöðugum eiganda, og skjöl tengingareiningarinnar eru rétta heimildin fyrir það sem síminn gerir í raun.

Tengdir greinar