Aplikacioni i punës kërkon VPN? Kontrolloni fillimisht këto tre shtresa

Mesazhi thotë se aplikacionit i duhet një VPN, por zakonisht aplikacioni raporton një simptom në vend që të emërtojë gjënë që e bllokoi. Tre përgjegjës të ndryshëm mund ta prodhojnë atë fjali: shërbimi privat me të cilin flet aplikacioni, kodi i politikës së vetë aplikacionit dhe shtresa e menaxhimit të pajisjes që kontrollon profilin e punës. Cili prej tyre po pyet ndryshon atë që duhet të bëni, dhe vetëm një nga të tre rregullohet duke lidhur një tunel. Gjetja e përgjegjësit fillimisht ju kursen riinstalimin e një klienti që nuk ishte kurrë problemi.

Çfarë mund të kontrollojë vetë aplikacioni

Përpara se të supozoni një rregull të fshehur të platformës, mbani mend se një aplikacion normal mund të shohë nëse transporti VPN është aktiv. ConnectivityManager raporton rrjetet që mbajnë TRANSPORT_VPN, dhe mungesa e NET_CAPABILITY_NOT_VPN i thotë çdo thirrësi se rruga aktuale kalon nëpër tunel. Një zhvillues që dëshiron të refuzojë të punojë jashtë një tuneli mund ta bëjë këtë me API publike dhe pa asnjë mjet ndërmarrjeje.

Ajo që aplikacioni nuk mund të shohë në këtë mënyrë është e kujt është VPN-i. Një flamur transporti thotë se ekziston një tunel, jo se ai përfundon aty ku pret organizata juaj.

Rruga e shërbimit: emra dhe adresa private

Versioni më i zakonshëm i sinqertë i mesazhit nuk është aspak një kontroll politike. Aplikacioni zgjidh një emër hosti të brendshëm, si një wiki ose një pikë fundore API që ekziston vetëm brenda pamjes DNS të korporatës, dhe kërkimi dështon përpara se të ekzekutohet ndonjë kod politike. Tuneli mund të jetë aktiv dhe të lejojë kalimin e trafikut të përgjithshëm të internetit, ndërsa DNS i ndarë e dërgon atë emër te një zgjidhës që nuk ka dëgjuar kurrë për të.

Simptomat këtu janë të ngushta. Një host dështon, thirrjet e tjera të rrjetit të aplikacionit funksionojnë, dhe dështimi shfaqet gjatë një kërkimi emri, jo në nisje. Certifikatat e brendshme shtojnë një mënyrë të dytë dështimi, sepse një aplikacion i fiksuar në CA-në e organizatës refuzon një certifikatë publike edhe kur paketat rrjedhin.

Lidhja e një VPN komerciale të rastësishme nuk rregullon asgjë nga kjo. Ndryshon adresën tuaj të daljes dhe e lë emrin e brendshëm po aq të pazgjidhshëm.

Shtresa e politikës së aplikacionit

Një aplikacion mund të mbajë edhe portën e vet. Konfigurimet e menaxhuara i lejojnë organizatës të dërgojë çifte çelësi dhe vlere që aplikacioni deklaron, dhe aplikacioni i lexon ato përmes RestrictionManager. Një çelës si një emër profili i kërkuar ose një listë rrjetesh të lejuara është tërësisht dizajni i zhvilluesit, i zbatuar në kodin e aplikacionit me çdo tekst gabimi që zgjedh ai kod.

Kjo shtresë është vendi ku formulimi zakonisht e tradhton veten. Nëse mesazhi shfaqet menjëherë në nisje, përpara çdo thirrjeje rrjeti, dhe përmend një politikë, një profil ose një administrator, me gjasë po shihni logjikën e aplikacionit dhe jo një paketë të rënë.

Leximi i të njëjtit kufizim në një pajisje personale është rrugë pa krye. Pajisjet e pamenaxhuara nuk kanë kufizime për të lexuar, kështu që aplikacioni bie përsëri në çdo vlerë të paracaktuar me të cilën u ndërtua.

Shtresa e platformës: gjithmonë aktive dhe bllokim

Menaxhimi i pajisjes shtoi zbatim që aplikacioni nuk mund ta anashkalojë. Një kontrollues i politikës së pajisjes mund të thërrasë setAlwaysOnVpnPackage për profilin e punës, opsionalisht me bllokimin të aktivizuar, dhe pasi bllokimi është ndezur platforma refuzon trafikun që nuk kalon përmes atij pakete. Bllokimi shihet si kusht i sistemit dhe jo si gabim i aplikacionit: edhe aplikacionet e tjera në profil ndalojnë së arrituri rrjetin.

Shtrirja ka rëndësi. VPN-i gjithmonë aktiv konfigurohet për çdo përdorues, kështu që një paketë e profilit të punës nuk mbulon profilin tuaj personal, dhe një VPN personal nuk plotëson paketën e profilit të punës. Dy profile, dy politika rrjeti të pavarura, një pajisje.

Kjo është gjithashtu shtresa e vetme ku një VPN i palidhur nuk mund të ndihmojë, sepse politika emërton një paketë të caktuar.

Të dallosh të tre

Kalon nëpër sinjalet sipas radhës dhe ndaloni te i pari që përputhet. Një emër hosti dështon ndërsa gjithçka tjetër zgjidhet, tregon rrugën e shërbimit. Një refuzim i menjëhershëm në nisje me formulim politike tregon logjikën e aplikacionit. Një profil i tërë që humbet lidhjen sa herë shkëputet klienti i miratuar tregon bllokimin. Dhe një aplikacion që pranon çdo tunel po kontrollon flamurin e transportit, jo identitetin e organizatës tuaj.

Prova të dobishme: teksti i saktë dhe koha e tij, nëse aplikacionet e tjera në të njëjtin profil kanë ende lidhje, nëse emri privat zgjidhet brenda tunelit të miratuar dhe nëse pajisja shfaq një shenjë pune për aplikacionin që hapët.

Çfarë të vendosni në kërkesën për mbështetje

Një kërkesë që emërton shtresën drejtohet saktë në provën e parë. Diçka si: aplikacioni i profilit të punës hapet, lista e burimeve dështon pasi lidhet VPN-i i miratuar, zgjidhja e emrit privat dështon në diagnostifikimin e lejuar, dhe aplikacionet e tjera në profil vazhdojnë të punojnë. Kjo lexohet si problem rruge ose zgjidhësi dhe kalon ciklin e rivendosjes së llogarisë.

Nëse VPN-i i miratuar mungon plotësisht, rruga e mbështetur është regjistrimi ose riprovisionimi përmes administratorit tuaj. Heqja e profilit të menaxhimit, instalimi i një klienti të palidhur ose falsifikimi i gjendjes së rrjetit ndryshon rregullimin e sigurisë në vend që ta rivendosë atë.

Filloni me shtresën, jo me klientin. Tre sinjalet më sipër zakonisht e zgjidhin çështjen në një sesion të vetëm.