Kuumkoha klientide jaoks mõeldud split-tunnel ei ole rakendusepõhine välistamine
Rakenduse VPN-ist väljajätmine muudab ainult telefoni. Ühendatud sülearvuti vajab oma edastusreeglit, mis sobitatakse lähtekoha, sihtkoha ja NAT-i järgi.
Kaks nõuet, mis kõlavad samamoodi, ei ole samad: „jäta see rakendus VPN-ist välja“ ja „saada see üks sihtkoht VPN-ist välja minu kuumkoha sülearvuti jaoks“. Esimene muudab seda, kuidas telefonis olev pesa võrku valib. Teine peab muutma edastusotsust paketi jaoks, mis saabus teisest seadmest pärast seda, kui telefon oli selle juba vastu võtnud. Nende kahe segamine on see, kuidas kuumkoha klient jääb erandiga, mis kehtis alati ainult telefoni enda brauserile.
Kaks alamsüsteemi vastutavad kahe küsimuse eest
Android hoiab rakenduste võrgunduse ja tetherduse lahus. Rakenduste pesad määrab võrku ühenduvusvirn, ja VPN-rakendus otsustab, millised tema enda pesadest tunnelisse lähevad. Ühendatud kliendi edastatud pakette käsitleb tetherduse alamsüsteem, mis küsib netd-ilt marsruute, poliitikareegleid ja tõlget allavoolu liidesel.
Rakendusepõhist välistamist hinnatakse siis, kui rakendus pesa avab. Edastatud pakett ei jõua kunagi selle kontrollini, sest see ei pärine selle seadme rakenduse pesast. Just see on kogu põhjus, miks kaks seadet ei saa teineteist asendada, ja see ei ole kummagi viga.
Mida rakendusepõhine välistamine tegelikult muudab
VpnService’i ehitaja saab addDisallowedApplication abil nimetada pakette, mis jäävad tunnelist välja, või addAllowedApplication abil nimetada ainsaid sees lubatud pakette. Need rakendused avavad siis pesad alusvõrgus, samal ajal kui VPN jätkab kõige muu jaoks vaikemarsruudi omamist.
Ulatus on täpne: paketi enda pesad, selles seadmes, seni kuni tunnel on üleval. See ei ütle midagi edastatud liikluse, teise seadme ega pakettide kohta, mida süsteem saadab tetherduse nimel.
See ei ole ka sihtkoha juhtimine. Brauseri välistamine välistab iga aadressi, kuhu see brauser jõuab, sealhulgas selle, mida soovisite tunnelis hoida. Kui nõue nimetab sihtkohta, mitte rakendust, on rakenduse valija juba konstruktsiooni poolest vale tööriist.
Kuidas edastatud pakett telefonile paistab
Kliendi pakett saabub kuumkoha liidesele telefonis määratud privaatse lähteaadressiga, ütleme 192.168.43.20, ja avaliku sihtkohaga. Selle edastamiseks vajab telefon marsruuti ülesvoolu lingi poole ja tõlkereeglit, et vastused leiaksid tee tagasi, sest kliendi privaatne aadress on mobiilivõrgus mõttetu.
Android väljendab seda poliitikareeglitega, mis valivad marsruutimistabeli, ja netd ehitab asjakohased tabelid ja reeglid uuesti üles, kui võrgud ja VPN-id muutuvad. Foorumipostitusest või sama mudeli vanemast väljaandest kopeeritud tabelinumber, reegli prioriteet või liidese nimi ei loo püsivat omandit. See ülesehitamine on ka põhjus, miks käsitsi kirjutatud reegel võib tund aega töötada ja järgmise taasühenduse järel lakkab.
Millist poliitikat kuumkoha erand tegelikult vajab
Kirjutage otsus lähtekoha, sihtkoha ja kavatsetud teena üles enne, kui reeglit puudutate. Ühe kinnitatud sihtkoha minimaalne kuju näeb välja selline:
| 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 |
Mõlemad suunad peavad olema terviklikud. Otseharu vajab kasutatavat marsruuti mobiilse ülesvoolu lingi kaudu, mis juhtub parajasti kehtiv olema; VPN-haru vajab tunneli marsruuti pluss luba edastada. Iga lähtekoha tõlge peab vastama valitud väljundile, sest tunneli liidesel rakendatud NAT esitab tunneli aadressi, mitte mobiili oma, ja siis ei klapi tagasitee väljamineva teega.
Vastused peavad jõudma sama allavoolu kliendini jälgitud oleku või selgesõnalise marsruudi kaudu, ja väljuvate pakettide loendur ei tõesta sellest midagi. Hoidke ka VPN-i enda välimine transport erandi ulatusest väljas, muidu pärivad tunneli kandepaketid poliitika, mis on kirjutatud kliendi veebipäringu jaoks.
Üks tabatud aadress ei ole sihtkoht
Üks brauserist loetud IPv4-aadress on hetktõmmis. Suured teenused vastavad anycastist või pöörlevast servaaadresside hulgast, paljud on kahekihilised, ja sisselogimisvoog võib puudutada autentimis- ja telemeetriahoste, mida leht kunagi ei näita. Aadressi ümber, mida juhtusite nägema, ehitatud erand puruneb järgmisel korral, kui teenus koormust ümber jaotab.
Kasutage teenuse omaniku dokumenteeritud aadresse või vahemikku, mille ta avaldab, ja arvestage mõlema aadressiperekonnaga. Kui nõuet ei saa väljendada stabiilse hulgana, on see tõenäoliselt teenuse poliitikaküsimus, mitte marsruutimistrikk telefonis.
Kontrollige allavoolu poolelt
Kolm kontrolli selles järjekorras: valitud teenus sülearvutist, tavaline sihtkoht, mis peab jääma VPN-i sisse, ja telefonirakendus, mis peab jääma mõjutamata. Seejärel korrake pärast taasühendust ja pärast ülesvoolu lingi muutust, sest just siis ehitatakse poliitikatabelid uuesti üles.
Kui telefoni jagamise teostus ei suuda seda lepet üle taasühenduse hoida, viige valikuline poliitika toetatud allavoolu ruuterile, selle asemel et koguda seadmesse root-reegleid. Ruuter suudab väljendada lähte- ja sihtkoha sobivust stabiilse omanikuga, ja tetherduse mooduli dokumentatsioon on õige viide selle kohta, mida telefon tegelikult teeb.