Dy VPN iPhone njëkohësisht: cili e mbart trafikun tuaj?

Dy aplikacione VPN tregojnë të dyja Connected, dhe supozimi është se trafiku tani kalon përmes të dyjave, njëri brenda tjetrit. Zakonisht nuk ndodh kështu. iOS ka një model specifik bashkëjetese, dhe ai nuk është zinxhir. Një klasë konfigurimi kufizohet në një instancë të aktivizuar, tjetra mund të punojë pranë saj, dhe përparësia e rrugëve vendos konfliktet. Dy çelësa të ndezur nuk janë dy kërcime. Modeli është i dokumentuar, që do të thotë se rruga mund të parashikohet në vend që të merret me mend nga ikonat.

Miti: dy VPN të lidhura janë zinxhir

Një zinxhir me dy kërcime kërkon një transport të jashtëm të përcaktuar, një tunel të brendshëm të përcaktuar, rrugëtim të pajtueshëm të pikave fundore dhe një plan për atë që ndodh kur dështon njëri prej tyre. Dy konfigurime të pavarura nuk e krijojnë këtë thjesht duke ekzistuar në të njëjtën kohë. Përparësia e rrugës nuk është e njëjtë me inkapsulimin, dhe fakti që një konfigurim fiton një kërkim rruge nuk thotë asgjë për atë nëse tjetri i mbart paketat që rezultojnë.

Nëse keni nevojë për folezim, projektojeni si folezim. Mos e nxirrni nga dy tregues lidhjeje. Ky dallim kursen shumë korrigjim.

Modeli i dokumentuar pas këtij miti

NETunnelProviderManager i Apple përshkruan konfigurimet e zakonshme të VPN-së për ndërmarrje dhe thotë se vetëm një e atij lloji mund të aktivizohet njëherësh. I njëjti referencë lejon që një Personal VPN të mbetet e aktivizuar dhe e lidhur pranë saj, dhe u jep përparësi rrugëve të ndërmarrjes aty ku të dyja mbivendosen.

Këtu Personal VPN është termi i API-së për implementimin e integruar të IPsec ose IKEv2 të menaxhuar përmes NEVPNManager. NETunnelProviderManager është modeli i ofruesit të tunelit. Një aplikacion konsumatori mund të përdorë modelin e ofruesit, prandaj një emër produkti që përmban personal nuk e klasifikon atë.

Apple dokumenton një kombinim të lejuar, dhe leja nuk ju thotë se profilet e dy furnitorëve janë të pajtueshme, prandaj pyesni çdo furnitor se cila palë mbështetet. Llojet e konfigurimit, rrugët dhe politikat e tyre ende vendosin rezultatin.

Miti: VPN-ja personale merr trafikun e shfletimit

Një profil pune që kërkon çdo destinacion do të fitojë kërkimin e rrugës edhe për shfletimin publik, kështu që dalja personale nuk mbart asgjë prej tij. Sipas përparësisë së dokumentuar, rrugët e ndërmarrjes fitojnë aty ku përplasen, kështu që shfletimi publik nuk merr automatikisht daljen personale vetëm sepse ai aplikacion raporton gjithashtu lidhje. Një konfigurim pune më i ngushtë mund të ndryshojë pamjen e rrugëtimit, por klienti i organizatës ende mund të imponojë kërkesa DNS, bllokimi ose pajisjeje. Merrni rregullimin e mbështetur nga pronari i tij në vend që t'i modifikoni ato kërkesa lokalisht.

Konfigurimet e menaxhuara për aplikacion kanë shtrirjen e tyre. Mos e përgjithësoni një rregull në nivel pajisjeje për çdo vendosje të menaxhuar.

Shkruani dy rrjedhat para provës: emrin dhe intervalin privat të shërbimit të punës, dhe një kërkesë të re shfletimi publik. Të dyja janë legjitime, dhe kërkojnë kontrolle të ndryshme.

Përparësia e rrugëve me një profil pune me tunel të ndarë

Një profil pune me tunel të ndarë kërkon prefikset private dhe prapashtesën e brendshme DNS që liston, dhe ato rrugë fitojnë çdo kërkim që përputhet me to. Destinacionet publike që nuk përputhen me asnjë rrugë të ndërmarrjes bien në lidhjen fizike, përveç nëse VPN-ja personale i kërkon ato së pari. Rregulli i përparësisë vendos vetëm përputhjet e mbivendosura, prandaj dy profilet duhet të lexohen si tabela rrugësh dhe jo si ikona.

Shkruani çiftin në dy rreshta dhe emërtoni fituesin e pritur për secilin: një emër host pune që zgjidhet në 10.x ose 172.16.x duhet të dalë përmes tunelit të ndërmarrjes, dhe një adresë publike pa prefiks përputhës duhet të marrë rrugën e parazgjedhur që mbetet. Nëse të dy rreshtat emërtojnë të njëjtën dalje, ndarja nuk bën atë që përshkruan dokumentacioni.

Shkruani dy rrjedha dhe provoni secilën

Për çdo rrjedhë, shkruani cili konfigurim i miratuar duhet ta mbartë dhe cili zgjidhës duhet të marrë çdo lloj emri. Më pas verifikoni me kërkesa të reja, jo me një faqe pune të ruajtur në cache ose me një rezultat të vjetër IP.

Ndaloni një konfigurim dhe përsëritni të dyja rrjedhat. Sjellja në dështim është pjesë e projektimit, dhe është pjesa që përdoruesit vërejnë. Kur dy ofruesit nuk mund ta mbështesin kombinimin, ndaloni në një konfigurim të miratuar dhe dokumentoni cilën rrjedhë mbart, ose kaloni në një projektim të menaxhuar me një tunel. Dokumentacioni i NETunnelProviderManager është burimi i rregullit të bashkëjetesës.