Dy VPN në një telefon të vetëm: zgjidhni rregullimin, jo numrin e aplikacioneve

Përdorimi i dy VPN-ve nuk është një kërkesë e vetme. Mund të nënkuptojë arritjen e dy organizatave njëra pas tjetrës, mbajtjen të ndara të aplikacioneve të punës dhe atyre personale, ose ekzekutimin e një tuneli brenda një tjetri. Android i trajton këto tre raste në mënyra krejt të ndryshme, dhe numri i aplikacioneve VPN të instaluara në telefon nuk është arkitektura. Pyetja që i ndan është e thjeshtë: a duhet të ekzistojnë dy rrugë në të njëjtin moment për të njëjtin aplikacion?

Tre rregullime, një pyetje

Nëse përgjigja është jo, sepse dy rrjetet përdoren në kohë të ndryshme, ju dëshironi një ndërrim të qëllimshëm. Nëse përgjigja është jo sepse vetë aplikacionet janë të ndara, ju dëshironi ndarje profilesh, ku çdo aplikacion qëndron në kontekstin që zotëron tunelin e vet. Nëse përgjigja është po, dhe një rrugë duhet ta mbajë fizikisht tjetrën, ju dëshironi një zinxhir, dhe ky është i vetmi nga të tre ku rendi është pjesë e modelit.

Çdo gjë tjetër rrjedh nga ajo zgjedhje. Ndërrimi ka një dritare kalimi, ndarja ka një kufi politike, dhe një zinxhir ka një kosto shtesë dhe një kosto varësie. Zgjedhja e të gabuarës nuk dështon pastër; prodhon një telefon që duket i lidhur dhe një aplikacion që nuk arrin asgjë.

Ndërrim brenda një konteksti të vetëm përdoruesi

Android lejon një shërbim aktiv VPN për përdorues. Nisja e një aplikacioni të dytë VPN në të njëjtin kontekst zëvendëson të parin ose refuzohet menjëherë; ai nuk i bashkon kurrë dy grupet e rrugëve, dhe sigurisht nuk i vendos kriptimin e tyre njëri mbi tjetrin. Brenda një përdoruesi, dy tunele janë një sekuencë, jo një shumë.

Kjo është e zbatueshme kur aksesi është me të vërtetë sekuencial. Emërtoni profilet në mënyrë që ai aktiv të jetë i dukshëm, përfundoni çdo gjë të ndjeshme përpara se të ndërroni dhe prisni një dritare të shkurtër në të cilën asnjëra nga dy rrugët nuk është plotësisht e vendosur. Mbyllja e një skede shfletuesi nuk është e njëjtë me përfundimin e një sesioni: skeda mund të mbajë gjendjen e llogarisë së vet dhe thjesht të dërgojë kërkesën tjetër përmes rrjetit të sapozgjedhur, dhe pikërisht ky është rrjedhja që njerëzit vënë re më pas.

Ajo që ndërrimi nuk mund t'ju japë është një makinë që është në të dy rrjetet në të njëjtën kohë. Nëse një aplikacion ka nevojë për një adresë private nga secila anë, asnjë disiplinë klienti nuk do ta prodhojë atë.

Ndarje sipas profilit

Një profil pune i menaxhuar është një përdorues i veçantë me aplikacionet, depon e çelësave dhe politikën e vet të rrjetit. Një klient poste pune mund të përdorë tunelin e organizatës, ndërsa një shfletues personal përdor një personal, dhe të dy mund të jenë të lidhur në të njëjtën kohë sepse nuk janë në të njëjtin kontekst duke konkurruar për vendin.

Ndarja është gjithashtu kufiri. Shfletuesi personal nuk e huazon tunelin e punës, nuk i sheh prapashtesat DNS të punës dhe nuk arrin rrjetin e punës vetëm sepse të dy shërbimet shfaqen si të lidhura. Kur dikush raporton se një lidhje nuk hapet, kontrolloni se cila kopje e aplikacionit e trajtoi atë dhe cili profil zotëron atë llogari përpara se të prekni ndonjë nga dy VPN-të.

Trajtojeni kufirin si të fiksuar. Krijimi i një profili të dytë ose heqja e një profili pune për të anashkaluar një vendim rrugëtimi të punëdhënësit shkatërron pikërisht ndarjen që e bënte rregullimin të funksiononte, dhe në një pajisje të menaxhuar zakonisht është shkelje e politikës dhe jo një rregullim konfigurimi.

Një zinxhir, ku rendi është modeli

Një zinxhir është rregullimi që njerëzit zakonisht kanë parasysh kur thonë të dyja njëkohësisht: tuneli i telefonit udhëton brenda tunelit të ruterit. Mund të funksionojë, dhe kufizimet janë konkrete. Ofruesi i jashtëm duhet të lejojë një rrugë funksionale drejt pikës fundore VPN të telefonit, çka për protokollet e bazuara në UDP do të thotë që shërbimi i jashtëm nuk duhet ta bllokojë ose kufizojë atë trafik.

Kuptoni se kush sheh çfarë. Ofruesi i jashtëm sheh një lidhje drejt pikës fundore të brendshme. Ofruesi i brendshëm pranon trafikun e telefonit nga dalja e jashtme dhe e përcjell më tej. Destinacioni përfundimtar zakonisht sheh daljen e shërbimit të brendshëm, dhe asnjë ofrues përgjatë zinxhirit nuk është i verbër; llogaritë e aplikacioneve vazhdojnë ta identifikojnë përdoruesin pavarësisht rrugës.

Prisni kosto praktike. Çdo shtresë shton inkapsulim, kështu që MTU-ja efektive bie dhe një vlerë që ishte në rregull për një tunel tani fragmentohet ose ngec derisa MTU-ja e tunelit të brendshëm të vendoset në mënyrë konservative. Dy shtresa nënkuptojnë gjithashtu dy varësi dështimi dhe dy grupe mesazhesh mbajtëse, dhe një tunel i brendshëm i bazuar në TCP mbi një lidhje të jashtme me humbje mund të ngecë në mënyra që duken si një server i vdekur.

Më e rëndësishmja, një zinxhir nuk i shkrin dy rrjete private. Rrugët, prefikset që mbivendosen, zgjidhja DNS dhe rregullat e aksesit mbeten vendime të veçanta, dhe një ruter që mban një VPN ndërsa një telefon mban një tjetër nuk i jep telefonit të dy hapësirat e adresave.

Kontrolloni modelin përpara se ta korrigjoni

Shkruajeni rregullimin në një fjali dhe provojeni kundër aplikacionit që dështoi. Aksesi sekuencial duhet të tregojë një tunel në një kohë; ndarja e profileve duhet të tregojë çdo aplikacion në përdoruesin e vet; një zinxhir duhet të tregojë tunelin e brendshëm duke u vendosur mbi një ndërfaqe të jashtme dhe jo mbi atë fizike.

adb shell ip -br addr
adb shell ip route get 10.20.0.8
adb shell dumpsys connectivity | grep -i vpn

Nëse kërkimi i rrugës përmend ndërfaqen fizike ndërsa një aplikacion pret tunelin, modeli dhe konteksti i aplikacionit nuk pajtohen, dhe asnjë aplikacion shtesë VPN nuk do t'i pajtojë. Dokumentacioni për profilet e menaxhuara mbulon rregullat e ndarjes nëse ju nevojitet detaji i politikës dhe jo ai i rrugëtimit.