Дзве VPN на iPhone адначасова: якая з іх нясе трафік?

Дзве праграмы VPN абедзве паказваюць Connected, і меркаванне такое, што трафік цяпер ідзе праз абедзве, адна ўнутры другой. Звычайна гэта не так. У iOS ёсць пэўная мадэль суіснавання, і гэта не ланцужок. Адзін клас канфігурацыі абмежаваны адным уключаным асобнікам, другі можа працаваць побач, а прыярытэт маршрутаў вырашае канфлікты. Два запаленыя перамыкачы — не два праскокі. Мадэль дакументаваная, а значыць шлях можна прадказаць, а не ўгадваць па значках.

Міф: дзве падключаныя VPN — гэта ланцужок

Ланцужку з двух праскокаў патрэбны вызначаны знешні транспарт, вызначаны ўнутраны тунель, сумяшчальная маршрутызацыя канчатковых кропак і план на выпадак адмовы любога з іх. Дзве незалежныя канфігурацыі не ствараюць гэтага проста тым, што існуюць адначасова. Прыярытэт маршруту — не тое самае, што інкапсуляцыя, і перамога адной канфігурацыі ў пошуку маршруту нічога не кажа пра тое, ці нясе другая атрыманыя пакеты.

Калі вам патрэбна ўкладанне, праектуйце яго як укладанне. Не выводзьце яго з двух індыкатараў злучэння. Гэта адрозненне зэканоміць шмат адладкі.

Дакументаваная мадэль за гэтым міфам

NETunnelProviderManager ад Apple апісвае звычайныя карпаратыўныя канфігурацыі VPN і сцвярджае, што адначасова можна ўключыць толькі адну з гэтага тыпу. Тое ж даведачнае апісанне дазваляе Personal VPN заставацца ўключанай і падключанай побач, і дае карпаратыўным маршрутам прыярытэт там, дзе яны супадаюць.

Personal VPN тут — гэта тэрмін API для ўбудаванай рэалізацыі IPsec або IKEv2, якой кіруе NEVPNManager. NETunnelProviderManager — гэта мадэль пастаўшчыка тунеля. Спажывецкая праграма можа выкарыстоўваць мадэль пастаўшчыка, таму назва прадукту са словам personal яго не класіфікуе.

Apple дакументуе адну дазволеную камбінацыю, а дазвол не кажа, што профілі двух пастаўшчыкоў сумяшчальныя, таму спытайце ў кожнага пастаўшчыка, якая пара падтрымліваецца. Іх тыпы канфігурацый, маршруты і палітыкі ўсё яшчэ вырашаюць вынік.

Міф: асабістая VPN атрымлівае трафік аглядання

Працоўны профіль, які заяўляе ўсе прызначэнні, выйграе пошук маршруту і для публічнага аглядання, таму асабісты выхад не нясе нічога з гэтага. Паводле дакументаванага прыярытэту карпаратыўныя маршруты перамагаюць там, дзе супадаюць, таму публічнае агляданне не пераходзіць аўтаматычна на асабісты выхад толькі таму, што гэтая праграма таксама паведамляе пра злучэнне. Больш вузкая працоўная канфігурацыя можа змяніць карціну маршрутызацыі, але кліент арганізацыі ўсё яшчэ можа навязаць патрабаванні да DNS, блакавання або прылады. Атрымайце падтрымоўваны парадак у яго ўласніка, замест таго каб правіць гэтыя патрабаванні лакальна.

Кіраваныя канфігурацыі для асобных праграм маюць сваю сферу. Не пераносьце правіла ўзроўню прылады на кожнае кіраванае разгортванне.

Запішыце два патокі да тэсту: прыватнае імя і дыяпазон працоўнай службы, і свежы запыт публічнага аглядання. Абодва законныя, і ім патрэбны розныя праверкі.

Прыярытэт маршрутаў з працоўным профілем раздзеленага тунеля

Працоўны профіль з раздзеленым тунелем заяўляе прыватныя прэфіксы і ўнутраны суфікс DNS, які ён пералічвае, і гэтыя маршруты перамагаюць любы пошук, які з імі супадае. Публічныя прызначэнні, якія не супадаюць ні з адным карпаратыўным маршрутам, сыходзяць на фізічнае звяно, калі асабістая VPN не заявіць іх раней. Правіла прыярытэту вырашае толькі супадаючыя збежкі, таму два профілі трэба чытаць як табліцы маршрутаў, а не як значкі.

Запішыце пару двума радкамі і назавіце чаканага пераможцу для кожнага: імя працоўнага хоста, што вырашаецца ў 10.x або 172.16.x, павінна выходзіць праз карпаратыўны тунель, а публічны адрас без адпаведнага прэфікса павінен узяць той маршрут па змаўчанні, што застанецца. Калі абодва радкі называюць адзін і той жа выхад, раздзяленне не робіць таго, што апісвае дакументацыя.

Запішыце два патокі і праверце кожны

Для кожнага патоку запішыце, якая адабраная канфігурацыя павінна яго несці і які рэзалвер павінен атрымліваць кожны тып імені. Потым правярайце свежымі запытамі, а не кэшаванай працоўнай старонкай або старым вынікам IP.

Спыніце адну канфігурацыю і паўтарыце абодва патокі. Паводзіны пры адмове — частка праекта, і гэта тая частка, якую заўважаюць карыстальнікі. Калі два пастаўшчыкі не могуць падтрымаць камбінацыю, спыніцеся на адной адабранай канфігурацыі і задокументуйце, які паток яна нясе, або перайдзіце на кіраваны праект з адным тунелем. Дакументацыя NETunnelProviderManager — крыніца правіла суіснавання.