To Mac-innloggingskontoer deler ikke VPN-trafikk
Eieren av en profil og omfanget av trafikken er to forskjellige spørsmål. På en delt Mac velger du en grense per app, gjest eller proxy og beviser at begge veier fungerer.
To innloggingskontoer på samme Mac ser ut som to adskilte verdener til nettverket kommer. En tunnel startet i én økt kan likevel endre det den andre økten opplever, avhengig av hvilken klient som eier den og hvilken policy som følger med. Beskriv separasjonen du trenger før du velger en mekanisme for å håndheve den. Rekkefølgen betyr noe, fordi en mekanisme som velges først har en tendens til å omdefinere kravet rundt seg selv.
Tre spørsmål gjør det meste av arbeidet: hvilke apper til hvem som trenger hvilke private ressurser, om begge øktene må være aktive samtidig, og hva disse appene har lov til å gjøre når tunnelen deres ikke er tilgjengelig.
Start med trafikken, ikke med kontolisten
Kontobytte er en identitetsgrense, ikke en rutegrense. macOS laster inn en VPN-konfigurasjon for kontoen som eier den, men grensesnittet, rutene og enhver systemomfattende policy den installerer tilhører maskinen. Hvis kravet er at bare én persons apper kommer inn på bedriftsnettet, må designet si det i form av apper og mål, ikke i form av hvem som er logget inn. Ellers arver den andre kontoen det den førstes klient etterlot.
Skriv den påkrevde atferden i én setning: én brukers e-post og filtilgang følger den administrerte tunnelen, den andre brukerens surfing blir på hjemmetilkoblingen, og ingen av veiene arver den andres standardrute. Den setningen kan testes; en historie om innloggingsbytte kan vanligvis ikke.
Profilkanal og trafikkomfang er forskjellige ting
Apple støtter administrerte VPN-ordninger som leveres per bruker eller per enhet, og en utrullingsveiledning beskriver disse modellene sammen med leverandøravhengig integrasjon. Leveringskanalen sier hvem som mottar konfigurasjonen og eier den. Den definerer ikke i seg selv hvilken trafikk som fanges, fordi klientens implementasjon og den konfigurerte policyen fortsatt avgjør det.
Der en dokumentert brukerbevisst eller appbevisst modus kan uttrykke kravet, er det den korteste veien. Deretter verifiserer du de faktiske appene og identitetene i stedet for å stole på navn: to kopier av samme app er ikke to forskjellige nettverksveier, og en profil som lister en app garanterer ikke at hjelpeprosessene er dekket.
Et gjestesystem er en ekte grense med ekte begrensninger
En virtuell maskin gir deg et eget operativsystem med sin egen nettverksstack, så en gjest kan kjøre sin egen tunnel og sine egne apper uten å røre vertens ruter. Det er en sterkere separasjon enn en andre innloggingskonto, og det er også mer vedlikeholdsarbeid. Avgjør om den kostnaden kjøper en grense du faktisk trenger før du foreslår den.
Modusen for virtuelt nettverk trenger fortsatt gjennomgang. Om gjesten er broet, bak NAT eller isolert avgjør hva den kan nå og hva som kan nå den, og vertens apper blir ikke gjestens apper fordi gjesten tilfeldigvis er tilkoblet. Sjekk også blokkeringspolicyen, ellers faller en droppet gjestetunnel tilbake til vertens vei på en måte ingen hadde tenkt seg.
En proxy er smalere enn en brukerkonto
Én vertsapp kan nå en ekte proxytjeneste som kjører i en godkjent gjest eller container, og det dekker trafikken appen faktisk sender gjennom den støttede protokollen. Det dekker ikke hver prosess som eies av den Mac-kontoen, og det dekker ikke trafikk appen sender utenfor proxyprotokollen.
Nok en forholdsregel på delte maskiner: en TCP-lytter bundet til vertens loopback er ikke en brukernavnskontroll. Å begrense en proxy til den lokale maskinen holder den borte fra nettverket, men den autoriserer ikke én lokal bruker over en annen som allerede er logget inn. Hold tjenestens autentisering eksplisitt hvis den forskjellen betyr noe.
Bevis grensen med to tester
Kjør begge veier og observer dem separat. Under den tiltenkte kontoen åpner du appen som trenger den private ressursen og bekrefter at den når den administrerte tjenesten; under den andre kontoen bekrefter du at vanlig surfing beholder hjemveien. Bryt deretter tunnelen med vilje og sjekk fallback-atferden på hver side, for det er der de fleste design feiler stille. Gjør kontrollene i samme time også, så et endret nettverk ikke forurenser sammenligningen.
Hvis en container eller gjest kjører tunnelen, legg til en tredje kontroll: bekreft at en innebygd Mac-app utenfor den fortsatt oppfører seg som designet. Velg den enkleste ordningen hvis omfang du kan demonstrere, og ikke kall virtuelle maskiner universelt nødvendige eller kontobytte universelt tilstrekkelig før du har kjørt disse testene.