To Mac-login konti deler ikke VPN-trafik

To login-konti på samme Mac ser ud som to adskilte verdener, indtil netværket melder sig. En tunnel startet i én session kan stadig ændre det, den anden session oplever, afhængigt af hvilken klient der ejer den, og hvilken politik der følger med. Beskriv den adskillelse, du har brug for, før du vælger en mekanisme til at håndhæve den. Rækkefølgen betyder noget, fordi en mekanisme, der vælges først, har tendens til at omdefinere kravet omkring sig selv.

Tre spørgsmål gør det meste af arbejdet: hvis applikationer der har brug for hvilke private ressourcer, om begge sessioner skal være aktive samtidig, og hvad disse applikationer må gøre, når deres tunnel ikke er tilgængelig.

Start med trafikken, ikke med kontolisten

Kontoskift er en identitetsgrænse, ikke en routinggrænse. macOS indlæser en VPN-konfiguration for den konto, der ejer den, men grænsefladen, dens ruter og enhver systemdækkende politik, den installerer, tilhører maskinen. Hvis kravet er, at kun én persons applikationer kommer ind på virksomhedsnetværket, skal designet sige det i form af applikationer og destinationer, ikke i form af hvem der er logget ind. Ellers arver den anden konto det, den førstes klient efterlod.

Skriv den krævede adfærd i én sætning: én brugers mail og filadgang følger den administrerede tunnel, den anden brugers browsing bliver på hjemmeforbindelsen, og ingen af vejene arver den andens standardrute. Den sætning kan testes; en historie om login-skift kan normalt ikke.

Profilkanal og trafikomfang er forskellige ting

Apple understøtter administrerede VPN-ordninger leveret pr. bruger eller pr. enhed, og en udrulningsvejledning beskriver disse modeller sammen med udbyderafhængig integration. Leveringskanalen siger, hvem der modtager konfigurationen og ejer den. Den definerer ikke i sig selv, hvilken trafik der opfanges, fordi klientens implementering og den konfigurerede politik stadig afgør det.

Hvor en dokumenteret brugermedvidende eller applikationsmedvidende tilstand kan udtrykke kravet, er det den korteste vej. Bekræft derefter de faktiske applikationer og identiteter i stedet for at stole på navne: to kopier af samme app er ikke to forskellige netværksveje, og en profil, der lister en app, garanterer ikke, at dens hjælpeprocesser er dækket.

Et gæstesystem er en rigtig grænse med rigtige begrænsninger

En virtuel maskine giver dig et separat operativsystem med sin egen netværksstak, så en gæst kan køre sin egen tunnel og sine egne applikationer uden at røre værtens ruter. Det er en stærkere adskillelse end en anden login-konto, og det er også mere arbejde at vedligeholde. Beslut, om den pris køber en grænse, du faktisk har brug for, før du foreslår den.

Tilstanden for det virtuelle netværk skal stadig gennemgås. Om gæsten er broet, bag NAT eller isoleret afgør, hvad den kan nå, og hvad der kan nå den, og værtens applikationer bliver ikke gæstens applikationer, fordi gæsten tilfældigvis er forbundet. Tjek også blokeringspolitikken, ellers falder en droppet gæstetunnel tilbage til værtens vej på en måde, ingen havde tænkt sig.

En proxy er snævrere end en brugerkonto

Én værtsapplikation kan nå en rigtig proxy-tjeneste, der kører i en godkendt gæst eller container, og det dækker den trafik, applikationen faktisk sender gennem den understøttede protokol. Det dækker ikke enhver proces, der ejes af den Mac-konto, og det dækker ikke trafik, som applikationen sender uden for proxy-protokollen.

Endnu en advarsel på delte maskiner: en TCP-lytter bundet til værtens loopback er ikke en brugernavnskontrol. At begrænse en proxy til den lokale maskine holder den væk fra netværket, men den autoriserer ikke én lokal bruger over en anden, der allerede er logget ind. Hold tjenestens godkendelse eksplicit, hvis den forskel betyder noget.

Bevis grænsen med to tests

Kør begge veje og observer dem hver for sig. Under den tilsigtede konto skal du åbne den applikation, der har brug for den private ressource, og bekræfte, at den når den administrerede tjeneste; under den anden konto skal du bekræfte, at almindelig browsing beholder hjemvejen. Bryd derefter tunnelen med vilje, og tjek fallback-adfærden for hver side, for det er der, de fleste designs stille fejler. Kør kontrollerne i den samme time, så et ændret netværk ikke forurener sammenligningen.

Hvis en container eller gæst kører tunnelen, skal du tilføje en tredje kontrol: bekræft, at en indbygget Mac-applikation uden for den stadig opfører sig som designet. Vælg den enkleste ordning, hvis omfang du kan demonstrere, og kald ikke virtuelle maskiner universelt nødvendige eller kontoskift universelt tilstrækkeligt, før du har kørt disse tests.