Twee Mac-inlogaccounts splitsen VPN-verkeer niet

Twee inlogaccounts op dezelfde Mac lijken twee gescheiden werelden tot het netwerk arriveert. Een tunnel die in de ene sessie is gestart, kan nog steeds veranderen wat de andere sessie ervaart, afhankelijk van welke client hem bezit en welk beleid erbij hoort. Beschrijf de scheiding die u nodig hebt voordat u een mechanisme kiest om die af te dwingen. De volgorde is belangrijk, want een mechanisme dat eerst wordt gekozen, herdefinieert de eis vaak om zichzelf heen.

Drie vragen doen het meeste werk: welke apps van wie welke privébronnen nodig hebben, of beide sessies tegelijk actief moeten zijn en wat die apps mogen doen wanneer hun tunnel niet beschikbaar is.

Begin bij het verkeer, niet bij de accountlijst

Van account wisselen is een identiteitsgrens, geen routeringsgrens. macOS laadt een VPN-configuratie voor het account dat hem bezit, maar de interface, de routes en elk systeembreed beleid dat hij installeert, horen bij de machine. Als de eis is dat alleen de apps van één persoon het bedrijfsnetwerk binnenkomen, moet het ontwerp dat zeggen in termen van apps en bestemmingen, niet in termen van wie is ingelogd. Anders erft het tweede account wat de client van het eerste heeft achtergelaten.

Schrijf het vereiste gedrag in één zin: de mail en bestandstoegang van de ene gebruiker volgen de beheerde tunnel, het browsen van de andere gebruiker blijft op de thuisverbinding, en geen van beide wegen erft de standaardroute van de ander. Die zin is testbaar; een verhaal over inlogwissel meestal niet.

Profielkanaal en verkeersomvang zijn verschillende dingen

Apple ondersteunt beheerde VPN-regelingen die per gebruiker of per apparaat worden geleverd, en een implementatiehandleiding beschrijft die modellen samen met providerafhankelijke integratie. Het leveringskanaal zegt wie de configuratie ontvangt en bezit. Het bepaalt niet op zichzelf welk verkeer wordt vastgelegd, omdat de clientimplementatie en het geconfigureerde beleid dat nog steeds bepalen.

Waar een gedocumenteerde gebruiker- of appbewuste modus de eis kan uitdrukken, is dat de kortste weg. Verifieer daarna de werkelijke apps en identiteiten in plaats van namen te vertrouwen: twee kopieën van dezelfde app zijn geen twee verschillende netwerkpaden, en een profiel dat een app vermeldt, garandeert niet dat de hulpprocessen worden gedekt.

Een gastsysteem is een echte grens met echte beperkingen

Een virtuele machine geeft u een apart besturingssysteem met zijn eigen netwerkstack, zodat een gast zijn eigen tunnel en zijn eigen apps kan draaien zonder de routes van de host aan te raken. Dat is een sterkere scheiding dan een tweede inlogaccount, en het is ook meer onderhoudswerk. Bepaal of die kosten een grens kopen die u echt nodig hebt voordat u het voorstelt.

De modus voor virtueel netwerk moet nog steeds worden beoordeeld. Of de gast is overbrugd, achter NAT of geïsoleerd, bepaalt wat hij kan bereiken en wat hem kan bereiken, en hostapps worden geen gastapps omdat de gast toevallig verbonden is. Controleer ook het blokkeringsbeleid, anders valt een weggevallen gasttunnel terug op de weg van de host op een manier die niemand bedoelde.

Een proxy is smaller dan een gebruikersaccount

Eén hostapp kan een echte proxydienst bereiken die in een goedgekeurde gast of container draait, en dat dekt het verkeer dat de app daadwerkelijk via het ondersteunde protocol verstuurt. Het dekt niet elk proces dat eigendom is van dat Mac-account, en het dekt geen verkeer dat de app buiten het proxyprotocol verstuurt.

Nog een voorzorgsmaatregel op gedeelde machines: een TCP-listener die aan de loopback van de host is gebonden, is geen gebruikersnaamcontrole. Een proxy beperken tot de lokale machine houdt hem van het netwerk af, maar het machtigt niet de ene lokale gebruiker boven een andere die al is ingelogd. Houd de authenticatie van de dienst expliciet als dat onderscheid belangrijk is.

Bewijs de grens met twee tests

Voer beide wegen uit en observeer ze afzonderlijk. Open onder het bedoelde account de app die de privébron nodig heeft en bevestig dat die de beheerde dienst bereikt; bevestig onder het andere account dat gewoon browsen de thuisweg behoudt. Breek daarna de tunnel opzettelijk en controleer het terugvalgedrag aan elke kant, want daar falen de meeste ontwerpen stil. Doe de controles ook binnen hetzelfde uur, zodat een veranderd netwerk de vergelijking niet vervuilt.

Als een container of gast de tunnel draait, voeg dan een derde controle toe: bevestig dat een native Mac-app daarbuiten zich nog steeds gedraagt zoals ontworpen. Kies de eenvoudigste regeling waarvan u de reikwijdte kunt aantonen, en noem virtuele machines niet universeel noodzakelijk of accountwissel niet universeel voldoende voordat u die tests hebt uitgevoerd.