Welches macOS-Werkzeug kann eine einzige App ausschließlich durch das VPN zwingen?
Eine Nur-VPN-Grenze braucht sowohl einen Weg als auch eine Ablehnung. Vergleichen Sie Profile pro App, Proxys, Filter und PF und testen Sie dann die eine App, die Ihnen wichtig ist.
Eine Zeile in einem Anforderungsdokument – „diese App darf das VPN nutzen und sonst nichts“ – verlangt still nach zwei Mechanismen, die kein einzelner Schalter bereitstellt. Der Datenverkehr braucht einen Weg durch den vorgesehenen Tunnel, und Verkehr, der direkt hinausgehen würde, muss abgelehnt werden. Werkzeuge, die das eine gut und das andere gar nicht können, sind häufig, weshalb ein Vergleich, der nur fragt, ob etwas blockieren kann, selbstbewusst die Hälfte der Frage beantwortet. Schreiben Sie zuerst die Grenze auf und wählen Sie dann die Komponenten, die beide Hälften davon abdecken.
Zwei Anforderungen, die sich in einem Satz verstecken
Lenkung ist der Teil, der eine Verbindung in den Tunnel oder den Proxy bringt. Ablehnung ist der Teil, der dieselbe Verbindung daran hindert, über irgendeinen anderen Weg hinauszugehen. Unterschiedliche Komponenten setzen sie um, sie versagen auf unterschiedliche Weise, und ein Produkt kann bei dem einen hervorragend sein und zum anderen nichts sagen:
| Approach | Steers traffic | Refuses direct egress | Knows the app identity |
|---|---|---|---|
| Per-app VPN profile | Yes, for the apps it names | Only if a filter or firewall also blocks | Yes, within its own rules |
| Application proxy setting | Partly, for requests that honour it | No | No |
| Content filter | No | Yes | Yes, if the filter is written that way |
| Local PF ruleset | No | Yes, by address and port | Not reliably |
Lesen Sie die Tabelle als Checkliste und nicht als Rangfolge. Keine Zeile füllt beide mittleren Spalten, und die Zeilen, die sie abdecken, sind zwei zusammenarbeitende Komponenten: die eine besitzt den Weg, die andere die Ablehnung. Die Identitätsspalte ist aus einem anderen Grund wichtig, denn eine Regel, die die App nicht benennen kann, kann keine Regel über diese App durchsetzen. Was immer Sie einsetzen, muss alle drei beantworten, sonst ist die Grenze im Anforderungsdokument nicht die Grenze auf der Maschine.
Lenkung allein lässt einen Ausweg
Die Anwendungsproxy-Einstellung ist das klarste Beispiel für Lenkung ohne Ablehnung. Sie kann Anfragen einer App lenken, die den Systemproxy beachtet, und deckt nichts anderes ab: ein Hilfsprozess, ein Aktualisierungsprogramm, ein Hintergrunddienst oder ein anderes Protokoll können ihren eigenen Weg nehmen, ohne diese Einstellung je zu lesen. Einen SOCKS-Endpunkt in einem Fenster auszuwählen, schafft daher keine Richtlinie gegen direkten Ausgang für die Anwendung. Wenn die Anforderung die App als Ganzes betrifft, fragen Sie, welche Komponenten die Regel tatsächlich identifiziert.
Ein VPN-Profil pro App lenkt besser als ein Proxy, weil die Plattform entscheidet, welche Apps in den Tunnel gelangen statt dass jede App selbst entscheidet. Dennoch lehnt es nichts ab: Das Profil liefert einen Weg, und Verkehr, der nicht dazu passt, nimmt die gewöhnliche Route. Genau diese Lücke ist der Punkt, an dem eine zweite Komponente ihren Platz verdient, und deshalb sind Produkte, die wie ein Schalter aussehen, meist zwei.
Ablehnung allein macht die App unbrauchbar
Apples Dokumentation zu Inhaltsfiltern beschreibt ein Zulassen-oder-Blockieren-Urteil über Verkehr, während er den Netzwerk-Stack durchläuft. Dieses Urteil ist kein Tunnel und keine Proxyverbindung, weil es entscheidet, ob etwas weitergehen darf, und nicht, wohin es geht. Ein Filter allein setzt die Ablehnung perfekt durch und lässt die Anwendung unbrauchbar zurück, mit sauberen Protokollen und ohne Erklärung. Ein Filterurteil kann eine Verbindung stoppen, liefert aber nie den Tunnel, deshalb ist die Paarung mit Lenkung die Designentscheidung und kein optionaler Zusatz.
Ein lokal verwaltetes PF-Regelwerk steht am anderen Ende dieses Spektrums. Es ist eine legitime Supportentscheidung auf einer Maschine, die ein Administrator besitzt, und es ist nicht automatisch die Grundlage eines verteilbaren Produkts, denn wer das Regelwerk besitzt, besitzt auch dessen Wechselwirkungen mit anderen Firewall-Nutzern, seinen Aktualisierungspfad und seine Wiederherstellung, wenn eine Regel falsch ist. PF zu einem Produkt hinzuzufügen, beseitigt diese Eigentumsfrage nicht; es definiert sie.
Die Bereitstellung entscheidet, ob die Regel morgen noch existiert
Wie eine Network Extension auf Apple-Plattformen bereitgestellt wird, hängt vom Anbietertyp, der Paketierung und der OS-Version vor Ihnen ab. Eine App-Erweiterung unter macOS läuft in einem Benutzerkontext und endet, wenn sich dieser Benutzer abmeldet, während eine Systemerweiterung einen globalen Kontext hat, der nicht von der Sitzung abhängt. Wenn der Schutz eine Abmeldung überstehen muss, ist dieser Unterschied das ganze Design und keine Fußnote. Bestätigen Sie den Bereitstellungsweg, bevor Sie das Verhalten versprechen, denn derselbe Code landet je nach ausgeliefertem Erweiterungstyp anders.
Die Verfügbarkeit des Quellcodes ist eine andere Sache als die Durchsetzung. Ein Repository zu lesen sagt Ihnen, wie etwas umgesetzt ist, nicht, was die installierte Binärdatei auf dieser Maschine tun darf. Signierung, Installation und Autorisierung gelten weiterhin, und Anleitungen, die um eine veraltete Kernel-Erweiterung oder einen Bibliotheksinjektionstrick herum gebaut sind, beschreiben eine andere Plattform und eine andere Risikohaltung, so gut sie einst funktioniert haben mögen.
Ein Abnahmefall, der die App benennt
Wählen Sie eine einzelne Aktion, die die Anwendung von sich aus ausführt, notieren Sie die Adresse, die sie erreichen soll, und ob diese Adresse IPv4 oder IPv6 ist, und wiederholen Sie dann dieselbe Aktion im genehmigten Zustand ohne Tunnel. Der zweite Lauf muss die erklärte Ablehnung erzeugen und keinen stillen direkten Neuversuch. Das ist die Hälfte, die Menschen unspezifiziert lassen, und die einzige Hälfte, die beweist, dass Ablehnung überhaupt existiert. Führen Sie ihn zuerst mit verfügbarem Tunnel aus, damit ein Unterschied zwischen den beiden Ergebnissen nur vom fehlenden Tunnel kommen kann.
Gehen Sie dann die Übergänge durch, die die Anforderung nennt: Neustart der App, ein auslösender Hilfsprozess, das erneute Verbinden des Tunnels, ein Netzwerkwechsel der Maschine sowie Abmeldung oder Neustart, wo das zutrifft. Eine öffentliche IP-Seite im Browser ist kein Test der Sockets einer anderen Anwendung, kann diesen also nicht ersetzen. Wo keine unterstützte Bereitstellung das tatsächliche Verhalten der App abdeckt, ist eine autorisierte isolierte Umgebung mit ausdrücklichem Gateway und ohne alternativen Ausgang eine Eindämmungsentscheidung mit eigenen Verwaltungskosten, kein Ersatz für ein Kontrollkästchen.
Schließen Sie ab, indem Sie vier Punkte notieren: aus welchen Komponenten die App besteht, wer die Lenkung besitzt, wer die Ablehnung besitzt und in welchen Zuständen die Regel noch gelten muss. Ein öffentliches Repository kann ein Auswahlkriterium sein, aber es ist keines der vier, und diese Punkte entscheiden, ob ein bestimmtes Werkzeug die Netzwerkanforderung erfüllt.