Două VPN de iPhone simultan: care transportă traficul tău?

Două aplicații VPN afișează ambele Connected, iar presupunerea este că traficul trece acum prin ambele, una în interiorul celeilalte. De obicei nu se întâmplă așa. iOS are un model de coexistență specific, iar acesta nu este un lanț. O clasă de configurare este limitată la o singură instanță activată, cealaltă poate rula alături, iar prioritatea rutelor decide conflictele. Două întrerupătoare aprinse nu sunt două salturi. Modelul este documentat, ceea ce înseamnă că traseul poate fi prezis în loc să fie ghicit din pictograme.

Mit: două VPN conectate sunt un lanț

Un lanț cu două salturi are nevoie de un transport exterior definit, un tunel interior definit, rutare compatibilă a punctelor terminale și un plan pentru ce se întâmplă când unul dintre ele eșuează. Două configurații independente nu creează asta doar existând în același timp. Prioritatea rutei nu este același lucru cu încapsularea, iar faptul că o configurație câștigă o căutare de rută nu spune nimic despre dacă cealaltă transportă pachetele rezultate.

Dacă ai nevoie de imbricare, proiecteaz-o ca imbricare. Nu o deduce din doi indicatori de conexiune. Această distincție economisește multă depanare.

Modelul documentat din spatele acestui mit

NETunnelProviderManager de la Apple descrie configurații VPN obișnuite de întreprindere și afirmă că doar una de acel tip poate fi activată simultan. Aceeași referință permite unei Personal VPN să rămână activată și conectată alături, și dă prioritate rutelor întreprinderii acolo unde cele două se suprapun.

Aici Personal VPN este termenul API pentru implementarea IPsec sau IKEv2 încorporată, gestionată prin NEVPNManager. NETunnelProviderManager este modelul de furnizor de tunel. O aplicație de consum poate folosi modelul de furnizor, așa că un nume de produs care conține personal nu îl clasifică.

Apple documentează o singură combinație permisă, iar permisiunea nu îți spune că profilurile a doi furnizori sunt compatibile, așa că întreabă fiecare furnizor ce pereche este acceptată. Tipurile lor de configurare, rutele și politicile decid în continuare rezultatul.

Mit: VPN-ul personal primește traficul de navigare

Un profil de lucru care revendică fiecare destinație va câștiga căutarea de rută și pentru navigarea publică, așa că ieșirea personală nu transportă nimic din ea. Conform priorității documentate, rutele întreprinderii câștigă acolo unde intră în conflict, așa că navigarea publică nu ia automat ieșirea personală doar pentru că acea aplicație raportează și ea conectare. O configurație de lucru mai îngustă poate schimba imaginea rutării, dar clientul organizației poate impune în continuare cerințe de DNS, blocare sau dispozitiv. Obține aranjamentul acceptat de la proprietarul său în loc să editezi acele cerințe local.

Configurațiile gestionate pe aplicație au propriul domeniu. Nu extrapola o regulă la nivel de dispozitiv la fiecare implementare gestionată.

Notează cele două fluxuri înainte de testare: numele și intervalul private ale serviciului de lucru, și o cerere nouă de navigare publică. Ambele sunt legitime și au nevoie de verificări diferite.

Prioritatea rutelor cu un profil de lucru cu tunel divizat

Un profil de lucru cu tunel divizat revendică prefixele private și sufixul DNS intern pe care le enumeră, iar acele rute câștigă orice căutare care se potrivește cu ele. Destinațiile publice care nu se potrivesc cu nicio rută a întreprinderii cad pe legătura fizică, dacă VPN-ul personal nu le revendică primul. Regula de prioritate decide doar potrivirile suprapuse, de aceea cele două profiluri trebuie citite ca tabele de rute, nu ca pictograme.

Scrie perechea pe două linii și numește câștigătorul așteptat pentru fiecare: un nume de gazdă de lucru care se rezolvă la 10.x sau 172.16.x ar trebui să iasă prin tunelul întreprinderii, iar o adresă publică fără prefix potrivit ar trebui să ia ruta implicită rămasă. Dacă ambele linii numesc aceeași ieșire, divizarea nu face ce descrie documentația.

Notează două fluxuri și testează fiecare

Pentru fiecare flux, notează ce configurație aprobată ar trebui să îl transporte și ce resolver ar trebui să primească fiecare tip de nume. Apoi verifică cu cereri noi, nu cu o pagină de lucru din cache sau cu un rezultat IP vechi.

Oprește o configurație și repetă ambele fluxuri. Comportamentul la eșec face parte din design, și este partea pe care utilizatorii o observă. Când cei doi furnizori nu pot susține combinația, rămâi la o configurație aprobată și documentează ce flux transportă, sau treci la un design gestionat cu un singur tunel. Documentația NETunnelProviderManager este sursa regulii de coexistență.