Två Mac-inloggningskonton delar inte VPN-trafik
Ägaren av en profil och omfattningen av dess trafik är två olika frågor. På en delad Mac väljer du en gräns per app, gäst eller proxy och bevisar att båda vägarna fungerar.
Två inloggningskonton på samma Mac ser ut som två åtskilda världar tills nätverket kommer. En tunnel som startats i en session kan ändå förändra det den andra sessionen upplever, beroende på vilken klient som äger den och vilken policy som följer med. Beskriv den separation du behöver innan du väljer en mekanism för att genomdriva den. Ordningen spelar roll, eftersom en mekanism som väljs först tenderar att omdefiniera kravet runt sig själv.
Tre frågor gör det mesta av arbetet: vilka appars vem som behöver vilka privata resurser, om båda sessionerna måste vara aktiva samtidigt och vad dessa appar får göra när deras tunnel inte är tillgänglig.
Börja med trafiken, inte med kontolistan
Kontobyte är en identitetsgräns, inte en routinggräns. macOS läser in en VPN-konfiguration för kontot som äger den, men gränssnittet, dess rutter och alla systemomfattande policyer den installerar tillhör maskinen. Om kravet är att bara en persons appar kommer in i företagsnätet måste designen säga det i termer av appar och mål, inte i termer av vem som är inloggad. Annars ärver det andra kontot vad det förstas klient lämnade efter sig.
Skriv det krävda beteendet i en mening: en användares mejl och filåtkomst följer den hanterade tunneln, den andra användarens surfande stannar på hemanslutningen och ingen av vägarna ärver den andras standardrutt. Den meningen går att testa; en historia om inloggningsbyte gör det vanligtvis inte.
Profilkanal och trafikomfattning är olika saker
Apple stöder hanterade VPN-arrangemang som levereras per användare eller per enhet, och en distributionsguide beskriver dessa modeller tillsammans med leverantörsberoende integration. Leveranskanalen säger vem som tar emot konfigurationen och äger den. Den definierar inte i sig vilken trafik som fångas, eftersom klientens implementering och den konfigurerade policyn fortfarande avgör det.
Där ett dokumenterat användar- eller appmedvetet läge kan uttrycka kravet är det den kortaste vägen. Verifiera sedan de faktiska apparna och identiteterna i stället för att lita på namn: två kopior av samma app är inte två olika nätverksvägar, och en profil som listar en app garanterar inte att dess hjälpprocesser täcks.
Ett gästsystem är en riktig gräns med riktiga begränsningar
En virtuell maskin ger dig ett separat operativsystem med egen nätverksstack, så en gäst kan köra sin egen tunnel och sina egna appar utan att röra värdens rutter. Det är en starkare separation än ett andra inloggningskonto, och det är också mer underhållsarbete. Bestäm om den kostnaden köper en gräns du faktiskt behöver innan du föreslår den.
Läget för virtuellt nätverk behöver fortfarande ses över. Om gästen är bryggad, bakom NAT eller isolerad avgör vad den kan nå och vad som kan nå den, och värdens appar blir inte gästens appar bara för att gästen råkar vara ansluten. Kontrollera även blockeringspolicyn, annars faller en tappad gästtunnel tillbaka på värdens väg på ett sätt som ingen hade tänkt sig.
En proxy är smalare än ett användarkonto
En värdapp kan nå en riktig proxytjänst som körs i en godkänd gäst eller container, och det täcker den trafik appen faktiskt skickar via det stödda protokollet. Det täcker inte varje process som ägs av det Mac-kontot, och det täcker inte trafik appen skickar utanför proxyprotokollet.
Ännu en försiktighetsåtgärd på delade maskiner: en TCP-lyssnare bunden till värdens loopback är inte en användarnamnskontroll. Att begränsa en proxy till den lokala maskinen håller den borta från nätverket, men den ger inte en lokal användare behörighet över en annan som redan är inloggad. Håll tjänstens autentisering uttrycklig om den skillnaden spelar roll.
Bevisa gränsen med två tester
Kör båda vägarna och observera dem separat. Under det avsedda kontot öppnar du appen som behöver den privata resursen och bekräftar att den når den hanterade tjänsten; under det andra kontot bekräftar du att vanligt surfande behåller hemvägen. Bryt sedan tunneln med avsikt och kontrollera reservbeteendet på varje sida, för det är där de flesta designerna misslyckas tyst. Gör kontrollerna under samma timme också, så att ett förändrat nätverk inte förorenar jämförelsen.
Om en container eller gäst kör tunneln, lägg till en tredje kontroll: bekräfta att en inbyggd Mac-app utanför den fortfarande beter sig som designat. Välj det enklaste arrangemanget vars omfattning du kan demonstrera, och kalla inte virtuella maskiner universellt nödvändiga eller kontobyte universellt tillräckligt innan du har kört dessa tester.