Du iPhone-VPN-oj samtempe: kiu portas vian trafikon?

Du VPN-aplikoj ambaŭ montras Connected, kaj la supozo estas, ke la trafiko nun iras tra ambaŭ, unu ene de la alia. Kutime ĝi ne faras tion. iOS havas specifan kunekzistan modelon, kaj ĝi ne estas ĉeno. Unu agorda klaso limiĝas al unu ŝaltita ekzemplero, la alia povas funkcii apude, kaj itinera prioritato decidas konfliktojn. Du ŝaltitaj ŝaltiloj ne estas du saltoj. La modelo estas dokumentita, do la vojo povas esti antaŭdirita anstataŭ divenita el la ikonoj.

Mito: du konektitaj VPN-oj estas ĉeno

Ĉeno de du saltoj bezonas difinitan eksteran transporton, difinitan internan tunelon, kongruan finpunkto-tiradon kaj planon por kio okazas kiam iu el ili malsukcesas. Du sendependaj agordoj ne kreas tion per la nura samtempa ekzistado. Itinera prioritato ne samas kiel enkapsulado, kaj tio, ke unu agordo gajnas itineran serĉon, diras nenion pri tio, ĉu la alia portas la rezultajn pakaĵojn.

Se vi bezonas nestadon, planu ĝin kiel nestadon. Ne deduktu ĝin el du konektaj indikiloj. Tiu distingo ŝparas multan sencimigadon.

La dokumentita modelo malantaŭ tiu mito

NETunnelProviderManager de Apple priskribas ordinarajn entreprenajn VPN-agordojn kaj konstatas, ke nur unu tia povas esti ŝaltita samtempe. La sama referenco permesas al Personal VPN resti ŝaltita kaj konektita apude, kaj donas prioritaton al la entreprenaj itineroj kie la du koincidas.

Personal VPN ĉi tie estas la API-termo por la enkonstruita IPsec aŭ IKEv2 efektivigo administrata per NEVPNManager. NETunnelProviderManager estas la modelo de tunela provizanto. Konsuma aplikaĵo povas uzi la provizantan modelon, do produkta nomo enhavanta personal ne klasifikas ĝin.

Apple dokumentas unu permesitan kombinaĵon, kaj permeso ne diras al vi, ke la profiloj de du provizantoj kongruas, do demandu ĉiun provizanton, kiu paro estas subtenata. Iliaj agordaj tipoj, itineroj kaj politikoj ankoraŭ decidas la rezulton.

Mito: la persona VPN ricevas la retuman trafikon

Labora profilo, kiu postulas ĉiun celon, gajnos la itineran serĉon ankaŭ por publika retumado, do la persona eliro portas neniom da ĝi. Laŭ la dokumentita prioritato, la entreprenaj itineroj gajnas kie ili konfliktas, do publika retumado ne aŭtomate prenas la personan eliron nur ĉar tiu aplikaĵo ankaŭ raportas konekton. Pli mallarĝa labora agordo povas ŝanĝi la tiradan bildon, sed la kliento de la organizo ankoraŭ povas trudi postulojn pri DNS, blokado aŭ aparato. Petu la subtenatan aranĝon de ĝia posedanto anstataŭ redakti tiujn postulojn loke.

Administrataj agordoj por unuopa aplikaĵo havas sian propran amplekson. Ne etendi regulon ĉe aparata nivelo al ĉiu administrata deplojo.

Skribu la du fluojn antaŭ la testado: la privata nomo kaj gamo de la labora servo, kaj freŝa peto pri publika retumado. Ambaŭ estas legitimaj, kaj ili bezonas malsamajn kontrolojn.

Itinera prioritato kun labora profilo de dividita tunelo

Labora profilo kun dividita tunelo postulas la privatajn prefiksojn kaj la internan DNS-sufikson, kiujn ĝi listigas, kaj tiuj itineroj gajnos ĉiun serĉon, kiu kongruas kun ili. Publikaj celoj, kiuj kongruas kun neniu entreprena itinero, falas al la fizika ligilo, se la persona VPN ne postulas ilin unue. La prioritata regulo decidas nur la koincidantajn kongruojn, tial la du profiloj devas esti legataj kiel itineraj tabeloj, ne kiel ikonoj.

Skribu la paron kiel du liniojn kaj nomu la atendatan gajninton por ĉiu: labora gastiga nomo solviĝanta al 10.x aŭ 172.16.x devus eliri tra la entreprena tunelo, kaj publika adreso sen kongrua prefikso devus preni la restantan implicitan itineron. Se ambaŭ linioj nomas la saman eliron, la divido ne faras tion, kion priskribas la dokumentaro.

Skribu du fluojn kaj testu ĉiun

Por ĉiu fluo, notu kiun aprobitan agordon ĝi devus porti kaj kiun solvilon devus ricevi ĉiu speco de nomo. Poste kontrolu per freŝaj petoj, ne per kaŝmemorigita labora paĝo aŭ malnova IP-rezulto.

Haltigu unu agordon kaj ripetu ambaŭ fluojn. La malsukcesa konduto estas parto de la dezajno, kaj ĝi estas la parto, kiun uzantoj rimarkas. Kiam la du provizantoj ne povas subteni la kombinaĵon, elektu unu aprobitan agordon kaj dokumentu, kiun fluon ĝi portas, aŭ transiru al administrata unutunela dezajno. La dokumentaro de NETunnelProviderManager estas la fonto de la kunekzista regulo.