Две iPhone VPN истовремено: која го носи вашиот сообраќај?

Две 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 е изворот на правилото за соживот.