Dwa konta logowania na Macu nie dzielą ruchu VPN
Właściciel profilu i zasięg jego ruchu to dwa różne pytania. Na współdzielonym Macu wybierz granicę na aplikację, gościa lub proxy i udowodnij, że obie ścieżki działają.
Dwa konta logowania na tym samym Macu wyglądają jak dwa odrębne światy, dopóki nie pojawi się sieć. Tunel uruchomiony w jednej sesji wciąż może zmienić to, czego doświadcza druga sesja, w zależności od tego, który klient go posiada i jaka polityka mu towarzyszy. Opisz separację, której potrzebujesz, zanim wybierzesz mechanizm jej wymuszania. Kolejność ma znaczenie, ponieważ mechanizm wybrany pierwszy ma skłonność do przedefiniowania wymagania wokół siebie.
Trzy pytania wykonują większość pracy: czyje aplikacje potrzebują których prywatnych zasobów, czy obie sesje muszą być aktywne jednocześnie i co tym aplikacjom wolno robić, gdy ich tunel jest niedostępny.
Zacznij od ruchu, nie od listy kont
Przełączanie kont to granica tożsamości, nie granica routingu. macOS ładuje konfigurację VPN dla konta, które ją posiada, ale interfejs, jego trasy i wszelka polityka systemowa, którą instaluje, należą do maszyny. Jeśli wymaganiem jest, aby do sieci firmowej wchodziły tylko aplikacje jednej osoby, projekt musi to powiedzieć w kategoriach aplikacji i celów, a nie w kategoriach tego, kto jest zalogowany. Inaczej drugie konto dziedziczy to, co zostawił klient pierwszego.
Napisz wymagane zachowanie w jednym zdaniu: poczta i dostęp do plików jednego użytkownika podążają za zarządzanym tunelem, przeglądanie drugiego użytkownika zostaje na połączeniu domowym i żadna ze ścieżek nie dziedziczy domyślnej trasy drugiej. To zdanie da się przetestować; opowieść o przełączaniu logowania zwykle nie.
Kanał profilu i zasięg ruchu to dwie różne rzeczy
Apple obsługuje zarządzane rozwiązania VPN dostarczane na użytkownika lub na urządzenie, a przewodnik wdrożeniowy opisuje te modele wraz z integracją zależną od dostawcy. Kanał dostarczania mówi, kto otrzymuje konfigurację i kto ją posiada. Nie określa sam z siebie, który ruch jest przechwytywany, ponieważ implementacja klienta i skonfigurowana polityka wciąż o tym decydują.
Tam, gdzie udokumentowany tryb świadomy użytkownika lub aplikacji może wyrazić wymaganie, to najkrótsza droga. Potem zweryfikuj rzeczywiste aplikacje i tożsamości, zamiast ufać nazwom: dwie kopie tej samej aplikacji to nie dwie różne ścieżki sieciowe, a profil wymieniający aplikację nie gwarantuje, że jej procesy pomocnicze są objęte.
System gościa to prawdziwa granica z prawdziwymi ograniczeniami
Maszyna wirtualna daje osobny system operacyjny z własnym stosem sieciowym, więc gość może uruchomić własny tunel i własne aplikacje bez dotykania tras hosta. To silniejsza separacja niż drugie konto logowania, a także więcej pracy przy utrzymaniu. Zdecyduj, czy ten koszt kupuje granicę, której naprawdę potrzebujesz, zanim go zaproponujesz.
Tryb sieci wirtualnej nadal wymaga przeglądu. To, czy gość jest w trybie mostu, za NAT czy odizolowany, określa, do czego może dotrzeć i co może dotrzeć do niego, a aplikacje hosta nie stają się aplikacjami gościa dlatego, że gość przypadkiem jest podłączony. Sprawdź też politykę blokowania, inaczej zerwany tunel gościa wróci na ścieżkę hosta w sposób, którego nikt nie zamierzył.
Proxy jest węższe niż konto użytkownika
Jedna aplikacja hosta może dotrzeć do prawdziwej usługi proxy działającej w zatwierdzonym gościu lub kontenerze, i to obejmuje ruch, który aplikacja faktycznie wysyła przez obsługiwany protokół. Nie obejmuje każdego procesu posiadanego przez to konto Maca ani ruchu, który aplikacja wysyła poza protokołem proxy.
Jeszcze jedna ostrożność na współdzielonych maszynach: nasłuch TCP przypisany do loopbacku hosta nie jest sprawdzeniem nazwy użytkownika. Ograniczenie proxy do lokalnej maszyny trzyma je z dala od sieci, ale nie upoważnia jednego lokalnego użytkownika wobec drugiego, już zalogowanego. Utrzymuj uwierzytelnianie usługi jawnie, jeśli to rozróżnienie ma znaczenie.
Udowodnij granicę dwoma testami
Uruchom obie ścieżki i obserwuj je osobno. Pod zamierzonym kontem otwórz aplikację, która potrzebuje prywatnego zasobu, i potwierdź, że dociera do zarządzanej usługi; pod drugim kontem potwierdź, że zwykłe przeglądanie zachowuje ścieżkę domową. Następnie celowo zerwij tunel i sprawdź zachowanie zapasowe po każdej stronie, bo właśnie tam większość projektów zawodzi po cichu. Wykonaj kontrole również w tej samej godzinie, aby zmieniona sieć nie zanieczyściła porównania.
Jeśli tunel uruchamia kontener lub gość, dodaj trzecią kontrolę: potwierdź, że natywna aplikacja Maca poza nim nadal zachowuje się zgodnie z projektem. Wybierz najprostszy układ, którego zasięg potrafisz pokazać, i nie nazywaj maszyn wirtualnych uniwersalnie koniecznymi ani przełączania kont uniwersalnie wystarczającym, zanim wykonasz te testy.