Dwa VPN-y iPhone naraz: który niesie twój ruch?

Dwie aplikacje VPN pokazują obie Connected, a założenie jest takie, że ruch przechodzi teraz przez obie, jedna wewnątrz drugiej. Zwykle tak nie jest. iOS ma określony model współistnienia i nie jest to łańcuch. Jedna klasa konfiguracji jest ograniczona do jednej włączonej instancji, druga może działać obok, a priorytet tras rozstrzyga konflikty. Dwa włączone przełączniki to nie dwa skoki. Model jest udokumentowany, co oznacza, że ścieżkę można przewidzieć, zamiast zgadywać ją z ikon.

Mit: dwa połączone VPN-y to łańcuch

Łańcuch dwóch skoków wymaga zdefiniowanego transportu zewnętrznego, zdefiniowanego tunelu wewnętrznego, zgodnego routingu punktów końcowych i planu na to, co się stanie, gdy jeden z nich zawiedzie. Dwie niezależne konfiguracje nie tworzą tego tylko przez współistnienie. Priorytet trasy to nie to samo co enkapsulacja, a wygranie przez jedną konfigurację wyszukiwania trasy nic nie mówi o tym, czy druga niesie powstałe pakiety.

Jeśli potrzebujesz zagnieżdżenia, zaprojektuj je jako zagnieżdżenie. Nie wnioskuj tego z dwóch wskaźników połączenia. Ta różnica oszczędza wiele debugowania.

Udokumentowany model stojący za tym mitem

NETunnelProviderManager firmy Apple opisuje zwykłe konfiguracje VPN dla przedsiębiorstw i stwierdza, że jednocześnie można włączyć tylko jedną tego typu. Ta sama dokumentacja pozwala Personal VPN pozostać włączonemu i połączonemu obok, i daje pierwszeństwo trasom przedsiębiorstwa tam, gdzie się pokrywają.

Personal VPN to tutaj termin API oznaczający wbudowaną implementację IPsec lub IKEv2 zarządzaną przez NEVPNManager. NETunnelProviderManager to model dostawcy tunelu. Aplikacja konsumencka może użyć modelu dostawcy, więc nazwa produktu zawierająca personal tego nie klasyfikuje.

Apple dokumentuje jedną dozwoloną kombinację, a pozwolenie nie mówi, że profile dwóch dostawców są zgodne, więc zapytaj każdego dostawcę, która para jest obsługiwana. Ich typy konfiguracji, trasy i zasady nadal decydują o wyniku.

Mit: osobisty VPN dostaje ruch przeglądania

Profil służbowy, który rości sobie wszystkie cele, wygra też wyszukiwanie trasy dla przeglądania publicznego, więc wyjście osobiste nic z tego nie niesie. Zgodnie z udokumentowanym pierwszeństwem trasy przedsiębiorstwa wygrywają tam, gdzie się zderzają, więc przeglądanie publiczne nie przechodzi automatycznie na wyjście osobiste tylko dlatego, że ta aplikacja również zgłasza połączenie. Węższa konfiguracja służbowa może zmienić obraz routingu, ale klient organizacji nadal może narzucić wymagania dotyczące DNS, blokowania lub urządzenia. Uzyskaj obsługiwane rozwiązanie od jego właściciela, zamiast edytować te wymagania lokalnie.

Zarządzane konfiguracje dla poszczególnych aplikacji mają własny zakres. Nie przenoś reguły na poziomie urządzenia na każde zarządzane wdrożenie.

Zapisz dwa strumienie przed testem: prywatną nazwę i zakres usługi służbowej oraz nowe żądanie przeglądania publicznego. Oba są uzasadnione i wymagają różnych kontroli.

Priorytet tras z profilem służbowym podzielonego tunelu

Profil służbowy z podzielonym tunelem rości sobie wymienione prefiksy prywatne i wewnętrzny sufiks DNS, a te trasy wygrywają każde wyszukiwanie, które do nich pasuje. Cele publiczne, które nie pasują do żadnej trasy przedsiębiorstwa, spadają na łącze fizyczne, chyba że osobisty VPN rości je sobie pierwszy. Reguła pierwszeństwa rozstrzyga tylko nakładające się dopasowania, dlatego oba profile trzeba czytać jako tabele tras, a nie jako ikony.

Zapisz parę w dwóch wierszach i nazwij oczekiwanego zwycięzcę dla każdego: nazwa hosta służbowego, która rozwiązuje się na 10.x lub 172.16.x, powinna wychodzić przez tunel przedsiębiorstwa, a adres publiczny bez pasującego prefiksu powinien wziąć pozostałą trasę domyślną. Jeśli oba wiersze wskazują to samo wyjście, podział nie robi tego, co opisuje dokumentacja.

Zapisz dwa strumienie i przetestuj każdy

Dla każdego strumienia zapisz, która zatwierdzona konfiguracja ma go nieść i który resolver ma otrzymywać każdy rodzaj nazwy. Następnie zweryfikuj nowymi żądaniami, nie buforowaną stroną służbową ani starym wynikiem IP.

Zatrzymaj jedną konfigurację i powtórz oba strumienie. Zachowanie przy awarii jest częścią projektu i to jest ta część, którą zauważają użytkownicy. Gdy dwóch dostawców nie może obsłużyć kombinacji, wybierz jedną zatwierdzoną konfigurację i udokumentuj, który strumień niesie, albo przejdź na zarządzany projekt z jednym tunelem. Dokumentacja NETunnelProviderManager jest źródłem zasady współistnienia.