Две 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 е източникът за правилото за съвместно съществуване.