To Mac-innloggingskontoar deler ikkje VPN-trafikk
Eigaren av ein profil og omfanget av trafikken er to ulike spørsmål. På ein delt Mac vel du ei grense per app, gjest eller proxy og beviser at begge vegar fungerer.
To innloggingskontoar på same Mac ser ut som to skilde verdar til nettet kjem. Ein tunnel starta i éin økt kan likevel endre det den andre økta opplever, avhengig av kva klient som eig han og kva policy som følgjer med. Skildre separasjonen du treng før du vel ein mekanisme for å handheve han. Rekkjefølgja har noko å seie, fordi ein mekanisme som blir vald først har ein tendens til å omdefinere kravet rundt seg sjølv.
Tre spørsmål gjer det meste av arbeidet: kva appars kven som treng kva private ressursar, om begge øktene må vere aktive samstundes, og kva desse appane har lov til å gjere når tunnelen deira ikkje er tilgjengeleg.
Start med trafikken, ikkje med kontolista
Kontobyte er ei identitetsgrense, ikkje ei rutegrense. macOS lastar inn ein VPN-konfigurasjon for kontoen som eig han, men grensesnittet, rutene og kvar systemomfattande policy han installerer høyrer til maskinen. Viss kravet er at berre éin persons appar kjem inn på bedriftsnettet, må designet seie det i form av appar og mål, ikkje i form av kven som er logga inn. Elles arvar den andre kontoen det den første sin klient lét etter seg.
Skriv den påkravde åtferda i éin setning: éin brukars e-post og filtilgang følgjer den administrerte tunnelen, den andre brukaren si surfing blir på heimetilkoplinga, og ingen av vegane arvar den andre sin standardrute. Den setninga kan testast; ei historie om innloggingsbyte kan vanlegvis ikkje.
Profilkanal og trafikkomfang er ulike ting
Apple støttar administrerte VPN-ordningar som blir leverte per brukar eller per eining, og ein utrullingsrettleiar skildrar desse modellane saman med leverandøravhengig integrasjon. Leveringskanalen seier kven som får konfigurasjonen og eig han. Han definerer ikkje i seg sjølv kva trafikk som blir fanga, fordi klienten si implementasjon og den konfigurerte policyen framleis avgjer det.
Der ein dokumentert brukarbevisst eller appbevisst modus kan uttrykke kravet, er det den kortaste vegen. Deretter verifiserer du dei faktiske appane og identitetane i staden for å stole på namn: to kopiar av same app er ikkje to ulike nettverksvegar, og ein profil som listar ein app garanterer ikkje at hjelpeprosessane er dekte.
Eit gjestesystem er ei ekte grense med ekte avgrensingar
Ein virtuell maskin gir deg eit eige operativsystem med sin eigen nettverksstack, så ein gjest kan køyre sin eigen tunnel og sine eigne appar utan å røre verten sine ruter. Det er ein sterkare separasjon enn ein andre innloggingskonto, og det er også meir vedlikeholdsarbeid. Avgjer om den kostnaden kjøper ei grense du faktisk treng før du føreslår henne.
Modusen for virtuelt nettverk treng framleis gjennomgang. Om gjesten er brua, bak NAT eller isolert avgjer kva han kan nå og kva som kan nå han, og verten sine appar blir ikkje gjesten sine appar fordi gjesten tilfeldigvis er tilkopla. Sjekk også blokkeringspolicyen, elles fell ein droppa gjestetunnel tilbake til verten sin veg på ein måte ingen hadde tenkt seg.
Ein proxy er smalare enn ein brukarkonto
Éin vertsapp kan nå ein ekte proxeteneste som køyrer i ein godkjend gjest eller container, og det dekkjer trafikken appen faktisk sender gjennom den støtta protokollen. Det dekkjer ikkje kvar prosess som er eigd av den Mac-kontoen, og det dekkjer ikkje trafikk appen sender utanfor proxyprotokollen.
Endå ei forholdsregel på delte maskinar: ein TCP-lyttar bunden til verten sin loopback er ikkje ein brukarnamnkontroll. Å avgrense ein proxy til den lokale maskinen held han borte frå nettverket, men han autoriserer ikkje éin lokal brukar over ein annan som allereie er logga inn. Hald autentiseringa til tenesta eksplisitt viss den skilnaden betyr noko.
Bevis grensa med to testar
Køyr begge vegar og observer dei separat. Under den tiltenkte kontoen opnar du appen som treng den private ressursen og stadfestar at han når den administrerte tenesta; under den andre kontoen stadfestar du at vanleg surfing held på heimevegen. Bryt deretter tunnelen med vilje og sjekk fallback-åtferda på kvar side, for det er der dei fleste design sviktar stille. Gjer kontrollane i same time også, så eit endra nettverk ikkje forureinar samanlikninga.
Viss ein container eller gjest køyrer tunnelen, legg til ein tredje kontroll: stadfest at ein innebygd Mac-app utanfor han framleis oppfører seg som designa. Vel den enklaste ordninga der du kan demonstrere omfanget, og ikkje kall virtuelle maskinar universelt nødvendige eller kontobyte universelt tilstrekkeleg før du har køyrt desse testane.