Mac-VPN, Inhaltsfilter oder Private Relay: Was ist aktiv
Drei Netzwerkschichten am Mac sehen in den Einstellungen gleich aus. Unterscheiden Sie VPN, Inhaltsfilter und Private Relay über Ausgangspfad, Flussrichtlinie und Surfumfang.
Auf Ihrem Mac können gleichzeitig ein VPN-Tunnel, ein Inhaltsfilter und iCloud Private Relay installiert sein, und keines davon verrät, welches eine bestimmte Verbindung prägt. Die Einstellungsfenster sehen ähnlich aus, die Symbole sehen ähnlich aus, und fast jeder Anbieter nennt sein Produkt Netzwerksicherheit. Drei Fakten trennen sie: ob der Datenverkehr über einen entfernten Endpunkt austritt, den Sie benennen können, ob eine Richtlinien-Engine für einzelne Flüsse erlauben-oder-verwerfen entscheidet und ob der Schutz bei Safari endet. Bringen Sie diese drei Punkte in Ordnung, und die meisten Fragen der Art ist-mein-VPN-an beantworten sich von selbst.
Drei Bedingungen, die die Komponente bestimmen
Bedingung eins ist der Ausgang. Ein Tunnelanbieter übergibt Pakete an ein entferntes Gateway, sodass sich Ihre öffentliche Adresse ändert und, wenn das Profil es vorsieht, Hosts hinter diesem Gateway erreichbar werden. Ändert sich die Adresse nie und öffnet sich kein privates Subnetz, sehen Sie keinen funktionierenden Tunnel, was die Menüleiste auch behauptet.
Bedingung zwei ist die Entscheidung. Ein Inhaltsfilter bewertet Flüsse und gibt erlauben oder verwerfen zurück. Er kann eine Kategoriesperre, eine Regel pro App oder eine vom Arbeitgeber vorgegebene Richtlinie durchsetzen und das Urteil protokollieren. Was er allein nicht kann, ist dem Datenverkehr ein Ziel zu geben.
Bedingung drei ist der Umfang. Private Relay schützt einen definierten Teil des Surfens statt eines ganzen Geräts, und seine Aufgabe ist es, wer Sie sind von dem zu trennen, was Sie besuchen, nicht Sie in ein anderes Netzwerk zu setzen.
Stellen Sie die drei nebeneinander, und die Grenzen sind kaum zu übersehen:
| Layer | Question it answers | Evidence to look for | What it does not do |
|---|---|---|---|
| VPN tunnel provider | Where does my traffic emerge, and which private networks can I reach? | Changed public address, a connected service, a default route through a utun interface | Enforce per-app content policy |
| Content filter | May this flow proceed, and who decided? | A filter extension in Network Extensions, drop verdicts, an MDM profile | Supply a different public exit |
| iCloud Private Relay | Can the local network see which sites Safari loads? | A relay egress address in Safari only, the relay toggle in iCloud settings | Cover other apps or grant access to a private subnet |
Ein Inhaltsfilter ist eine Richtlinien-Engine, kein Ausgang
Unter macOS kommt ein Filter als Network Extension auf Basis der Filter-Datenprovider-Klasse von Apple, NEFilterDataProvider. In einer verwalteten Bereitstellung wird er per MDM verteilt, als Systemerweiterung installiert und einmal unter Systemeinstellungen > Allgemein > Anmeldeobjekte und Erweiterungen genehmigt. Danach sieht er TCP-Flüsse, in manchen Konfigurationen auch UDP, und gibt für jeden ein Urteil zurück.
Der Fehlermodus ist das, was Menschen verwirrt. Ein Filter, der einen Fluss verwirft, erzeugt einen Timeout, einen hängenden TLS-Handshake oder einen Reset, was genau wie ein Tunnel aussieht, der steht, aber keinen Verkehr durchlässt. Die öffentliche Adresse änderte sich nie, weil es nie einen Ausgang gab, der sie hätte ändern können.
Kommerzielle Clients bündeln oft beide Rollen. Ein Installer liefert Tunnelanbieter und Filter, der Filter blockiert, und der Tunnel routet. Der Anwendungsname sagt Ihnen also nichts darüber, welche Komponente die Verbindung abgelehnt hat. Prüfen Sie die Erweiterungsliste, dann den verbundenen Dienst, dann das Client-Protokoll, in dieser Reihenfolge.
Private Relay deckt Safari ab, nicht den Rechner
Private Relay schickt das von ihm abgedeckte Surfen durch zwei Relais, die von getrennten Parteien betrieben werden, sodass kein einzelner Betreiber sowohl Ihre Identität als auch Ihre Ziele hat. Das ist ein Datenschutzkonzept, kein Tunnel: Es gibt kein Gateway, in das Sie hineingehen können, kein privates Subnetz und keine Möglichkeit, eine Ausgangsadresse in einem Land Ihrer Wahl festzulegen.
Sein Umfang ist bewusst eng und deckt das Surfen in Safari samt der zugehörigen DNS-Abfragen und unsicheren HTTP-Ladevorgänge ab. Eine Terminalsitzung, ein Mailclient, eine Chat-App und ein Spielelauncher liegen außerhalb. Wenn eine Prüfung im Terminal weiterhin Ihre Zugangsnetzadresse zeigt, während Safari eine Relay-Adresse zeigt, ist das das erwartete Ergebnis und keine defekte Installation.
Die Verfügbarkeit ist bedingt. Es braucht einen iCloud+-Tarif, es wird nicht in jeder Region angeboten, und ein verwaltetes Netzwerk kann den Relay-Zugang sperren, woraufhin Safari auf eine direkte Verbindung zurückfällt. Apples Überblick zu Private Relay ist die Referenz für den aktuellen Umfang. Wenn ein VPN-Profil verbunden ist und diesen Verkehr führt, wird das Relais nicht darüber gestapelt; das Profil bestimmt den Pfad.
Lesen Sie die Belege in der richtigen Reihenfolge
Beginnen Sie mit dem Dienststatus, denn das ist das billigste Signal. scutil --nc list listet die konfigurierten VPN-Dienste und ob jeder verbunden ist. Ein Profil kann dort jahrelang liegen, ohne je verbunden zu werden, und Leute zählen das routinemäßig als Tunnel.
Schauen Sie dann auf Schnittstellen und Routen. ifconfig zeigt utun-Schnittstellen, doch ihre bloße Anwesenheit beweist wenig, da macOS utun für mehrere Zwecke außer VPN nutzt. Entscheidend ist, ob die Standardroute in eine davon zeigt, was route -n get default meldet.
Für die Namensauflösung listet scutil --dns die Resolver, die das System tatsächlich nutzt, und dort erscheint ein DNS-Proxy-Provider. Der Vergleich von dig +short example.com mit dig +short example.com @1.1.1.1 trennt den antwortenden Resolver von dem, der abgefangen wird.
Erweiterungsaktivität erreicht das einheitliche Protokoll: log show --predicate 'subsystem == "com.apple.networkextension"' --last 5m. Sie suchen, welche Erweiterung gestartet ist und ob ein Filter ein Urteil für den Fluss gemeldet hat, der Sie interessiert, nicht eine Zeile zum Auswendiglernen.
Grenzen Sie das Symptom ein, bevor Sie etwas deaktivieren
Ordnen Sie zuerst den Fehler ein. Ein Name, der nicht aufgelöst wird, eine sofort abgelehnte Verbindung und eine Verbindung, die bis zum Timeout hängt, sind drei verschiedene Beobachtungen mit drei verschiedenen Verursachern. Auflösung deutet auf einen Resolver oder DNS-Proxy. Sofortige Ablehnung deutet auf eine Filterregel. Stille deutet meist auf Routing oder auf einen Tunnel, der steht, aber nicht weiterleitet.
Gehen Sie bei einem verwalteten Mac davon aus, dass der Filter der Organisation gehört. Ihn zum VPN-Test zu deaktivieren, entfernt die Komponente, die Sie beobachten wollten, und MDM stellt ihn beim nächsten Check-in oft wieder her. Fragen Sie den Administrator vor jeder Änderung nach dem Richtliniennamen und testen Sie mit der konkreten App, die versagt hat, statt mit dem ganzen System.
Noch eine Falle: Private Relay abzuschalten, um ein VPN zu testen, sagt nichts über ausländischen Verkehr aus, weil das Relais diesen Verkehr nie abgedeckt hat. Jede Schicht muss in der App getestet werden, die sie tatsächlich steuert.
Arbeiten Sie diese Liste durch und halten Sie beim ersten Punkt an, der scheitert:
- Zeigt
scutil --nc listden erwarteten Dienst als verbunden? - Unterscheidet sich die im Terminal sichtbare öffentliche Adresse von der, die Ihr Zugangsnetz vergeben hat?
- Ist eine Filtererweiterung installiert, und hat sie ein Urteil für den fehlschlagenden Fluss protokolliert?
- Tritt der Fehler nur in Safari auf? Dann prüfen Sie den Relay-Umfang, bevor Sie den Tunnel beschuldigen.
Bestehen alle vier und die App scheitert weiterhin, liegt das Problem oberhalb der Netzwerkschicht: Proxy-Einstellungen, Zertifikatsvertrauen oder eine Positivliste auf Anwendungsebene.