Due VPN iPhone insieme: quale trasporta il tuo traffico?

Due app VPN mostrano entrambe Connesso, e si presume che il traffico ora passi attraverso entrambe, una dentro l’altra. Di solito non è così. iOS ha un modello di coesistenza specifico, e non è una catena. Una classe di configurazione è limitata a una sola istanza abilitata, l’altra può funzionare accanto, e la precedenza delle rotte dirime i conflitti. Due interruttori accesi non sono due salti. Il modello è documentato, il che significa che il percorso può essere previsto invece di essere indovinato dalle icone.

Mito: due VPN connesse sono una catena

Una catena a due salti richiede un trasporto esterno definito, un tunnel interno definito, un routing degli endpoint compatibile e un piano per ciò che accade quando uno dei due fallisce. Due configurazioni indipendenti non creano questo semplicemente esistendo nello stesso momento. La priorità di rotta non è la stessa cosa dell’incapsulamento, e il fatto che una configurazione vinca una ricerca di rotta non dice nulla sul fatto che l’altra trasporti i pacchetti risultanti.

Se ti serve l’annidamento, progettalo come annidamento. Non dedurlo da due indicatori di connessione. Questa distinzione risparmia molto debug.

Il modello documentato dietro quel mito

NETunnelProviderManager di Apple descrive le normali configurazioni VPN aziendali e afferma che solo una di quel tipo può essere abilitata alla volta. Lo stesso riferimento consente a una Personal VPN di restare abilitata e connessa accanto, e dà la precedenza alle rotte aziendali dove le due si sovrappongono.

Qui Personal VPN è il termine dell’API per l’implementazione IPsec o IKEv2 integrata gestita tramite NEVPNManager. NETunnelProviderManager è il modello del fornitore di tunnel. Un’app consumer può usare il modello del fornitore, quindi un nome di prodotto che contiene personal non lo classifica.

Apple documenta una sola combinazione consentita, e il permesso non ti dice che i profili di due fornitori sono compatibili, quindi chiedi a ciascun fornitore quale coppia è supportata. I loro tipi di configurazione, le rotte e le politiche decidono comunque il risultato.

Mito: la VPN personale riceve il traffico di navigazione

Un profilo di lavoro che rivendica ogni destinazione vincerà la ricerca di rotta anche per la navigazione pubblica, quindi l’uscita personale non ne trasporta nulla. Secondo la precedenza documentata, le rotte aziendali vincono dove entrano in conflitto, quindi la navigazione pubblica non prende automaticamente l’uscita personale solo perché quell’app segnala anch’essa la connessione. Una configurazione di lavoro più ristretta può cambiare il quadro di routing, ma il client dell’organizzazione può comunque imporre requisiti DNS, di blocco o del dispositivo. Ottieni l’accordo supportato dal suo proprietario invece di modificare quei requisiti localmente.

Le configurazioni gestite per app hanno il proprio ambito. Non estrapolare una regola a livello di dispositivo a ogni distribuzione gestita.

Annota i due flussi prima di testare: il nome e l’intervallo privati del servizio di lavoro, e una nuova richiesta di navigazione pubblica. Entrambi sono legittimi, e richiedono controlli diversi.

Precedenza delle rotte con un profilo di lavoro a tunnel diviso

Un profilo di lavoro con tunnel diviso rivendica i prefissi privati e il suffisso DNS interno che elenca, e quelle rotte vincono ogni ricerca che vi corrisponde. Le destinazioni pubbliche che non corrispondono a nessuna rotta aziendale ricadono sul collegamento fisico, a meno che la VPN personale non le rivendichi prima. La regola di precedenza dirime solo le corrispondenze sovrapposte, per questo i due profili vanno letti come tabelle di rotte e non come icone.

Scrivi la coppia su due righe e indica il vincitore atteso per ciascuna: un nome host di lavoro che si risolve in 10.x o 172.16.x dovrebbe uscire dal tunnel aziendale, e un indirizzo pubblico senza prefisso corrispondente dovrebbe prendere la rotta predefinita rimasta. Se entrambe le righe indicano la stessa uscita, la suddivisione non fa ciò che descrive la documentazione.

Annota due flussi e prova ciascuno

Per ogni flusso, annota quale configurazione approvata dovrebbe trasportarlo e quale resolver dovrebbe ricevere ogni tipo di nome. Poi verifica con richieste nuove, non con una pagina di lavoro in cache o un vecchio risultato IP.

Ferma una configurazione e ripeti entrambi i flussi. Il comportamento in caso di guasto fa parte del progetto, ed è la parte che gli utenti notano. Quando i due fornitori non possono supportare la combinazione, scegli una configurazione approvata e documenta quale flusso trasporta, oppure passa a un progetto gestito a tunnel singolo. La documentazione di NETunnelProviderManager è la fonte della regola di coesistenza.