VPN pe aplicație pe iPhone-uri administrate: ce este rutat și ce nu
Un tunel pe aplicație urmează aplicația administrată, nu telefonul. Verificați asocierea încărcăturii, copia administrată, regulile la cerere și fluxurile care ies din aplicație.
VPN-ul pe aplicație pe iPhone nu este un întrerupător pentru tot telefonul. Este o asociere între o aplicație administrată și o încărcătură VPN, creată când aplicația este implementată, iar traficul tuturor celorlalte păstrează ruta pe care o avea. De aceea același telefon se comportă inconsecvent: aplicația de lucru deschide o pagină privată, în timp ce Safari nu ajunge la același host, sau tunelul nu urcă deloc și aplicația raportează un timeout care arată ca acreditări greșite. Verificările merg de la cea mai largă cauză în jos, așa că opriți-vă la prima care eșuează.
Verificați mai întâi încărcătura și înregistrarea aplicației
Asocierea trăiește în două obiecte, nu într-unul. Încărcătura VPN definește tunelul: tip, server, autentificare, DNS și identificatorul pachetului furnizorului când se folosește un client personalizat. Înregistrarea aplicației indică spre acea încărcătură, iar majoritatea consolelor de administrare oferă asta ca opțiune pe aplicație în configurația aplicației, cu un nume apropiat de Per-App VPN. O încărcătură spre care nu indică nicio aplicație nu rutează nimic pe aplicație; se comportă ca un tunel obișnuit pe care cineva trebuie să îl pornească manual.
Citiți ambele obiecte înainte de a atinge telefonul. Confirmați că configurația aplicației indică încărcătura pe care o testați și nu o copie veche a ei, pentru că încărcăturile duplicate cu nume aproape identice sunt frecvente după migrare, iar aplicația indică bucuroasă spre cea retrasă. Apoi confirmați că configurația a ajuns pe dispozitiv: Setări, General, VPN și gestionarea dispozitivului trebuie să o arate ca profil instalat. Lista de VPN de acolo nu este testul. Un serviciu pe aplicație nu are de obicei întrerupător manual, așa că o configurație implementată corect poate să nu apară niciodată între VPN-urile care pot fi pornite. Absența se vede în înregistrarea aplicației și în dacă tunelul urcă la prima cerere a aplicației.
O condiție explică multe tichete: acest model cere ca aplicația să vină prin administrare. O copie instalată lateral sau cumpărată personal nu primește asocierea, chiar dacă identificatorul pachetului se potrivește. Ghidul Apple de implementare VPN descrie modelul de încărcătură din spate (support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web).
Confirmați că aplicația instalată este copia administrată
Asocierea urmează aplicația instalată și administrată. Dacă cineva a reinstalat-o din App Store cu un Apple ID personal, a înlocuit-o cu o versiune de întreprindere resemnată sau dispozitivul a fost reînregistrat și aplicația a revenit pe alt canal, tunelul poate rămâne jos în timp ce aplicația în sine pare complet normală.
Testați prin comparație, nu cu o singură observație. În inventarul de administrare, aplicația trebuie să apară ca administrată pentru acel dispozitiv, cu maparea VPN în înregistrarea ei. Pe telefon, tunelul trebuie să urce când aplicația este lansată și prima ei cerere iese, nu doar când cineva pornește o configurație manuală separată în Setări. Dacă lansarea aplicației nu schimbă nimic, iar acea configurație manuală schimbă, aplicația nu este deloc legată de un tunel pe aplicație.
Actualizările contează: cea împinsă prin administrare păstrează maparea, în timp ce o reinstalare pornită de utilizator o poate pierde. Când reclamația este datată de la o actualizare, verificați înregistrarea aplicației înainte de rețea.
Verificați ce poate lua tunelul
Un tunel pe aplicație este ales după aplicația sursă, așa că ruta implicită a telefonului aparține încă Wi-Fi-ului sau rețelei celulare. OverridePrimary este cheia care schimbă asta. Când un profil o setează, tunelul se comportă ca un tunel complet și fiecare aplicație îl moștenește, așa că tot ce trece prin VPN devine o chestiune de profil, nu o defecțiune a aplicației.
Regulile la cerere decid persistența. OnDemandEnabled și setul său de reguli readuc tunelul când aplicația trimite trafic, supraviețuiesc trecerii de la Wi-Fi la celular sau îl coboară când aplicația intră în fundal. O implementare care se conectează și apoi moare în liniște are de obicei o regulă care se potrivește doar cu o sondă ce nu se declanșează niciodată cât timp aplicația este inactivă.
Apoi citiți partea rutelor cu onestitate. Dacă profilul furnizorului sau al vânzătorului oferă o listă de includere, un tunel care poartă doar 10.20.0.0/16 nu va purta serviciu în 10.30.0.0/16; aceea este lista care își face treaba, nu o defecțiune pe aplicație. Încărcătura iOS încorporată nu are listă de includere. Fără ea, împărțirea urmează valorile implicite ale furnizorului și IncludeAllNetworks, nu o listă ascunsă.
Testați aplicația, apoi testați ce iese din ea
Testați cu nume, nu doar cu adresă. Rezolvarea unui host intern în aplicația administrată dovedește că și DNS-ul a trecut prin tunel, pentru că încărcătura decide care resolver răspunde și ce domenii de căutare se aplică. Rutarea poate fi perfectă în timp ce căutarea numelui eșuează, iar cele două simptome indică setări diferite.
Apoi testați granița din ambele părți. O aplicație personală sau Safari ar trebui să ajungă la o pagină publică obișnuită și să raporteze adresa operatorului sau de acasă, în timp ce aplicația administrată ajunge la serviciul privat. Dacă ambele raportează aceeași adresă publică, tunelul nu mai este pe aplicație, orice ar afirma înregistrarea aplicației.
Fluxurile care ies din aplicație produc tichete confuze. Un link care se deschide în Safari, un document trimis prin foaia de partajare sau o autentificare SSO care trece la un browser părăsesc procesul aplicației și tunelul cu el. O autentificare afișată în aplicație este de obicei atribuită aplicației, așa că autentificarea încorporată poate reuși acolo unde același URL eșuează în Safari; verificați asta în loc să presupuneți. Când furnizorul de identitate este accesibil doar prin tunel, păstrați autentificarea în aplicație sau adăugați domeniul furnizorului la domeniile Safari ale încărcăturii, ca traficul Safari potrivit să fie prins.
Potriviți simptomul cu stratul
Forma defecțiunii spune ce verificare trebuie repetată.
| 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 |
În spatele rândurilor din mijloc stau două detalii: un tunel pe aplicație poate fi sănătos și totuși poate rata o subrețea pe care nu o include nicio listă a furnizorului, iar un telefon administrat poate ține mai mult de o configurație VPN, așa că stabiliți de care este legată aplicația în loc să presupuneți că este cea pe care o citiți.
Remediați în această ordine: îndreptați înregistrarea aplicației spre încărcătura activă, reinstalați aplicația prin administrare, confirmați că tunelul urcă la prima cerere a aplicației, apoi repetați teste de nume și graniță. Dacă prima cerere nu poate porni deloc un tunel, opriți-vă și verificați partea furnizorului, pentru că un client personalizat are nevoie de Network Extension existent și de un identificator care corespunde aplicației instalate.
Întoarceți trei fapte în loc de o captură de ecran: spre ce încărcătură indică înregistrarea aplicației, dacă Setările o arată ca profil instalat și care a fost cererea eșuată — un nume, o adresă sau o trecere la browser. Aceste trei răspunsuri separă o eroare de implementare de una de rutare, iar următoarea persoană poate acționa fără a repeta diagnosticul.