Miért nem tud rendszer-VPN-profilt hozzáadni az Android-alkalmazása

Megérinti a VPN sort a Beállításokban, lát egy profilt, amelyet valaki más telepített, és elkezdi keresni azt a hívást, amely hozzáad egyet. Ilyen hívás nincs. Az alkalmazás saját alagutat nyithat a VpnService-en keresztül, de a listán szereplő bejegyzések a platformhoz és ahhoz az ügyfélhez tartoznak, amely létrehozta őket. Annak pontos ismerete, hol húzódik a határ, egy hét keresgélést takarít meg a rejtett osztályok után.

Kezdje azzal, amit a Beállítások képernyő mutat

A VPN-lista azon profilok nyilvántartása, amelyeket a rendszer vagy egy gyártói ügyfél telepített: PPTP, L2TP/IPsec, IKEv2, és minden sor, amelyet egy OEM-alkalmazás vagy egy MDM betolt. Minden sor kiszolgálócímet, hitelesítő adatokat és egy folyamatán kívül élő protokoll-implementációt hordoz. Amikor a felhasználó ott a Csatlakozás gombra koppint, az alagutat a platform ügyfele emeli, nem az Ön kódja. Ezért éli túl a sor az újraindítást, és ezért nem távolítja el soha az alkalmazás eltávolítása.

A felhasználó oldaláról a lista API-felületnek tűnik, olyan helynek, ahol a VPN hozzáadása egyetlen szándéknyi távolságra kellene legyen. Nem az. Az egyetlen nyilvános belépési pontok, amelyek hozzáérnek, a navigációs szándékok, és minden, ami bele ír, a platformhoz vagy egy kiemelt összetevőhöz tartozik.

Gyakorlati következmény: ha egy támogatási szöveg azt mondja a felhasználóknak, hogy adják hozzá a profilt a Beállításokban, az alkalmazása egyáltalán nem része ennek a folyamatnak.

Amit a VpnService valóban ad Önnek

A VpnService és a VpnService.Builder egy alagutat ír le, amely az alkalmazásáé. Címeket, útvonalakat, DNS-kiszolgálókat és MTU-t ad hozzá, az addAllowedApplication() vagy az addDisallowedApplication() segítségével határolja a forgalmat, majd az establish() egy ParcelFileDescriptor-t ad vissza egy TUN-interfészhez. Attól a ponttól az alkalmazás IP-csomagokat olvas és válaszokat ír, ami azt jelenti, hogy a protokoll az Öné, megvalósítani vagy beágyazni: OpenVPN, WireGuard, saját átvitel.

Ebben a sorrendben semmi nem beszél PPTP-t, L2TP/IPsec-et vagy IKEv2-t. A Builderben nincs kapcsoló, amely azt mondaná, használd a rendszer L2TP-ügyfelét, és nincs visszahívás, amellyel a platform által már birtokolt profilt vezérelhetne. Ez az igazi határ, és ez tervezési határ, nem jogosultsági hiány.

Az alkalmazás tehát bátran lehet VPN-ügyfél az Androidon. Csak nem lehet a telefonnal érkező ügyfelek kezelője.

A hozzájárulási párbeszéd nem díszítés

Mivel az alagút elfoghatja más alkalmazások forgalmát, a rendszer megköveteli, hogy a felhasználó kifejezetten jóváhagyja. A prepare() egy Intentet ad vissza, amelyet el kell indítania, a jóváhagyás a csomagjához kötődik, és amíg az alagút fut, az állapotsor állandó jelzőt mutat. Egy második VPN feljövetele deaktiválja az elsőt, mert az Android egyszerre egy aktív VPN-t futtat.

Ez az egy-aktív szabály megbotlasztja az embereket teszteléskor. Felhozza az alagútját, miközben egy vállalati ügyfél csatlakozva van, és arra jut, hogy a kódja hibás, pedig a platform egyszerűen átváltott a másik ügyfélről. A jóváhagyások később visszavonhatók, és a prepare() null-t adhat vissza olyan eszközökön, ahol hiányzik a hozzájárulási tevékenység, így az establish()-nek továbbra is kezelnie kell a hibát.

Rejtett API-k és beállítási szándékok

A régebbi válaszok com.android.internal osztályokra és AIDL-interfészekre mutatnak, amelyeket a beépített ügyfél használ. Ezek nincsenek az SDK-ban, kiadások között figyelmeztetés nélkül változnak, és az alkalmazásboltok kockázatnak tekintik ezt a hozzáférést. Az eszköz rootolása sem teszi őket stabillá, mert a root és a rejtett API-hozzáférés független problémák.

A támogatott navigációs segédeszköz a Settings.ACTION_VPN_SETTINGS, amelynek értéke android.net.vpn.SETTINGS. Oldja fel indítás előtt, mert egyes OEM-buildok nem szállítják ezt a tevékenységet, és térjen át írott lépésekre, ha a feloldás meghiúsul. A felhasználót a képernyőre viszi, és semmit nem konfigurál.

Az eszköztulajdonos és MDM útvonalak az a kivétel, amelyre az emberek általában gondolnak. A DevicePolicyManager kijelölhet egy mindig bekapcsolt VPN-csomagot, és a felügyelt konfigurációk előtölthetnek beállításokat egy azt támogató ügyfélnek, de ez még mindig nem a nyilvános SDK, amely PPTP-profilt ír.

Járja be a döntést a felhasználó oldaláról

Ha a termékének forgalmat kell szállítania, tervezzen VpnService-t valódi protokollveremmel, és számoljon időt a hozzájárulási folyamatra és az egy-VPN szabályra. Ha a cél egy meglévő vállalati profilhoz csatlakozni, a munkája az útmutatás: mélyhivatkozás a beállítások képernyőre, a mezők dokumentálása, és hagyja, hogy a platform ügyfele végezze az alagutazást. Ha az alkalmazásnak csak egy privát végpontot kell elérnie, egyáltalán nincs szüksége saját alagútra.

Írja le ezt a döntést, mielőtt kódot ír, mert a három útnak az első sprint után szinte semmi közös vonása nincs.

Egy utolsó ellenőrzés indulás előtt: a követelmény azt mondja, hogy az alkalmazásunk csatlakozik, vagy hogy az eszköz csatlakozik? Az első a VpnService, a második egy profil, amelyet nem tud létrehozni. Azt a mondatot helyesen megfogalmazni olcsóbb, mint bármilyen refaktorálás.