Hotspot klientų skaidytas tunelis nėra išimtis pagal programėles
Programėlės pašalinimas iš VPN keičia tik telefoną. Prijungtam nešiojamajam kompiuteriui reikia savo persiuntimo taisyklės, suderintos pagal šaltinį, paskirties vietą ir NAT.
Du reikalavimai, kurie skamba vienodai, nėra vienodi: „pašalink šią programėlę iš VPN“ ir „siųsk šią vieną paskirties vietą už VPN ribų nešiojamajam kompiuteriui mano hotspote“. Pirmasis keičia tai, kaip telefono lizdas pasirenka tinklą. Antrasis turi pakeisti persiuntimo sprendimą paketui, kuris atėjo iš kito įrenginio po to, kai telefonas jį jau priėmė. Sumaišius abu, hotspot klientui lieka išimtis, kuri visada galiojo tik paties telefono naršyklei.
Du posistemius valdo du klausimus
Android laiko programėlių tinklą ir tethering atskirai. Programėlių lizdus tinklui priskiria jungiamumo krūva, o VPN programėlė nusprendžia, kurie jos pačios lizdai patenka į tunelį. Persiųstus paketus iš prijungto kliento apdoroja tethering posistemis, kuris prašo netd maršrutų, politikos taisyklių ir vertimo žemutinėje sąsajoje.
Išimtis pagal programėlę vertinama, kai programėlė atidaro lizdą. Persiųstas paketas niekada nepasiekia šios patikros, nes jis neatsirado iš šio įrenginio programėlės lizdo. Tai ir yra visa priežastis, kodėl du nustatymai negali pakeisti vienas kito, ir tai nėra klaida nė viename iš jų.
Ką iš tikrųjų keičia išimtis pagal programėlę
VpnService kūrėjas gali įvardyti paketus, kurie lieka už tunelio, naudodamas addDisallowedApplication, arba įvardyti vienintelius viduje leidžiamus paketus naudodamas addAllowedApplication. Tada tos programėlės atidaro lizdus pagrindiniame tinkle, o VPN toliau valdo numatytąjį maršrutą viskam kitam.
Apimtis tiksli: paties paketo lizdai, šiame įrenginyje, kol tunelis pakeltas. Ji nieko nesako apie persiųstą srautą, nieko apie antrą įrenginį ir nieko apie paketus, kuriuos sistema siunčia tethering vardu.
Tai irgi ne paskirties vietos valdymas. Naršyklės pašalinimas pašalina kiekvieną adresą, kurį ta naršyklė pasiekia, įskaitant tą, kurį norėjote palikti tunelio viduje. Kai reikalavimas įvardija paskirties vietą, o ne programėlę, programėlių parinkiklis jau iš konstrukcijos yra netinkamas įrankis.
Kaip persiųstas paketas atrodo telefonui
Kliento paketas atvyksta į hotspot sąsają su telefonu priskirtu privačiu šaltinio adresu, tarkim 192.168.43.20, ir vieša paskirties vieta. Kad jį persiųstų, telefonui reikia maršruto link viršutinės grandies ir vertimo taisyklės, kad atsakymai rastų kelią atgal, nes kliento privatus adresas mobiliojo ryšio tinkle nieko nereiškia.
Android tai išreiškia politikos taisyklėmis, kurios pasirenka maršruto lentelę, o netd atkuria atitinkamas lenteles ir taisykles, kai keičiasi tinklai ir VPN. Lentelės numeris, taisyklės prioritetas ar sąsajos pavadinimas, nukopijuoti iš forumo žinutės ar to paties modelio senesniame leidime, nesukuria ilgalaikio valdymo. Šis atkūrimas yra ir priežastis, kodėl ranka parašyta taisyklė gali veikti valandą ir sustoti po kito prisijungimo.
Kokios politikos iš tikrųjų reikia hotspot išimčiai
Prieš liesdami taisyklę, užrašykite sprendimą kaip šaltinį, paskirties vietą ir numatytą kelią. Vienos patvirtintos paskirties vietos minimali forma atrodo taip:
| 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 |
Abi kryptys turi būti išsamios. Tiesioginei šakai reikia tinkamo maršruto per mobiliojo ryšio viršutinę grandį, kuri šiuo metu yra aktuali; VPN šakai reikia tunelio maršruto ir leidimo persiųsti. Bet koks šaltinio vertimas turi atitikti pasirinktą išėjimą, nes NAT, taikomas tunelio sąsajoje, rodo tunelio adresą, o ne mobiliojo ryšio, ir tada grįžimo kelias nesutampa su ėjimo keliu.
Atsakymai turi pasiekti tą patį žemutinį klientą per sekamą būseną arba aiškų maršrutą, o išeinančių paketų skaitiklis nieko to neįrodo. Laikykite ir paties VPN išorinį transportą už išimties apimties, kitaip tunelio nešantys paketai paveldi politiką, parašytą kliento žiniatinklio užklausai.
Vienas užfiksuotas adresas nėra paskirties vieta
Vienas IPv4 adresas, perskaitytas iš naršyklės, yra akimirkos nuotrauka. Didelės paslaugos atsako iš anycast arba iš besisukančio krašto adresų rinkinio, daugelis yra dvigubo kamino, o prisijungimo srautas gali paliesti autentifikavimo ir telemetrijos mazgus, kurių puslapis niekada nerodo. Išimtis, pastatyta aplink adresą, kurį netyčia matėte, nulūžta kitą kartą, kai paslauga perskirsto apkrovą.
Naudokite dokumentuotus paslaugos savininko adresus arba jo skelbiamą diapazoną ir atsižvelkite į abi adresų šeimas. Jei reikalavimo neįmanoma išreikšti kaip stabilaus rinkinio, tai greičiausiai politikos klausimas paslaugai, o ne maršrutizavimo gudrybė telefone.
Patikrinkite iš žemutinės pusės
Trys patikros šia tvarka: pasirinkta paslauga iš nešiojamojo kompiuterio, įprasta paskirties vieta, kuri turi likti VPN viduje, ir telefono programėlė, kuri turi likti nepaveikta. Tada pakartokite po prisijungimo iš naujo ir po viršutinės grandies pakeitimo, nes tada lentelės atkuriamos.
Jei telefono bendrinimo diegimas negali išlaikyti šios sutarties per prisijungimą iš naujo, perkelkite selektyvią politiką į palaikomą žemutinį maršrutizatorių, o ne kaupkite root taisykles pačiame aparate. Maršrutizatorius gali išreikšti šaltinio ir paskirties atitikimą su stabiliu savininku, o tethering modulio dokumentacija yra teisinga nuoroda apie tai, ką telefonas iš tikrųjų daro.