Tunela disigo por hotspot-klientoj ne estas por-aplika ekskludo
Ekskludi aplikaĵon el la VPN ŝanĝas nur la telefonon. Ligita tekokomputilo bezonas propran plusendan regulon, kongruigitan laŭ fonto, celo kaj NAT.
Du postuloj, kiuj sonas egalaj, ne estas: „ekskludi ĉi tiun aplikaĵon el la VPN” kaj „sendi ĉi tiun unu celon ekster la VPN por la tekokomputilo en mia hotspot”. La unua ŝanĝas kiel ingo en la telefono elektas reton. La dua devas ŝanĝi plusendan decidon por paketo, kiu alvenis de alia aparato post kiam la telefono jam akceptis ĝin. Konfuzi la du estas kiel hotspot-kliento finiĝas kun escepto, kiu ĉiam nur validis por la propra retumilo de la telefono.
Du subsistemoj posedas la du demandojn
Android tenas aparte aplikaĵan retadon kaj tethering. Aplikaĵaj ingoj estas atribuitaj al reto de la konekteca stako, kaj VPN-a aplikaĵo decidas, kiuj el ĝiaj propraj ingoj eniras la tunelon. Plusenditaj paketoj de ligita kliento estas pritraktataj de la tethering-subsistemo, kiu petas de netd itinerojn, politikajn regulojn kaj tradukon sur la malsupra interfaco.
Por-aplika ekskludo estas taksata kiam aplikaĵo malfermas ingon. Plusendita paketo neniam atingas tiun kontrolon, ĉar ĝi ne originis el aplikaĵa ingo sur ĉi tiu aparato. Tio estas la tuta kialo, kial la du agordoj ne povas anstataŭi unu la alian, kaj tio ne estas cimo en iu el ili.
Kion por-aplika ekskludo fakte ŝanĝas
Konstruanto de VpnService povas nomi pakaĵojn, kiuj restas ekster la tunelo, per addDisallowedApplication, aŭ nomi la solajn pakaĵojn permesatajn interne per addAllowedApplication. Tiuj aplikaĵoj tiam malfermas ingojn en la suba reto, dum la VPN plu posedas la aprikan itineron por ĉio alia.
La amplekso estas preciza: la propraj ingoj de la pakaĵo, sur ĉi tiu aparato, dum la tunelo estas aktiva. Ĝi diras nenion pri plusendita trafiko, nenion pri dua aparato, kaj nenion pri paketoj, kiujn la sistemo sendas nome de tethering.
Ĝi ankaŭ ne estas celdirektado. Ekskludi retumilon ekskludas ĉiun adreson, kiun tiu retumilo atingas, inkluzive tiun, kiun vi volis teni ene de la tunelo. Kiam la postulo nomas celon anstataŭ aplikaĵon, la aplikaĵ-elektilo estas la malĝusta ilo jam laŭ konstruo.
Kiel plusendita paketo aspektas al la telefono
La paketo de la kliento alvenas sur la hotspot-interfacon kun privata fontadreso atribuita de la telefono, diru 192.168.43.20, kaj publika celo. Por plusendi ĝin, la telefono bezonas itineron al suprena ligo kaj tradukan regulon, por ke respondoj trovu la vojon reen, ĉar la privata adreso de la kliento estas sensignifa en la poŝtelefona reto.
Android esprimas tion per politikaj reguloj, kiuj elektas enkursigan tabelon, kaj netd rekonstruas la koncernajn tabelojn kaj regulojn, kiam retoj kaj VPN-oj ŝanĝiĝas. Tabelnumero, regula prioritato aŭ interfaca nomo kopiitaj el forumafiŝo, aŭ el la sama modelo en pli malnova eldono, ne starigas daŭran posedon. Tiu rekonstruo ankaŭ klarigas, kial permane skribita regulo povas funkcii unu horon kaj halti post la sekva rekonekto.
Kiun politikon hotspot-escepto fakte bezonas
Skribu la decidon kiel fonto, celo kaj intencita vojo antaŭ ol tuŝi regulon. La minimuma formo por unu aprobita celo aspektas tiel:
| Source | Destination | Intended path |
|---|---|---|
| One authorized hotspot client | One approved public service address | Ordinary cellular uplink |
| The same client | All other covered destinations | Shared VPN |
| The phone's own apps | Their existing destinations | Unchanged phone policy |
Ambaŭ direktoj devas esti kompletaj. La rekta branĉo bezonas uzeblan itineron tra la poŝtelefona suprena ligo, kiu hazarde estas la nuna; la VPN-branĉo bezonas la tunelan itineron plus permeson plusendi. Ĉiu fonta traduko devas kongrui kun la eliro, kiun vi elektis, ĉar NAT aplikita sur tunela interfaco montras la tunelan adreson kaj ne la poŝtelefonan, kaj tiam la revena vojo ne kongruas kun la elira vojo.
Respondoj devas atingi la saman malsupran klienton per spurata stato aŭ eksplicita itinero, kaj nombrilo de elirantaj paketoj pruvas nenion el tio. Teni ankaŭ la propran eksteran transporton de la VPN ekster la amplekso de la escepto, alie la portaj paketoj de la tunelo heredas politikon skribitan por reta peto de kliento.
Unu kaptita adreso ne estas celo
Unu sola IPv4-adreso legita el retumilo estas momenta bildo. Grandaj servoj respondas per anycast aŭ per rotacia aro de randaj adresoj, multaj estas duobla-stako, kaj ensaluta fluo povas tuŝi aŭtentigajn kaj telemetriajn gastigantojn, kiujn la paĝo neniam montras. Escepto konstruita ĉirkaŭ la adreso, kiun vi hazarde vidis, rompiĝas la sekvan fojon, kiam la servo reekvilibrigas.
Uzu la dokumentitajn adresojn de la posedanto de la servo, aŭ intervalon, kiun ĝi publikigas, kaj kalkulu ambaŭ adresajn familiojn. Se la postulo ne povas esti esprimita kiel stabila aro, ĝi verŝajne estas politika demando por la servo kaj ne enkursiga artifiko sur telefono.
Kontrolu de la malsupra flanko
Tri kontroloj, en ĉi tiu ordo: la elektita servo de la tekokomputilo, ordinara celo, kiu devas resti ene de la VPN, kaj telefonoa aplikaĵo, kiu devas resti neinfluita. Poste ripetu post rekonekto kaj post ŝanĝo de suprena ligo, ĉar tiam la politikaj tabeloj rekonstruiĝas.
Se la kunhaviga efektivigo de la telefono ne povas teni tiun kontrakton tra rekonekto, movu la selekvan politikon al subtenata malsupra enkursigilo anstataŭ amasigi radikajn regulojn sur la aparato. Enkursigilo povas esprimi fontan kaj celan kongruon kun stabila posedanto, kaj la dokumentaro de la tethering-modulo estas la ĝusta referenco por tio, kion la telefono fakte faras.