VPN sipas aplikacionit në iPhone-t e menaxhuara: çfarë rutohet dhe çfarë jo
Një tunel sipas aplikacionit ndjek aplikacionin e menaxhuar, jo telefonin. Kontrolloni lidhjen e ngarkesës, kopjen e menaxhuar, rregullat me kërkesë dhe rrjedhat që dalin nga aplikacioni.
VPN-ja sipas aplikacionit në iPhone nuk është çelës për të gjithë telefonin. Është një lidhje midis një aplikacioni të menaxhuar dhe një ngarkese VPN, e krijuar kur aplikacioni vendoset, dhe trafiku i gjithçkaje tjetër mban rrugën që kishte. Prandaj i njëjti telefon sillet në mënyrë të paqëndrueshme: aplikacioni i punës hap një faqe private ndërsa Safari nuk arrin të njëjtin host, ose tuneli nuk ngrihet fare dhe aplikacioni raporton një skadim kohe që duket si kredenciale të gabuara. Kontrollet shkojnë nga shkaku më i gjerë poshtë, prandaj ndaloni te i pari që dështon.
Fillimisht kontrolloni ngarkesën dhe regjistrin e aplikacionit
Lidhja jeton në dy objekte, jo në një. Ngarkesa VPN përcakton tunelin: llojin, serverin, vërtetimin, DNS-në dhe identifikuesin e paketës së ofruesit kur përdoret një klient i personalizuar. Regjistri i aplikacionit tregon drejt asaj ngarkese, dhe shumica e konsolave të menaxhimit e ofrojnë këtë si opsion sipas aplikacionit në konfigurimin e aplikacionit, me një emër afër Per-App VPN. Një ngarkesë drejt së cilës nuk tregon asnjë aplikacion nuk rruton asgjë sipas aplikacionit; sillet si një tunel i zakonshëm që dikush duhet ta nisë me dorë.
Lexoni të dy objektet përpara se të prekni telefonin. Konfirmoni që konfigurimi i aplikacionit tregon drejt ngarkesës që po testoni dhe jo drejt një kopjeje të vjetër të saj, sepse ngarkesat e dyfishta me emra pothuajse identikë janë të zakonshme pas migrimit dhe aplikacioni tregon me kënaqësi drejt asaj të tërhequr. Pastaj konfirmoni që konfigurimi ka arritur në pajisje: Cilësimet, Të përgjithshme, VPN dhe Menaxhimi i Pajisjes duhet ta shfaqin si profil të instaluar. Lista e VPN-ve atje nuk është testi. Një shërbim sipas aplikacionit zakonisht nuk ka çelës manual, prandaj një konfigurim i vendosur saktë mund të mos shfaqet kurrë mes VPN-ve që mund të nisen. Mungesa shihet në regjistrin e aplikacionit dhe në atë nëse tuneli ngrihet në kërkesën e parë të aplikacionit.
Një kusht shpjegon shumë bileta: ky model kërkon që aplikacioni të vijë përmes menaxhimit. Një kopje e instaluar anash ose e blerë personalisht nuk e merr lidhjen, edhe kur identifikuesi i paketës përputhet. Udhëzuesi i Apple për vendosjen e VPN përshkruan modelin e ngarkesës pas kësaj (support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web).
Konfirmoni që aplikacioni i instaluar është kopja e menaxhuar
Lidhja ndjek aplikacionin e instaluar dhe të menaxhuar. Nëse dikush e riinstaloi nga App Store me një Apple ID personal, e zëvendësoi me një ndërtim korporativ të rinënshkruar, ose pajisja u regjistrua përsëri dhe aplikacioni u kthye përmes një kanali tjetër, tuneli mund të mbetet poshtë ndërsa vetë aplikacioni duket plotësisht normal.
Testoni me krahasim, jo me një vëzhgim. Në inventarin e menaxhimit aplikacioni duhet të shfaqet si i menaxhuar për atë pajisje me hartëzimin VPN në regjistrin e tij. Në telefon tuneli duhet të ngrihet kur aplikacioni niset dhe kur del kërkesa e tij e parë, jo vetëm kur dikush nis një konfigurim manual të veçantë në Cilësimet. Nëse nisja e aplikacionit nuk ndryshon asgjë dhe ai konfigurim manual ndryshon, aplikacioni nuk është fare i lidhur me një tunel sipas aplikacionit.
Përditësimet kanë rëndësi: ai i shtyrë përmes menaxhimit e mban hartëzimin, ndërsa një riinstalim i nisur nga përdoruesi mund ta humbasë. Kur ankesa daton nga një përditësim, kontrolloni regjistrin e aplikacionit përpara rrjetit.
Kontrolloni çfarë mund të marrë tuneli
Një tunel sipas aplikacionit zgjidhet nga aplikacioni burim, prandaj rruga e paracaktuar e telefonit ende i përket Wi-Fi-t ose rrjetit celular. OverridePrimary është çelësi që e ndryshon këtë. Kur një profil e vendos, tuneli sillet si tunel i plotë dhe çdo aplikacion e trashëgon, prandaj gjithçka që kalon nëpër VPN bëhet çështje profili dhe jo defekt i aplikacionit.
Rregullat me kërkesë vendosin këmbënguljen. OnDemandEnabled dhe grupi i rregullave të tij e kthejnë tunelin kur aplikacioni dërgon trafik, i mbijetojnë kalimit nga Wi-Fi në celular ose e ulin kur aplikacioni kalon në sfond. Një vendosje që lidhet dhe pastaj vdes në heshtje zakonisht ka një rregull që përputhet vetëm me një sondë që nuk aktivizohet kurrë ndërsa aplikacioni është i papunë.
Pastaj lexoni anën e rrugëve me ndershmëri. Nëse profili i ofruesit ose shitësit jep një listë përfshirjeje, një tunel që mban vetëm 10.20.0.0/16 nuk do të mbajë shërbim në 10.30.0.0/16; ajo është lista që bën punën e vet, jo një defekt sipas aplikacionit. Ngarkesa e integruar e iOS nuk ka listë përfshirjeje. Pa të ndarja ndjek parazgjedhjet e ofruesit dhe IncludeAllNetworks, jo një listë të fshehur.
Testoni aplikacionin, pastaj testoni çfarë del prej tij
Testoni me emër, jo vetëm me adresë. Zgjidhja e një hosti të brendshëm brenda aplikacionit të menaxhuar vërteton që edhe DNS-ja kaloi përmes tunelit, sepse ngarkesa përcakton cili zgjidhës përgjigjet dhe cilat domene kërkimi zbatohen. Rrutimi mund të jetë i përsosur ndërsa kërkimi i emrit dështon, dhe dy simptomat tregojnë cilësime të ndryshme.
Pastaj testoni kufirin nga të dy anët. Një aplikacion personal ose Safari duhet të arrijë një faqe publike të zakonshme dhe të raportojë adresën e operatorit ose të shtëpisë, ndërsa aplikacioni i menaxhuar arrin shërbimin privat. Nëse të dy raportojnë të njëjtën adresë publike, tuneli nuk është më sipas aplikacionit, çfarëdo që pretendon regjistri i aplikacionit.
Rrjedhat që dalin nga aplikacioni krijojnë bileta konfuze. Një lidhje që hapet në Safari, një dokument i kaluar përmes fletës së ndarjes ose një hyrje SSO që kalon në një shfletues e lënë procesin e aplikacionit dhe tunelin me të. Një hyrje e shfaqur brenda aplikacionit zakonisht i atribuohet aplikacionit, prandaj një hyrje e integruar mund të ketë sukses aty ku i njëjti URL dështon në Safari; verifikojeni këtë në vend që ta supozoni. Kur ofruesi i identitetit është i arritshëm vetëm përmes tunelit, mbani hyrjen brenda aplikacionit ose shtoni domenin e ofruesit te domenet Safari të ngarkesës, që trafiku përkatës Safari të kapet.
Përputhni simptomën me shtresën
Forma e defektit ju tregon cilën kontroll të përsërisni.
| 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 |
Pas rreshtave të mesëm qëndrojnë dy detaje: një tunel sipas aplikacionit mund të jetë i shëndetshëm dhe gjithsesi të humbasë një nënrrjet që nuk përfshihet në asnjë listë ofruesi, dhe një telefon i menaxhuar mund të mbajë më shumë se një konfigurim VPN, prandaj konfirmoni se me cilin është lidhur aplikacioni në vend që të supozoni se është ai që po lexoni.
Rregulloni në këtë rend: drejtoni regjistrin e aplikacionit te ngarkesa aktive, riinstaloni aplikacionin përmes menaxhimit, konfirmoni që tuneli ngrihet në kërkesën e parë të aplikacionit, pastaj përsëritni testet e emrit dhe kufirit. Nëse kërkesa e parë nuk mund të nisë fare tunel, ndaloni dhe kontrolloni anën e ofruesit, sepse një klient i personalizuar ka nevojë për Network Extension ekzistues dhe një identifikues që përputhet me aplikacionin e instaluar.
Ktheni tre fakte në vend të një pamjeje ekrani: drejt cilit ngarkesë tregon regjistri i aplikacionit, nëse Cilësimet e shfaqin si profil të instaluar dhe cila ishte kërkesa e dështuar — një emër, një adresë ose një kalim në shfletues. Këto tre përgjigje ndajnë një gabim vendosjeje nga një gabim rrutimi, dhe personi tjetër mund të veprojë pa përsëritur diagnozën.