Sovelluskohtainen VPN hallituissa iPhone-sovelluksissa: mitä reititetään ja mitä ei
Sovelluskohtainen tunneli seuraa hallittua sovellusta, ei puhelinta. Tarkista profiilin kytkentä, hallittu kopio, on-demand-säännöt ja sovelluksesta lähtevät virrat.
Sovelluskohtainen VPN ei ole iPhonessa koko puhelimen kytkin. Se on yhden hallitun sovelluksen ja yhden VPN-profiilin välinen kytkentä, joka syntyy sovellusta käyttöönotettaessa, ja kaiken muun liikenne säilyttää aiemman reittinsä. Siksi sama puhelin käyttäytyy epäjohdonmukaisesti: työsovellus avaa yksityisen sivun, kun taas Safari ei tavoita samaa isäntää, tai tunneli ei nouse lainkaan ja sovellus ilmoittaa aikakatkaisusta, joka näyttää huonoilta tunnuksilta. Tarkistukset etenevät laajimmasta syystä alaspäin, joten pysähdy ensimmäiseen, joka epäonnistuu.
Tarkista ensin profiili ja sovellustietue
Kytkentä elää kahdessa objektissa, ei yhdessä. VPN-profiili määrittelee tunnelin: tyyppi, palvelin, todennus, DNS ja tarjoajan pakettitunniste, kun käytetään mukautettua asiakasta. Sovellustietue osoittaa tuohon profiiliin, ja useimmat hallintakonsolit tarjoavat tämän sovelluskohtaisena vaihtoehtona sovelluksen kokoonpanossa, nimellä lähellä Per-App VPN:ää. Profiili, johon mikään sovellus ei osoita, ei reititä mitään sovelluskohtaisesti; se käyttäytyy kuin tavallinen tunneli, joka jonkun on käynnistettävä käsin.
Lue molemmat objektit ennen kuin kosket puhelinta. Vahvista, että sovelluksen kokoonpano viittaa testaamaasi profiiliin eikä sen vanhempaan kopioon, sillä lähes samannimiset kaksoisprofiilit ovat yleisiä migraation jälkeen ja sovellus osoittaa mielellään poistettuun. Vahvista sitten, että kokoonpano saapui laitteelle: Asetukset, Yleiset, VPN ja laitehallinta näyttävät sen asennettuna profiilina. VPN-luettelo siellä ei ole testi. Sovelluskohtaisella palvelulla ei yleensä ole käsikytkintä, joten oikein käyttöönotettu kokoonpano ei ehkä koskaan näy käynnistettävien VPN:ien joukossa. Puuttuminen näkyy sovellustietueessa ja siinä, nouseeko tunneli sovelluksen ensimmäisellä pyynnöllä.
Yksi ehto selittää monta tikettiä: tämä malli vaatii, että sovellus tulee hallinnan kautta. Sivulta asennettu tai henkilökohtaisesti ostettu kopio ei saa kytkentää, vaikka sen pakettitunniste täsmäisi. Applen VPN:n käyttöönotto-opas kuvaa tämän taustalla olevan profiilimallin (support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web).
Vahvista, että asennettu sovellus on hallittu kopio
Kytkentä seuraa asennettua, hallittua sovellusta. Jos joku asensi sen uudelleen App Storesta henkilökohtaisella Apple ID:llä, korvasi sen uudelleen allekirjoitetulla yritysversiolla tai laite rekisteröitiin uudelleen ja sovellus palasi toista kanavaa, tunneli voi pysyä alhaalla, kun taas sovellus näyttää täysin normaalilta.
Testaa vertaamalla, ei yksittäisellä havainnolla. Hallintaluettelossa sovelluksen pitää näkyä kyseiselle laitteelle hallittuna VPN-kartoitus tietueessaan. Puhelimessa tunnelin pitää nousta, kun sovellus käynnistetään ja sen ensimmäinen pyyntö lähtee, ei vain kun joku käynnistää erillisen manuaalisen kokoonpanon Asetuksissa. Jos sovelluksen käynnistäminen ei muuta mitään ja tuo manuaalinen kokoonpano muuttaa, sovellus ei ole lainkaan sidottu sovelluskohtaiseen tunneliin.
Päivitykset merkitsevät: hallinnan kautta työnnetty säilyttää kartoituksen, kun taas käyttäjän aloittama uudelleenasennus voi menettää sen. Kun valitus ajoittuu päivitykseen, tarkista sovellustietue ennen verkkoa.
Tarkista, mitä tunneli saa ottaa
Sovelluskohtainen tunneli valitaan lähdesovelluksen mukaan, joten puhelimen oletusreitti kuuluu edelleen Wi-Fi:lle tai matkapuhelinverkolle. OverridePrimary on avain, joka muuttaa sen. Kun profiili asettaa sen, tunneli käyttäytyy kuin täysi tunneli ja jokainen sovellus perii sen, joten kaikki VPN:n kautta tulee profiilikysymykseksi eikä sovellusviaksi.
On-demand-säännöt ratkaisevat pysyvyyden. OnDemandEnabled ja sen sääntöjoukko saavat tunnelin palaamaan, kun sovellus lähettää liikennettä, selviytymään siirtymästä Wi-Fi:stä matkapuhelinverkkoon tai putoamaan, kun sovellus siirtyy taustalle. Käyttöönotto, joka yhdistää ja kuolee sitten hiljaa, sisältää yleensä säännön, joka vastaa vain koetinta, joka ei koskaan laukea sovelluksen ollessa joutilaana.
Lue sitten reittipuoli rehellisesti. Jos tarjoajan tai toimittajan profiili antaa sisällytysluettelon, vain 10.20.0.0/16:tä kantava tunneli ei kanna palvelua 10.30.0.0/16:ssa; luettelo tekee tehtävänsä, ei sovelluskohtainen vika. Sisäänrakennetussa iOS-profiilissa ei ole sisällytysluetteloa. Ilman sitä jako seuraa tarjoajan oletuksia ja IncludeAllNetworksia, ei piilotettua luetteloa.
Testaa sovellus ja sitten se, mitä siitä lähtee
Testaa nimellä, ei vain osoitteella. Sisäisen isännän ratkaiseminen hallitun sovelluksen sisällä todistaa, että myös DNS kulki tunnelin läpi, koska profiili päättää, mikä ratkaisija vastaa ja mitkä hakualueet otetaan käyttöön. Reititys voi olla täydellinen, kun nimihaku epäonnistuu, ja kaksi oiretta osoittavat eri asetuksiin.
Testaa sitten raja molemmilta puolilta. Henkilökohtaisen sovelluksen tai Safarin pitäisi tavoittaa tavallinen julkinen sivu ja raportoida operaattorin tai kodin osoite, kun taas hallittu sovellus tavoittaa yksityisen palvelun. Jos molemmat raportoivat saman julkisen osoitteen, tunneli ei ole enää sovelluskohtainen, mitä sovellustietue väittääkin.
Sovelluksesta lähtevät virrat tuottavat sekavat tiketit. Safarissa avautuva linkki, jakolevyn kautta siirretty asiakirja tai selaimelle siirtyvä SSO-kirjautuminen lähtee sovelluksen prosessista ja tunneli mukanaan. Sovelluksen sisällä näytetty kirjautuminen liitetään yleensä sovellukseen, joten upotettu kirjautuminen voi onnistua siellä, missä sama URL epäonnistuu Safarissa; varmista se sen sijaan, että olettaisit. Kun identiteettitarjoaja on tavoitettavissa vain tunnelin kautta, joko pidä kirjautuminen sovelluksen sisällä tai lisää tarjoajan verkkotunnus profiilin Safari-verkkotunnuksiin, jotta vastaava Safari-liikenne kaapataan.
Sovita oire kerrokseen
Vian muoto kertoo, mikä tarkistus toistetaan.
| What you see | Where the repair is |
|---|---|
| Tunnel never appears when the app opens | App-to-payload association, or the app is not the managed copy |
| Tunnel connects, internal name resolves, connection times out | Provider or vendor include list missing the subnet, or a far-side firewall |
| Tunnel connects, internal name fails to resolve | DNS servers or search domains in the payload |
| Every app uses the tunnel | OverridePrimary set, or a full-tunnel payload reused |
| Worked until an update, broken since | Association lost on reinstall, or the payload was replaced |
Keskirivien takana on kaksi yksityiskohtaa: sovelluskohtainen tunneli voi olla terve ja silti ohittaa aliverkon, jota mikään tarjoajan luettelo ei sisällä, ja hallittu puhelin voi pitää useampaa kuin yhtä VPN-kokoonpanoa, joten vahvista, mihin sovellus on sidottu, älä oleta sen olevan se, jota luet.
Korjaa tässä järjestyksessä: korjaa sovellustietue viittaamaan elävään profiiliin, asenna sovellus uudelleen hallinnan kautta, vahvista että tunneli nousee sovelluksen ensimmäisellä pyynnöllä ja toista sitten nimi- ja rajatesti. Jos ensimmäinen pyyntö ei voi lainkaan käynnistää tunnelia, pysähdy ja tarkista tarjoajan puoli, koska mukautettu asiakas tarvitsee läsnä olevan Network Extensionin, jonka tunniste vastaa asennettua sovellusta.
Palauta kolme tosiasiaa kuvakaappauksen sijaan: mihin profiiliin sovellustietue viittaa, näyttävätkö Asetukset sen asennettuna profiilina ja mikä epäonnistunut pyyntö oli, nimi, osoite vai selainsiirto. Ne kolme vastausta erottavat käyttöönoton virheen reititysvirheestä, ja seuraava henkilö voi toimia toistamatta diagnoosia.