Dvě VPN na iPhonu najednou: která z nich nese provoz?
Dvě připojené VPN na iPhonu nejsou řetěz. Přečtěte si dokumentovaný model soužití a poté ověřte, která konfigurace nese každý tok.
Dvě aplikace VPN obě hlásí Connected a předpoklad je, že provoz nyní prochází oběma, jedna uvnitř druhé. Obvykle to tak není. iOS má konkrétní model soužití a ten není řetězem. Jedna třída konfigurace je omezena na jednu povolenou instanci, druhá může běžet vedle ní a priorita tras rozhoduje konflikty. Dva rozsvícené přepínače nejsou dva skoky. Model je dokumentovaný, což znamená, že cestu lze předpovědět místo hádání z ikon.
Mýtus: dvě připojené VPN jsou řetěz
Řetězec o dvou skocích potřebuje definovaný vnější přenos, definovaný vnitřní tunel, kompatibilní směrování koncových bodů a plán, co se stane, když kterýkoli z nich selže. Dvě nezávislé konfigurace to nevytvářejí jen tím, že existují současně. Priorita trasy není totéž co zapouzdření a vítězství jedné konfigurace ve vyhledání trasy nic neříká o tom, zda druhá nese výsledné pakety.
Pokud potřebujete vnoření, navrhněte ho jako vnoření. Neodvozujte ho ze dvou indikátorů připojení. Tento rozdíl ušetří hodně ladění.
Dokumentovaný model za tímto mýtem
NETunnelProviderManager od Applu popisuje běžné podnikové konfigurace VPN a uvádí, že současně lze povolit pouze jednu tohoto druhu. Stejná reference umožňuje, aby Personal VPN zůstala povolená a připojená vedle ní, a dává podnikovým trasám přednost tam, kde se obě překrývají.
Personal VPN je zde termín API pro vestavěnou implementaci IPsec nebo IKEv2 spravovanou přes NEVPNManager. NETunnelProviderManager je model poskytovatele tunelu. Spotřebitelská aplikace může použít model poskytovatele, takže název produktu obsahující personal ji neklasifikuje.
Apple dokumentuje jednu povolenou kombinaci a povolení vám neříká, že profily dvou dodavatelů jsou kompatibilní, proto se každého dodavatele zeptejte, která dvojice je podporovaná. Jejich typy konfigurací, trasy a zásady stále rozhodují o výsledku.
Mýtus: osobní VPN dostává provoz prohlížení
Pracovní profil, který si nárokuje všechny destinace, vyhraje vyhledání trasy i pro veřejné prohlížení, takže osobní výstup z něj nic nenese. Podle dokumentované priority vyhrávají podnikové trasy tam, kde se střetávají, takže veřejné prohlížení automaticky nepřejde na osobní výstup jen proto, že ta aplikace také hlásí připojení. Užší pracovní konfigurace může změnit obraz směrování, ale klient organizace může stále vynutit požadavky na DNS, blokování nebo zařízení. Podporované uspořádání si vyžádejte od jeho vlastníka, místo abyste tyto požadavky upravovali lokálně.
Spravované konfigurace pro jednotlivé aplikace mají vlastní rozsah. Nepřenášejte pravidlo na úrovni zařízení na každé spravované nasazení.
Před testem si zapište dva toky: soukromé jméno a rozsah pracovní služby a nový požadavek na veřejné prohlížení. Oba jsou legitimní a potřebují různé kontroly.
Priorita tras u pracovního profilu s rozděleným tunelem
Pracovní profil se rozděleným tunelem si nárokuje soukromé prefixy a interní příponu DNS, kterou uvádí, a tyto trasy vyhrají každé vyhledání, které jim odpovídá. Veřejné destinace, které neodpovídají žádné podnikové trase, propadnou na fyzické spojení, pokud si je osobní VPN nevyžádá první. Pravidlo priority rozhoduje jen o překrývajících se shodách, a proto se oba profily musí číst jako tabulky tras, nikoli jako ikony.
Zapište dvojici jako dva řádky a pojmenujte očekávaného vítěze pro každý: jméno pracovního hostitele, které se přeloží na 10.x nebo 172.16.x, by mělo vycházet podnikovým tunelem, a veřejná adresa bez odpovídajícího prefixu by měla převzít zbývající výchozí trasu. Pokud oba řádky pojmenují stejný výstup, rozdělení nedělá to, co dokumentace popisuje.
Zapište dva toky a ověřte každý
U každého toku zaznamenejte, která schválená konfigurace ho má nést a který překladač má dostat každý druh jména. Poté ověřte čerstvými požadavky, ne kešovanou pracovní stránkou nebo starým výsledkem IP.
Zastavte jednu konfiguraci a zopakujte oba toky. Chování při selhání je součástí návrhu a je to část, kterou si uživatelé všimnou. Když dva poskytovatelé nemohou kombinaci podporovat, rozhodněte se pro jednu schválenou konfiguraci a zdokumentujte, který tok nese, nebo přejděte na spravovaný návrh s jedním tunelem. Dokumentace NETunnelProviderManager je zdrojem pravidla soužití.