Hotspot-asiakkaiden jaettu tunnelointi ei ole sovelluskohtainen poissulkeminen
Sovelluksen poissulkeminen VPN:stä muuttaa vain puhelinta. Kytketyt kannettava tarvitsee oman välityssääntönsä, joka sovitetaan lähteen, kohteen ja NAT:in mukaan.
Kaksi vaatimusta, jotka kuulostavat samalta, eivät ole samoja: „sulje tämä sovellus VPN:stä pois” ja „lähetä tämä yksi kohde VPN:n ulkopuolelle hotspotissani olevalle kannettavalle”. Ensimmäinen muuttaa sitä, miten puhelimen pistoke valitsee verkon. Toisen on muutettava välityspäätöstä paketille, joka saapui toisesta laitteesta sen jälkeen, kun puhelin oli jo hyväksynyt sen. Näiden kahden sekoittaminen johtaa siihen, että hotspot-asiakkaalle jää poikkeus, joka koski aina vain puhelimen omaa selainta.
Kaksi osajärjestelmää omistaa kaksi kysymystä
Android pitää sovellusverkot ja tetheringin erillään. Yhteyksien pino osoittaa sovellusten pistokkeet verkolle, ja VPN-sovellus päättää, mitkä sen omista pistokkeista menevät tunnelin sisään. Kytketyn asiakkaan välittämiä paketteja käsittelee tethering-osajärjestelmä, joka kysyy netd:ltä reittejä, käytäntösääntöjä ja käännöstä alavirran rajapinnalla.
Sovelluskohtainen poissulkeminen arvioidaan, kun sovellus avaa pistokkeen. Välitetty paketti ei koskaan saavuta tätä tarkistusta, koska se ei ole lähtöisin tämän laitteen sovelluspistokkeesta. Juuri siksi kaksi asetusta eivät voi korvata toisiaan, eikä se ole kummankaan vika.
Mitä sovelluskohtainen poissulkeminen todella muuttaa
VpnService-rakentaja voi nimetä paketit, jotka jäävät tunnelin ulkopuolelle, komennolla addDisallowedApplication, tai nimetä ainoat sisällä sallitut paketit komennolla addAllowedApplication. Ne sovellukset avaavat silloin pistokkeita taustaverkossa, kun VPN omistaa edelleen oletusreitin kaikelle muulle.
Laajuus on täsmällinen: paketin omat pistokkeet, tässä laitteessa, niin kauan kuin tunneli on pystyssä. Se ei sano mitään välitetystä liikenteestä, ei toisesta laitteesta eikä paketeista, joita järjestelmä lähettää tetheringin puolesta.
Se ei ole myöskään kohdeohjaus. Selaimen poissulkeminen sulkee pois jokaisen osoitteen, johon se selain pääsee, mukaan lukien sen, jonka halusit pitää tunnelin sisällä. Kun vaatimus nimeää kohteen sovelluksen sijaan, sovellusvalitsin on rakenteellisesti väärä työkalu.
Miltä välitetty paketti näyttää puhelimelle
Asiakkaan paketti saapuu hotspot-rajapinnalle puhelimen jakamalla yksityisellä lähdeosoitteella, vaikkapa 192.168.43.20, ja julkisella kohteella. Välittääkseen sen puhelin tarvitsee reitin ylävirran linkkiin ja käännössäännön, jotta vastaukset löytävät tien takaisin, koska asiakkaan yksityinen osoite on merkityksetön matkapuhelinverkossa.
Android ilmaisee sen käytäntösäännöillä, jotka valitsevat reititystaulun, ja netd rakentaa asiaankuuluvat taulut ja säännöt uudelleen, kun verkot ja VPN:t muuttuvat. Foorumiviestistä tai saman mallin vanhemmasta versiosta kopioitu taulun numero, säännön prioriteetti tai rajapinnan nimi ei synnytä pysyvää omistusta. Tämä uudelleenrakennus on myös syy siihen, että käsin kirjoitettu sääntö voi toimia tunnin ja pysähtyä seuraavan uudelleenyhdistämisen jälkeen.
Millaisen käytännön hotspot-poikkeus todella tarvitsee
Kirjoita päätös lähteeksi, kohteeksi ja aiotuksi reitiksi ennen kuin kosket sääntöön. Vähimmäismuoto yhdelle hyväksytylle kohteelle näyttää tältä:
| 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 |
Molempien suuntien on oltava täydellisiä. Suora haara tarvitsee käyttökelpoisen reitin matkapuhelinverkon ylävirran linkin kautta, joka sattuu olemaan nykyinen; VPN-haara tarvitsee tunnelin reitin sekä luvan välittää. Kaikkien lähdekäännösten on vastattava valitsemaasi ulostuloa, koska tunnelirajapintaan sovellettu NAT näyttää tunnelin osoitteen eikä matkapuhelinverkon osoitetta, ja silloin paluureitti ei vastaa lähtevää reittiä.
Vastausten on saavutettava sama alavirran asiakas seurannan tilan tai nimenomaisen reitin kautta, eikä lähtevien pakettien laskuri todista siitä mitään. Pidä myös VPN:n oma ulompi kuljetus poikkeuksen laajuuden ulkopuolella, muuten tunnelin kantopaketit perivät käytännön, joka on kirjoitettu asiakkaan verkkopyyntöä varten.
Yksi tallennettu osoite ei ole kohde
Yksi selaimesta luettu IPv4-osoite on tilannekuva. Suuret palvelut vastaavat anycastista tai pyörivästä reunaosoitteiden joukosta, monet ovat kaksoispinon palveluita, ja kirjautumisvirta voi koskettaa todentamis- ja telemetria-isäntiä, joita sivu ei koskaan näytä. Sen osoitteen ympärille rakennettu poikkeus, jonka sattumalta näit, hajoaa seuraavan kerran, kun palvelu tasapainottaa uudelleen.
Käytä palvelun omistajan dokumentoituja osoitteita tai aluetta, jonka se julkaisee, ja ota huomioon molemmat osoiteperheet. Jos vaatimusta ei voi ilmaista vakaana joukkona, se on todennäköisesti palvelun käytäntökysymys eikä reititystemppu puhelimessa.
Varmista alavirran puolelta
Kolme tarkistusta tässä järjestyksessä: valittu palvelu kannettavasta, tavallinen kohde, jonka on pysyttävä VPN:n sisällä, ja puhelinsovellus, jonka on pysyttävä koskemattomana. Toista sitten uudelleenyhdistämisen ja ylävirran linkin muutoksen jälkeen, koska silloin käytäntötaulut rakennetaan uudelleen.
Jos puhelimen jakamisen toteutus ei pysty pitämään tätä sopimusta uudelleenyhdistämisen yli, siirrä valikoiva käytäntö tuettuun alavirran reitittimeen sen sijaan, että keräisit root-sääntöjä laitteeseen. Reititin voi ilmaista lähteen ja kohteen sovituksen vakaalla omistajalla, ja tethering-moduulin dokumentaatio on oikea lähde sille, mitä puhelin todella tekee.