Alkalmazásonkénti VPN felügyelt iPhone-alkalmazásokon: mi kerül átirányításra és mi nem

Az alkalmazásonkénti VPN az iPhone-on nem az egész telefon kapcsolója. Egy felügyelt alkalmazás és egy VPN hasznos adat közötti hozzárendelés, amely az alkalmazás telepítésekor jön létre, és minden más forgalma megtartja a korábbi útvonalát. Ezért ugyanaz a telefon következetlenül viselkedik: a munkaalkalmazás privát oldalt nyit, miközben a Safari nem éri el ugyanazt a gazdagépet, vagy az alagút egyáltalán nem jön fel, és az alkalmazás olyan időtúllépést jelent, amely rossz hitelesítő adatokra hasonlít. Az ellenőrzések a legszélesebb októl lefelé haladnak, ezért álljon meg az elsőnél, amelyik elbukik.

Először a hasznos adatot és az alkalmazásrekordot ellenőrizze

A hozzárendelés két objektumban él, nem egyben. A VPN hasznos adat határozza meg az alagút: típus, kiszolgáló, hitelesítés, DNS és a szolgáltató csomagazonosítója, ha egyéni klienst használnak. Az alkalmazásrekord erre a hasznos adatra mutat, és a legtöbb felügyeleti konzol ezt alkalmazásonkénti opcióként kínálja az alkalmazás konfigurációjában, a Per-App VPN-hez közeli névvel. Az a hasznos adat, amelyre egyetlen alkalmazás sem mutat, semmit nem irányít alkalmazásonként; úgy viselkedik, mint egy közönséges alagút, amelyet valakinek kézzel kell elindítania.

Olvassa el mindkét objektumot, mielőtt hozzányúl a telefonhoz. Erősítse meg, hogy az alkalmazás konfigurációja a tesztelt hasznos adatra hivatkozik, nem annak régebbi példányára, mert a csaknem azonos nevű duplikált hasznos adatok gyakoriak migráció után, és az alkalmazás szívesen mutat a visszavontra. Ezután erősítse meg, hogy a konfiguráció elérte az eszközt: a Beállítások, Általános, VPN és eszközkezelés alatt telepített profilként kell megjelennie. Az ottani VPN-lista nem a teszt. Az alkalmazásonkénti szolgáltatásnak általában nincs kézi kapcsolója, ezért egy helyesen telepített konfiguráció soha nem jelenhet meg az indítható VPN-ek között. A hiány az alkalmazásrekordban és abban látszik, hogy az alagút feljön-e az alkalmazás első kérésére.

Egy feltétel sok jegyet magyaráz: ehhez a modellhez az kell, hogy az alkalmazás felügyeleten keresztül érkezzen. A mellé telepített vagy személyesen vásárolt példány nem kapja meg a hozzárendelést, akkor sem, ha a csomagazonosítója megegyezik. Az Apple VPN-telepítési útmutatója leírja az e mögötti hasznosadat-modellt (support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web).

Erősítse meg, hogy a telepített alkalmazás a felügyelt példány

A hozzárendelés a telepített, felügyelt alkalmazást követi. Ha valaki személyes Apple ID-val újratelepítette az App Store-ból, újra-aláírt vállalati buildre cserélte, vagy az eszközt újra regisztrálták, és az alkalmazás más csatornán tért vissza, az alagút lent maradhat, miközben maga az alkalmazás teljesen normálisnak látszik.

Összehasonlítással teszteljen, ne egyetlen megfigyeléssel. A felügyeleti leltárban az alkalmazásnak az adott eszközhöz felügyeltként kell szerepelnie, a VPN-leképezéssel a rekordjában. A telefonon az alagútnak az alkalmazás indításakor és az első kérés kiindulásakor kell feljönnie, nem csak akkor, amikor valaki külön kézi konfigurációt indít a Beállításokban. Ha az alkalmazás indítása semmit nem változtat, a kézi konfiguráció viszont igen, az alkalmazás egyáltalán nincs alkalmazásonkénti alagúthoz kötve.

A frissítések számítanak: a felügyeleten keresztül küldött megtartja a leképezést, a felhasználó által indított újratelepítés viszont elveszítheti. Ha a panasz egy frissítéstől datálódik, a hálózat előtt ellenőrizze az alkalmazásrekordot.

Ellenőrizze, mit vehet át az alagút

Az alkalmazásonkénti alagút a forrásalkalmazás választja ki, ezért a telefon alapértelmezett útvonala továbbra is a Wi-Fihez vagy a mobilhálózathoz tartozik. Az OverridePrimary az a kulcs, amely ezt megváltoztatja. Ha egy profil beállítja, az alagút teljes alagútként viselkedik, és minden alkalmazás örökli, így minden, ami a VPN-en át megy, profilkerdéssé válik, nem alkalmazáshibává.

Az igény szerinti szabályok döntik el a tartósságot. Az OnDemandEnabled és szabálykészlete az, ami visszahozza az alagút, amikor az alkalmazás forgalmat küld, túléli a Wi-Fi-ről mobilhálózatra váltást, vagy leesik, amikor az alkalmazás háttérbe kerül. Az a telepítés, amely csatlakozik, majd csendben meghal, általában olyan szabállyal rendelkezik, amely csak egy olyan próbához illik, amely soha nem indul be, miközben az alkalmazás tétlen.

Utána olvassa el őszintén az útvonalak oldalát. Ha a szolgáltatói vagy gyártói profil befoglalási listát ad, a csak 10.20.0.0/16-ot vivő alagút nem visz szolgáltatást a 10.30.0.0/16-ban; ez a lista végzi a dolgát, nem alkalmazásonkénti hiba. A beépített iOS hasznos adatnak nincs befoglalási listája. Enélkül a felosztás a szolgáltató alapértékeit és az IncludeAllNetworks-t követi, nem egy rejtett listát.

Tesztelje az alkalmazást, majd azt, ami kijön belőle

Névvel teszteljen, ne csak címmel. Egy belső gazdagép feloldása a felügyelt alkalmazáson belül bizonyítja, hogy a DNS is az alagúton ment át, mert a hasznos adat dönti el, melyik feloldó válaszol, és mely keresési tartományok érvényesek. Az útválasztás tökéletes lehet, miközben a névkeresés elbukik, és a két tünet különböző beállításokra mutat.

Utána tesztelje a határt mindkét oldalról. Egy személyes alkalmazásnak vagy a Safarinak el kell érnie egy közönséges nyilvános oldalt, és jelentenie kell a szolgáltató vagy az otthoni címet, miközben a felügyelt alkalmazás eléri a privát szolgáltatást. Ha mindkettő ugyanazt a nyilvános címet jelenti, az alagút már nem alkalmazásonkénti, bármit is állít az alkalmazásrekord.

Az alkalmazást elhagyó folyamatok okozzák a zavaros jegyeket. A Safariban megnyíló hivatkozás, a megosztólapon átadott dokumentum vagy a böngészőre váltó SSO-bejelentkezés elhagyja az alkalmazás folyamatát és vele az alagút. Az alkalmazáson belül megjelenített bejelentkezés általában az alkalmazásnak tulajdonítható, ezért a beágyazott bejelentkezés sikerülhet ott, ahol ugyanaz az URL a Safariban elbukik; ezt ellenőrizze, ne feltételezze. Ha az identitásszolgáltató csak az alagúton érhető el, tartsa a bejelentkezést az alkalmazáson belül, vagy vegye fel a szolgáltató tartományát a hasznos adat Safari-tartományai közé, hogy a megfelelő Safari-forgalom elkapható legyen.

Párosítsa a tünetet a réteggel

A hiba alakja megmondja, melyik ellenőrzést kell megismételni.

A középső sorok mögött két részlet áll: az alkalmazásonkénti alagút egészséges lehet, és mégis kihagyhat egy alhálózatot, amelyet egyetlen szolgáltatói lista sem tartalmaz, és egy felügyelt telefon több VPN-konfigurációt is tarthat, ezért erősítse meg, melyikhez van kötve az alkalmazás, ahelyett hogy azt feltételezne, hogy az, amelyiket olvassa.

Ebben a sorrendben javítson: javítsa az alkalmazásrekordot, hogy az élő hasznos adatra hivatkozzon, telepítse újra az alkalmazást felügyeleten keresztül, erősítse meg, hogy az alagút az első kérésre feljön, majd ismételje meg a név- és határteszteket. Ha az első kérés egyáltalán nem tud alagút indítani, álljon meg, és ellenőrizze a szolgáltatói oldalt, mert az egyéni kliensnek szüksége van a Network Extension jelenlétére és a telepített alkalmazáshoz illő azonosítóra.

Három tényt adjon vissza képernyőkép helyett: melyik hasznos adatra hivatkozik az alkalmazásrekord, a Beállítások telepített profilként mutatják-e, és mi volt a sikertelen kérés, egy név, egy cím vagy egy böngészőátadás. Ez a három válasz elválasztja a telepítési hibát az útvonalválasztási hibától, és a következő ember a diagnózis megismétlése nélkül cselekedhet.