Zwei Mac-Anmeldekonten teilen keinen VPN-Traffic

Zwei Anmeldekonten auf demselben Mac wirken wie zwei getrennte Welten, bis das Netzwerk ins Spiel kommt. Ein in einer Sitzung gestarteter Tunnel kann dennoch verändern, was die andere Sitzung erlebt, je nachdem, welcher Client ihn besitzt und welche Richtlinie mit ihm kommt. Beschreiben Sie die Trennung, die Sie brauchen, bevor Sie einen Mechanismus zu ihrer Durchsetzung wählen. Die Reihenfolge ist wichtig, weil ein zuerst gewählter Mechanismus dazu neigt, die Anforderung um sich selbst herum neu zu definieren.

Drei Fragen erledigen den größten Teil der Arbeit: Welche Anwendungen von wem brauchen welche privaten Ressourcen, müssen beide Sitzungen gleichzeitig aktiv sein, und was dürfen diese Anwendungen tun, wenn ihr Tunnel nicht verfügbar ist.

Beginnen Sie beim Traffic, nicht bei der Kontenliste

Kontowechsel ist eine Identitätsgrenze, keine Routinggrenze. macOS lädt eine VPN-Konfiguration für das Konto, das sie besitzt, aber die Schnittstelle, ihre Routen und jede systemweite Richtlinie, die sie installiert, gehören dem Rechner. Wenn die Anforderung lautet, dass nur die Anwendungen einer Person in das Unternehmensnetz gelangen, muss das Design es in Begriffen von Anwendungen und Zielen ausdrücken, nicht in Begriffen dessen, wer angemeldet ist. Sonst erbt das zweite Konto, was der Client des ersten hinterlassen hat.

Schreiben Sie das geforderte Verhalten in einem Satz: Die Mail- und Dateizugriffe eines Nutzers folgen dem verwalteten Tunnel, das Surfen des anderen Nutzers bleibt auf der Heimverbindung, und keiner der Wege erbt die Standardroute des anderen. Dieser Satz ist prüfbar; eine Geschichte vom Anmeldewechsel ist es meist nicht.

Profilkanal und Traffic-Umfang sind verschiedene Dinge

Apple unterstützt verwaltete VPN-Arrangements, die pro Benutzer oder pro Gerät bereitgestellt werden, und ein Bereitstellungshandbuch beschreibt diese Modelle zusammen mit anbieterabhängiger Integration. Der Auslieferungskanal sagt, wer die Konfiguration erhält und besitzt. Er legt nicht von sich aus fest, welcher Traffic erfasst wird, weil die Client-Implementierung und die konfigurierte Richtlinie das weiterhin entscheiden.

Wo ein dokumentierter benutzer- oder anwendungsbewusster Modus die Anforderung ausdrücken kann, ist das der kürzeste Weg. Prüfen Sie dann die tatsächlichen Anwendungen und Identitäten, statt Namen zu vertrauen: Zwei Kopien derselben App sind keine zwei verschiedenen Netzwerkwege, und ein Profil, das eine App auflistet, garantiert nicht, dass ihre Hilfsprozesse abgedeckt sind.

Ein Gastsystem ist eine echte Grenze mit echten Grenzen

Eine virtuelle Maschine gibt Ihnen ein separates Betriebssystem mit eigenem Netzwerk-Stack, sodass ein Gast seinen eigenen Tunnel und seine eigenen Anwendungen betreiben kann, ohne die Routen des Hosts anzutasten. Das ist eine stärkere Trennung als ein zweites Anmeldekonto, und es ist auch mehr Pflegeaufwand. Entscheiden Sie, ob dieser Preis eine Grenze kauft, die Sie wirklich brauchen, bevor Sie sie vorschlagen.

Der Modus des virtuellen Netzwerks braucht trotzdem eine Prüfung. Ob der Gast gebrückt, hinter NAT oder isoliert ist, bestimmt, was er erreichen kann und was ihn erreichen kann, und Host-Anwendungen werden nicht zu Gast-Anwendungen, nur weil der Gast zufällig verbunden ist. Prüfen Sie auch die Blockierungsrichtlinie, sonst fällt ein ausgefallener Gast-Tunnel auf eine Weise auf den Weg des Hosts zurück, die niemand beabsichtigt hat.

Ein Proxy ist enger als ein Benutzerkonto

Eine Host-Anwendung kann einen echten Proxy-Dienst erreichen, der in einem freigegebenen Gast oder Container läuft, und das deckt den Traffic ab, den die Anwendung tatsächlich über das unterstützte Protokoll sendet. Es deckt nicht jeden Prozess ab, der diesem Mac-Konto gehört, und nicht den Traffic, den die Anwendung außerhalb des Proxy-Protokolls sendet.

Noch ein Hinweis auf gemeinsam genutzten Rechnern: Ein an das Host-Loopback gebundener TCP-Listener ist keine Benutzernamenprüfung. Einen Proxy auf den lokalen Rechner zu beschränken hält ihn vom Netz fern, autorisiert aber nicht einen lokalen Benutzer gegenüber einem anderen, der bereits angemeldet ist. Halten Sie die Authentifizierung des Dienstes explizit, wenn diese Unterscheidung zählt.

Belegen Sie die Grenze mit zwei Tests

Führen Sie beide Wege aus und beobachten Sie sie getrennt. Öffnen Sie unter dem vorgesehenen Konto die Anwendung, die die private Ressource braucht, und bestätigen Sie, dass sie den verwalteten Dienst erreicht; bestätigen Sie unter dem anderen Konto, dass gewöhnliches Surfen den Heimweg behält. Brechen Sie dann den Tunnel absichtlich ab und prüfen Sie das Rückfallverhalten auf jeder Seite, denn dort scheitern die meisten Designs still. Führen Sie die Prüfungen auch in derselben Stunde aus, damit ein geändertes Netz den Vergleich nicht verfälscht.

Wenn ein Container oder Gast den Tunnel betreibt, fügen Sie eine dritte Prüfung hinzu: Bestätigen Sie, dass eine native Mac-Anwendung außerhalb davon sich weiterhin wie entworfen verhält. Wählen Sie die einfachste Anordnung, deren Umfang Sie demonstrieren können, und bezeichnen Sie virtuelle Maschinen nicht als generell nötig oder Kontowechsel als generell ausreichend, bevor Sie diese Tests ausgeführt haben.