Hotspot klientu sadalītais tunelis nav izslēgšana pēc lietotnes
Lietotnes izslēgšana no VPN maina tikai tālruni. Pievienotajam klēpjdatoram vajadzīgs savs pārsūtīšanas noteikums, saskaņots pēc avota, galamērķa un NAT.
Divas prasības, kas izklausās vienādi, nav vienādas: „izslēdz šo lietotni no VPN“ un „nosūti šo vienu galamērķi ārpus VPN klēpjdatoram manā hotspot“. Pirmā maina to, kā tālruņa ligzda izvēlas tīklu. Otrajai jāmaina pārsūtīšanas lēmums paketei, kas ieradās no citas ierīces pēc tam, kad tālrunis to jau pieņēma. Abu sajaukšana noved pie tā, ka hotspot klientam paliek izņēmums, kas vienmēr attiecās tikai uz paša tālruņa pārlūku.
Divi apakšsistēmas pārvalda abus jautājumus
Android tur lietotņu tīklu un tethering atsevišķi. Lietotņu ligzdas tīklam piešķir savienojamības steks, un VPN lietotne izlemj, kuras no tās pašas ligzdām nonāk tunelī. Pārsūtītās paketes no pievienotā klienta apstrādā tethering apakšsistēma, kas pieprasa netd maršrutus, politikas noteikumus un tulkojumu lejupējā saskarnē.
Izslēgšana pēc lietotnes tiek novērtēta, kad lietotne atver ligzdu. Pārsūtītā pakete nekad nesasniedz šo pārbaudi, jo tā nav radusies no šīs ierīces lietotnes ligzdas. Tas ir viss iemesls, kāpēc divi iestatījumi nevar aizstāt viens otru, un tā nav kļūda nevienā no tiem.
Ko izslēgšana pēc lietotnes patiešām maina
VpnService veidotājs var nosaukt paketes, kas paliek ārpus tuneļa, ar addDisallowedApplication, vai nosaukt vienīgās iekšienē atļautās paketes ar addAllowedApplication. Šīs lietotnes pēc tam atver ligzdas pamata tīklā, kamēr VPN joprojām pārvalda noklusējuma maršrutu visam pārējam.
Darbības joma ir precīza: pašas paketes ligzdas, šajā ierīcē, kamēr tunelis ir pacelts. Tā neko nesaka par pārsūtīto datplūsmu, neko par otru ierīci un neko par paketēm, ko sistēma sūta tethering vārdā.
Tā nav arī galamērķa vadība. Pārlūka izslēgšana izslēdz katru adresi, ko šis pārlūks sasniedz, tostarp to, ko gribējāt paturēt tunelī. Kad prasība nosauc galamērķi, nevis lietotni, lietotņu atlasītājs jau pēc uzbūves ir nepareizais rīks.
Kā pārsūtītā pakete izskatās tālrunim
Klienta pakete ierodas hotspot saskarnē ar tālruņa piešķirtu privātu avota adresi, teiksim 192.168.43.20, un publisku galamērķi. Lai to pārsūtītu, tālrunim vajag maršrutu uz augšupējo saiti un tulkošanas noteikumu, lai atbildes atrastu ceļu atpakaļ, jo klienta privātā adrese mobilajā tīklā neko nenozīmē.
Android to izsaka ar politikas noteikumiem, kas izvēlas maršrutēšanas tabulu, un netd pārbūvē attiecīgās tabulas un noteikumus, kad mainās tīkli un VPN. Tabulas numurs, noteikuma prioritāte vai saskarnes nosaukums, kas nokopēts no foruma ziņas vai no tā paša modeļa vecākā laidienā, neizveido ilgstošu īpašumtiesību. Šī pārbūve ir arī iemesls, kāpēc ar roku rakstīts noteikums var strādāt stundu un apstāties pēc nākamās atkārtotās savienošanas.
Kāda politika hotspot izņēmumam patiešām vajadzīga
Pirms pieskaraties noteikumam, pierakstiet lēmumu kā avotu, galamērķi un paredzēto ceļu. Viena apstiprināta galamērķa minimālā forma izskatās šādi:
| 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 |
Abiem virzieniem jābūt pilnīgiem. Tiešajam zaram vajag lietojamu maršrutu caur mobilā tīkla augšupējo saiti, kas šobrīd ir aktuāla; VPN zaram vajag tuneļa maršrutu un atļauju pārsūtīt. Jebkuram avota tulkojumam jāatbilst izvēlētajai izejai, jo NAT, kas piemērots tuneļa saskarnē, parāda tuneļa adresi, nevis mobilo, un tad atgriešanās ceļš nesaskan ar izejas ceļu.
Atbildēm jāsasniedz tas pats lejupējais klients, izmantojot izsekotu stāvokli vai skaidru maršrutu, un izejošo pakešu skaitītājs neko no tā nepierāda. Turiet arī paša VPN ārējo transportu ārpus izņēmuma jomas, citādi tuneļa nesējpakekete manto politiku, kas rakstīta klienta tīmekļa pieprasījumam.
Viena uztverta adrese nav galamērķis
Viena IPv4 adrese, kas nolasīta no pārlūka, ir momentuzņēmums. Lieli pakalpojumi atbild no anycast vai no rotējošas malas adrešu kopas, daudzi ir divkāršas kaudzes, un pieteikšanās plūsma var aizskart autentifikācijas un telemetrijas saimniekus, ko lapa nekad nerāda. Izņēmums, kas uzbūvēts ap adresi, kuru nejauši redzējāt, salūzt nākamreiz, kad pakalpojums pārdala slodzi.
Izmantojiet pakalpojuma īpašnieka dokumentētās adreses vai diapazonu, ko tas publicē, un ņemiet vērā abas adrešu saimes. Ja prasību nevar izteikt kā stabilu kopu, tas, iespējams, ir politikas jautājums pakalpojumam, nevis maršrutēšanas triks tālrunī.
Pārbaudiet no lejupējās puses
Trīs pārbaudes šajā secībā: izvēlētais pakalpojums no klēpjdatora, parasts galamērķis, kam jāpaliek VPN iekšienē, un tālruņa lietotne, kurai jāpaliek neskartai. Pēc tam atkārtojiet pēc atkārtotas savienošanas un pēc augšupējās saites maiņas, jo tad tabulas tiek pārbūvētas.
Ja tālruņa koplietošanas ieviešana nevar noturēt šo līgumu pāri atkārtotai savienošanai, pārvietojiet selektīvo politiku uz atbalstītu lejupējo maršrutētāju, nevis krājiet root noteikumus pašā aparātā. Maršrutētājs var izteikt avota un galamērķa saskaņošanu ar stabilu īpašnieku, un tethering moduļa dokumentācija ir pareizā atsauce uz to, ko tālrunis patiešām dara.