Android-sovellus kieltäytyy toimimasta VPN:n yli: mikä kerros päättää
Sovellus voi hylätä VPN:n paikallisen kuljetustarkistuksen, palvelinpuolen osoitesäännön tai oman käytäntönsä takia. Erottele nämä kolme ennen kuin vaihdat ulostuloja.
Kun Android-sovellus lakkaa toimimasta hetkellä, jolloin tunneli nousee, syyllisiä voi olla kolme eri asiaa, ja ne tuottavat samannäköisiä vikoja. Sovellus voi lukea puhelimen oman verkkotilan ja kieltäytyä paikallisesti. Palvelin voi luokitella osoitteen, josta tulet, ja hylätä sen. Tai kieltäytymisellä ei välttämättä ole mitään tekemistä VPN:n kanssa. Alla oleva järjestys kerää todisteita ennen kuin muuttaa mitään, koska ulostulon vaihtaminen on kallein askel ja vähiten todennäköisesti auttaa, jos tarkistus on paikallinen.
Vaihe 1: selvitä, milloin sovellus kieltäytyy
Ajoitus on ensimmäinen erottelija. Tyhjennä lokipuskuri, toista vika ja katso, mitä sovellus teki ennen kuin valitti:
adb logcat -c
# reproduce the failure in the app
adb logcat -d | grep -iE 'vpn|network|connect|http' | tail -60
Jos sovellus kieltäytyy ennen kuin yhtäkään lähtevää pyyntöä on yritetty, kyseessä on paikallinen päätös. Jos se yhdistää, lähettää jotain ja näyttää sitten virheen, kieltäytyminen tuli toiselta puolelta. Jos sovellus epäonnistuu samalla tavoin tunnelin ollessa suljettuna, VPN ei ollut koskaan muuttuja.
Käsittele tuota ajoitusta todisteena, älä vahvistuksena. Sovellus voi toistaa välimuistiin tallennetun vastauksen, ja taustapyynnöt ovat voineet onnistua tai epäonnistua ennen kuin katsoit. Kirjaa viimeisen onnistuneen pyynnön ja virheen aikaleimat, ei vain hetkeä, jolloin viesti ilmestyi.
Vaihe 2: lue puhelimen oma näkemys verkosta
Android paljastaa VPN-tilan verkkokykynä, joten sovellus ei tarvitse luetteloa kaupallisista tarjoajista huomatakseen aktiivisen tunnelin. Se kysyy yhteyspalvelulta, mikä nykyinen verkko on, ja vastaus sisältää VPN:n kuljetusbitin:
val cm = context.getSystemService(ConnectivityManager::class.java)
val caps = cm.getNetworkCapabilities(cm.activeNetwork)
val onVpn = caps?.hasTransport(NetworkCapabilities.TRANSPORT_VPN) == true
Tuo tarkistus on paikallinen ja halpa, ja se selittää kokonaisen luokan raportteja tyyliin »tämä sovellus ei toimi VPN:n yli» ilman mitään etäluokitusta. Se, mitä sovellus voi nähdä, riippuu yhä sen omasta verkkoympäristöstä, joten älä oleta jokaisen sovelluksen tutkivan jokaista laitteen profiilia.
Työasemalta näet saman tilan testilaitteella komennolla adb shell dumpsys connectivity ja etsimällä VPN-verkkomerkintää. Vertaa ajoa, jossa tunneli on ylhäällä, ajoon, jossa se on alhaalla, ja säilytä molemmat tulosteet.
Vaihe 3: lue, mitä palvelin todella näkee
Toinen tarkkailija on palvelu. Se näkee saapuvan lähdeosoitteen ja voi toimia osoitteen, sen takana olevan hosting-verkon, alueen, operaattorin tai tilille ja laitteelle sidottujen signaalien perusteella. Mikään näistä ei ole ainutlaatuinen identiteetti, ja jaettu osoitteistus tekee sivublokit tavallisiksi: yksi rajoitettu osoite voi pudottaa pois asiattomia käyttäjiä saman käännöksen takaa.
Hanki osoite samaa reittiä, jota sovellus käyttää, älä kannettavan selaimesta. Puhelimessa yksinkertainen pyyntö osoitekaikupalvelulle näyttää, mitä kaukokanta vastaanottaa, ja vertaaminen mobiiliverkon kautta tehtyyn pyyntöön kertoo, muuttuiko osoite lainkaan.
Jos sovellus toimii mobiiliverkossa ja epäonnistuu tunnelin yli samalla tilillä, kieltäytyminen on kaukopäässä tai sovelluksen omassa käytännössä. Jos se epäonnistuu molemmissa, VPN ei ole erottelija, ja sinun kannattaa lopettaa päätepisteiden testaaminen.
Vaihe 4: sovita todisteet yhteen kolmesta päätöksestä
Kolme yhdistelmää kattaa lähes jokaisen raportin. Kieltäytyminen ilman lähtevää yritystä tunnelin ollessa aktiivinen viittaa paikalliseen kuljetustarkistukseen. Pyyntö, joka lähtee ja palaa virheellä, tietyn isännän aikakatkaisulla tai aluetekstillä, viittaa kaukokantaan. Vika, joka toistuu mobiiliverkossa ilman tunnelia, viittaa tiliin, sovellusversioon tai palvelun omaan käytäntöön, eikä mikään VPN-muutos liikuta sitä.
Kirjoita päätös ylös sen tuottaneen todisteen kanssa. Tämän vaiheen arvo on, että se pysäyttää silmukan, jossa joku vaihtaa ulostulosolmuja neljä kertaa korjatakseen tarkistuksen, joka pyörii puhelimessa itsessään.
Se pitää myös väitteet rehellisinä. Itse ylläpitäminen vaihtaa päätepisteen ja sen internet-ulostulon; se ei saa Androidia unohtamaan aktiivista VPN-verkkoa eikä takaa hyväksyntää palvelussa, joka luokittelee osoitteita. Paikallinen suodatin voi laueta omassa VPN-verkossasi yhtä helposti kuin kaupallisessa.
Vaihe 5: kulje tuettu polku ja varmista se
Aloita tuotteen dokumentoidusta käytännöstä ja sen tukiomistajasta. Lähetä asiakasversio, tarkka viesti ja kapea vikaikkuna; älä lähetä täydellisiä liikenteen kaappauksia tai tunnistetietoja vain todistaaksesi, että virhe on olemassa.
Jos palvelu sallii suoran pääsyn ja laitteen käytäntö sallii sen, sovelluskohtainen poissulkeminen on tuettu mekanismi, ja se poistaa kyseisen sovelluksen tunnelista tarkoituksellisesti sen sijaan, että piilottaisi tunnelin. Sovelluksen liikenne lähtee silloin omaa polkuaan, mikä on käytäntöpäätös, joka jonkun on omistettava. Konfiguraatiossa, joka estää ilman VPN:ää, poissuljettu sovellus voi yksinkertaisesti menettää yhteyden, joten testaa tuo yhdistelmä ennen kuin lupaat sen toimivan.
Toista jokaisen muutoksen jälkeen vaiheen yksi ajoitustesti, varmista että sovellus toimii ja varmista että kaikki muut sovellukset käyttävät yhä tunnelia. Palauta sitten edellinen konfiguraatio ja tarkista, palaako vika, koska korjaus, jota et voi toistaa, on yhteensattuma, jonka kohtaat uudelleen.