Dalawang iPhone VPN nang sabay: alin ang nagdadala ng iyong trapiko?

Dalawang app ng VPN ang parehong nagpapakita ng Connected, at ang palagay ay dumadaan na ang trapiko sa pareho, ang isa sa loob ng isa. Karaniwang hindi ito nangyayari. May partikular na modelo ng magkasamang pag-iral ang iOS, at hindi ito kadena. Isang klase ng configuration ang limitado sa isang pinagana na instance, ang isa ay maaaring tumakbo sa tabi nito, at ang priyoridad ng ruta ang nagpapasya ng mga salungatan. Dalawang nakasinding switch ay hindi dalawang hop. Ang modelo ay dokumentado, ibig sabihin ay mahuhulaan ang landas sa halip na hulaan mula sa mga icon.

Mito: ang dalawang konektadong VPN ay kadena

Ang kadenang may dalawang hop ay nangangailangan ng tinukoy na panlabas na transportasyon, tinukoy na panloob na tunel, tugmang pagruruta ng mga dulo at plano para sa mangyayari kapag ang isa sa dalawa ay nabigo. Ang dalawang malayang configuration ay hindi iyon nalilikha sa pamamagitan lamang ng pag-iral nang sabay. Ang priyoridad ng ruta ay hindi katulad ng encapsulation, at ang pagkapanalo ng isang configuration sa paghahanap ng ruta ay walang sinasabi kung ang isa ay nagdadala ng mga resultang packet.

Kung kailangan mo ng nesting, idisenyo ito bilang nesting. Huwag itong hinuha mula sa dalawang tagapagpahiwatig ng koneksyon. Ang pagkakaibang iyon ay nakakatipid ng maraming pag-debug.

Ang dokumentadong modelo sa likod ng mitong iyon

Ang NETunnelProviderManager ng Apple ay naglalarawan ng karaniwang mga configuration ng VPN ng enterprise at nagsasabi na isa lamang sa ganitong uri ang maaaring paganahin nang sabay. Pinapayagan ng parehong reperensya na manatiling pinagana at konektado ang isang Personal VPN sa tabi nito, at binibigyan ng priyoridad ang mga ruta ng enterprise kung saan nagsasapawan ang dalawa.

Dito ang Personal VPN ay ang termino ng API para sa built-in na implementasyon ng IPsec o IKEv2 na pinamamahalaan sa pamamagitan ng NEVPNManager. Ang NETunnelProviderManager ay ang modelo ng provider ng tunel. Maaaring gamitin ng app ng consumer ang modelo ng provider, kaya ang pangalan ng produkto na may personal ay hindi ito inuuri.

Dokumentado ng Apple ang isang pinapayagang kombinasyon, at hindi sinasabi ng pahintulot na tugma ang mga profile ng dalawang vendor, kaya itanong sa bawat vendor kung aling pares ang sinusuportahan. Ang kanilang mga uri ng configuration, ruta at patakaran ay nagpapasya pa rin ng resulta.

Mito: ang personal na VPN ang tumatanggap ng trapiko ng pagba-browse

Ang profile ng trabaho na nag-aangkin ng bawat destinasyon ay mananalo rin sa paghahanap ng ruta para sa pampublikong pagba-browse, kaya walang dinadala ang personal na labasan nito. Ayon sa dokumentadong priyoridad, nananalo ang mga ruta ng enterprise kung saan nagbabanggaan ang mga ito, kaya hindi awtomatikong kinukuha ng pampublikong pagba-browse ang personal na labasan dahil lang nag-uulat din ng koneksyon ang app na iyon. Maaaring baguhin ng mas makitid na configuration ng trabaho ang larawan ng pagruruta, ngunit maaari pa ring magpataw ang kliyente ng organisasyon ng mga kinakailangan sa DNS, pagharang o device. Kunin ang sinusuportahang kaayusan mula sa may-ari nito sa halip na i-edit ang mga kinakailangang iyon nang lokal.

Ang mga pinamamahalaang configuration bawat app ay may sariling saklaw. Huwag i-generalize ang patakaran sa antas ng device sa bawat pinamamahalaang deployment.

Isulat ang dalawang daloy bago mag-test: ang pribadong pangalan at saklaw ng serbisyo ng trabaho, at isang bagong kahilingan sa pampublikong pagba-browse. Parehong lehitimo, at kailangan nila ng magkaibang pagsusuri.

Priyoridad ng ruta sa isang profile ng trabaho na may split tunnel

Ang profile ng trabaho na may split tunnel ay nag-aangkin ng mga pribadong prefix at panloob na DNS suffix na inililista nito, at ang mga rutang iyon ay nananalo sa anumang paghahanap na tumutugma sa kanila. Ang mga pampublikong destinasyon na hindi tumutugma sa alinmang ruta ng enterprise ay bumabagsak sa pisikal na link maliban kung ang personal na VPN ang unang mag-aangkin sa kanila. Ang patakaran ng priyoridad ay nagpapasya lamang sa mga nagsasapawang tugma, kaya dapat basahin ang dalawang profile bilang mga talahanayan ng ruta at hindi bilang mga icon.

Isulat ang pares sa dalawang linya at pangalanan ang inaasahang panalo para sa bawat isa: ang pangalan ng host ng trabaho na nagre-resolve sa 10.x o 172.16.x ay dapat lumabas sa tunel ng enterprise, at ang pampublikong address na walang tugmang prefix ay dapat kumuha ng natitirang default na ruta. Kung parehong labasan ang pinangalanan ng dalawang linya, hindi ginagawa ng paghahati ang inilalarawan ng dokumentasyon.

Isulat ang dalawang daloy at subukan ang bawat isa

Para sa bawat daloy, itala kung aling aprubadong configuration ang dapat magdala nito at aling resolver ang dapat tumanggap ng bawat uri ng pangalan. Pagkatapos ay i-verify gamit ang mga bagong kahilingan, hindi gamit ang naka-cache na pahina ng trabaho o lumang resulta ng IP.

Ihinto ang isang configuration at ulitin ang dalawang daloy. Ang gawi sa pagkabigo ay bahagi ng disenyo, at ito ang bahaging napapansin ng mga user. Kapag hindi kayang suportahan ng dalawang provider ang kombinasyon, manatili sa isang aprubadong configuration at idokumento kung aling daloy ang dinadala nito, o lumipat sa pinamamahalaang disenyo na may isang tunel. Ang dokumentasyon ng NETunnelProviderManager ang pinagmulan ng patakaran ng magkasamang pag-iral.