Per-App-VPN oder Split-Tunnel? Was eine Mac-Route entscheiden kann
Eine Route wählt Ziele aus, nicht Prozesse. Vergleichen Sie zielbasiertes Split-Tunnelling mit einem verwalteten Per-App-VPN-Profil und mit einem lokalen Proxy als dritten Weg.
Zwei Anwendungen öffnen Verbindungen zum selben Büroserver, und nur eine von ihnen soll den Tunnel nutzen. Eine Route kann diesen Wunsch nicht ausdrücken, weil Routing-Tabellen nach Zielen aufgebaut sind und kein Begriff dafür existiert, welcher Prozess den Socket geöffnet hat. Was Leute verlangen und was sie brauchen, sind oft verschiedene Dinge. Trennen Sie beides, bevor Sie irgendeine Konfiguration ändern.
Der Selektor ist ein Ziel, niemals ein Prozess
Jede Routing-Entscheidung beginnt mit einer Zieladresse und endet mit einer Schnittstelle. Der Kernel fragt nie, welches Programm das Paket gesendet hat, und unter macOS routet auch pf nicht nach Prozess, sodass eine Firewall-Regel eine Anwendung nicht auf einen anderen Pfad legen kann. Deshalb nimmt derselbe Server, ob über einen Browser oder ein Reporting-Tool erreicht, für beide denselben Pfad. Eine Trennung auf Anwendungsebene muss daher von etwas anderem als einer Route kommen: ein VPN-Plugin, das den Socket besitzt, ein Proxy, der die Verbindung im Namen der Anwendung übernimmt, oder ein getrennter Netzwerk-Stack. Nichts davon ist eine Routing-Änderung.
Zwei Anwendungen, die mit einer Adresse sprechen, sind der sauberste Test für einen Entwurf. Wenn die Antwort für beide nicht unterschiedlich ausfallen kann, ist der Entwurf zielbasiert, wie auch immer er heißt.
Was ein gewöhnlicher Split-Tunnel tatsächlich bringt
Ein Split-Tunnel installiert Routen für die privaten Präfixe und lässt alles andere auf dem physischen Pfad. Das ist meistens, was die Anfrage meint: den Büroserver über den Tunnel erreichen, öffentliches Surfen direkt lassen. Es ist einfach, jeder gängige Client unterstützt es, und es wird durch denselben Mechanismus erzwungen wie jede andere Route. Prüfen Sie das konkrete Ziel mit route -n get, statt die Standardroute zu lesen, denn ein Split-Tunnel lässt die Standardroute oft unberührt.
Die Standardroute von Hand zu bearbeiten ist keine Umstellung auf irgendetwas. Es kämpft gegen die eigene Routenwiederherstellung des Clients und kann, bei Clients, die eine Schutzrichtlinie installieren, die Maschine in einem Zustand zurücklassen, den weder Sie noch der Client erwarten. Konfigurieren Sie den Split-Tunnel stattdessen in den unterstützten Einstellungen des Clients.
Was Per-App-VPN unter macOS voraussetzt
Echtes Per-App-VPN unter macOS ist eine Network-Extension-Funktion, die von einem Konfigurationsprofil gesteuert wird. Eine Verwaltungsnutzlast ordnet ausgewählte Anwendungen einer VPN-Konfiguration zu, und das System leitet den Datenverkehr dieser Anwendungen dann entsprechend. Es ist ein verwalteter Einsatz, was ein MDM, ein signiertes Profil und einen Administrator bedeutet, der beides besitzt.
Den Client von Hand zu installieren erzeugt diese Zuordnung nicht, und der gewöhnliche Einstellungsbereich macht Anwendungen nicht einzeln auswählbar. Ein Hersteller kann eigene Anwendungsregeln anbieten, und die folgen seiner Dokumentation statt einer allgemeinen Regel.
Drei Wege zu anwendungsbezogener Trennung ohne MDM
Wo keine Verwaltung verfügbar ist, ist ein Proxy die praktische Antwort. Setzen Sie die eigene Proxy-Konfiguration der Anwendung oder verwenden Sie eine PAC-Datei, die nur für diese Anwendung nach Ziel und Protokoll auswählt.
Ein lokaler Proxy beendet die Verbindung und erzeugt sie durch den Tunnel neu, sodass die Anwendung nie eine Route braucht. Die zweite Option ist ein getrennter Netzwerk-Stack: eine virtuelle Maschine oder ein Container mit eigener Standardroute, die die Anwendung über eine lokale Adresse erreicht. Die dritte ist, zielbasiertes Routing zu akzeptieren und die Anforderung fallen zu lassen, was ehrlich ist, wenn beide Anwendungen den Tunnel nutzen dürfen. Alle drei sind testbar, und keiner von ihnen tut so, als kenne eine Route Prozesse.
Formulieren Sie die Anfrage so, dass die Antwort eindeutig ist
Beschreiben Sie den Arbeitsablauf statt den Mechanismus: welche Anwendung welchen Dienst braucht, ob eine andere Anwendung von demselben Dienst ferngehalten werden muss und was passieren soll, während der Tunnel nicht steht. Diese drei Antworten bestimmen den Entwurf. Sie sagen dem Administrator auch, ob die Anfrage eine Routing-Änderung oder ein Bereitstellungsprojekt ist.
Nehmen Sie den Fall der ausgeschlossenen Anwendung ausdrücklich auf. Ein Client, der eine Anwendung stoppt, wenn ihr geschützter Pfad nicht verfügbar ist, verhält sich anders als einer, der sie auf die physische Schnittstelle zurückfallen lässt, und Benutzer merken diesen Unterschied sofort. Benennen Sie die Erwartung im Ticket. Prüfen Sie dann auf der tatsächlichen Maschine, denn dasselbe Produkt verhält sich unter macOS oft anders als unter Windows, und seine macOS-Dokumentation ist die einzige verlässliche Quelle dafür, was seine Einstellungen tun.