Mac-VPN-Einstellungen starten keinen Server: wo das Gateway wohnt
Ein VPN-Eintrag auf einem Mac wählt sich nur nach außen. Drei Fragen entscheiden, ob du stattdessen einen Gateway-Host brauchst, und wie du den Listener nachweist, bevor Clients kommen.
Zwei verschiedene Aufgaben tragen unter macOS den Namen VPN, und das Einstellungsfenster behandelt nur eine davon. Soll der Datenverkehr dieses Mac über einen Anbieter oder ein entferntes Gateway hinausgehen, brauchst du nur einen Client-Eintrag. Willst du vom Hotelzimmer aus den Drucker, das NAS oder eine Admin-Seite in deinem Heimnetz erreichen, muss etwas in diesem Netz Verbindungen von außen annehmen, und ein aktueller Mac ist das nicht einfach so ab Werk. Drei Fragen klären, in welchem Fall du bist, und sie lohnen sich, bevor du eine Adresse in ein Feld tippst.
Ein Client-Eintrag nennt ein Ziel, keinen Listener
In den Systemeinstellungen > Netzwerk > VPN beschreiben unter macOS Ventura und neuer die Felder, die ältere Versionen unter Netzwerk-Einstellungen führen, wie man den Endpunkt eines anderen erreicht: eine Serveradresse, eine entfernte ID, ein Konto oder Zertifikat und optionale Regeln für die Verbindung auf Anforderung. Wer diesen Eintrag sichert, speichert eine Verbindung in der Netzwerkkonfiguration des Mac. Nichts in diesem Vorgang bindet einen Port, öffnet einen Listener oder trägt einen entfernten Benutzer ein.
Das lässt sich in der Shell prüfen. Führe auf einem Mac, von dem du vermutest, dass er dient, sudo lsof -nP -iUDP aus und suche die Ports deines Protokolls: 500 und 4500 für IKEv2, 1194 für OpenVPNs Standard, 51820 für WireGuard. Eine reine Client-Maschine zeigt Sockets, die mit einer entfernten Adresse und einem Port gepaart sind, keine Wildcard-Bindung, die irgendetwas im Internet erreichen könnte. Tunnel, die in einer Network Extension laufen, können sich vor lsof verstecken, also gleiche in jedem Fall das Statusfenster der App selbst ab; was du nicht findest, ist eine Apple-Einstellung, die diesen Mac zum Gateway macht.
Drei Fragen trennen die beiden Rollen
Geh sie der Reihe nach durch. Die erste entscheidet meist den Rest, und bei der dritten geht die meiste Mac-spezifische Planung schief.
1. Wer beginnt das Gespräch? Wenn dein Mac nach außen wählt und die andere Seite antwortet, brauchst du einen Client. Wenn Geräte im Internet hereinwählen müssen, um dein Netz zu erreichen, brauchst du ein Gateway mit einem öffentlichen Einstiegspunkt, und der Mac kann ein Client dieses Gateways bleiben.
2. Was muss erreichbar sein, solange der Tunnel steht? Ein Dienst auf einem Host ist eine Portweiterleitung. Ein ganzes Subnetz samt Namensauflösung ist eine Routing- und DNS-Entscheidung, und sie ändert, was das Gateway weiterleiten muss, nicht was der Client-Eintrag sagt.
3. Welche OS-Version betreibt die annehmende Seite? Für Macs hat diese Frage eine harte Antwort. Apple führt VPN als aus macOS Server 5.7.1 entfernt, und die macOS-Server-App selbst wurde am 21. April 2022 eingestellt; die Seite, die man lesen sollte, wenn ein altes Tutorial dich durch ein Kontrollkästchen für den VPN-Dienst führt, das es nicht mehr gibt, ist die Mitteilung zum Dienstverlauf.
Lautet die erste Antwort „jemand draußen beginnt“, suche nicht weiter nach einem Schalter im Client-Fenster des Mac und wähle den Host, der den Tunnel beenden wird.
Wo das Gateway stattdessen wohnen kann
Vier Anordnungen decken die meisten Heim- und Kleinbürofälle ab. Ein Router mit echtem Servermodus, im Gegensatz zu einem Clientmodus mit anderem Etikett, beendet den Tunnel am Rand und hält die Zahl der Hosts klein, kostet aber Bindung an die Protokollunterstützung dieser Firmware. Ein NAS oder ein ständig laufender Mini-PC betreibt das Serverpaket des Herstellers und hinterlässt Logs, die du lesen kannst. Eine kleine Cloud-VM gibt dir eine öffentliche Adresse, die du kontrollierst, und erreicht dein Zuhause über einen zweiten Tunnel. Ein Mesh-Overlay auf Basis von WireGuard oder ein verwalteter Dienst, der zwischen Peers vermittelt, umgeht die Weiterleitung eingehender Ports, indem beide Enden nach außen wählen.
Die Grenze zwischen diesen Optionen ist meist deine Internetverbindung, nicht die Software. Wenn der Anbieter dich hinter Carrier-Grade-NAT setzt, erzeugt keine Portweiterleitung am Router einen erreichbaren Einstiegspunkt, und ein Relay- oder Mesh-Aufbau ist die ehrliche Antwort. Vergleiche die WAN-Adresse, die dein Router meldet, mit der Adresse, die die Außenwelt sieht; weichen sie ab und liegt der Router-Wert in einem privaten oder geteilten Bereich, plane den Relay-Fall ein.
Welchen Host du auch wählst, leite ein Protokoll über einen Port weiter statt über einen Bereich, und halte den Mac aus dem eingehenden Pfad heraus, es sei denn, genau dieses Produkt dokumentiert eine Serverrolle für die macOS-Version, die du betreibst.
Bestätige die Rolle, bevor du Profile ausgibst
Beweise auf dem Kandidaten-Gateway, dass ein Listener existiert, statt darauf zu vertrauen, dass das Installationsprogramm einen angelegt hat. Auf macOS heißt das sudo lsof -nP -iUDP gefiltert auf die oben genannten Ports, plus sudo pfctl -s nat, wenn Paketfilterregeln Teil des Entwurfs sind. Auf Linux zeigt ss -lunp dieselben Fakten ohne Mehrdeutigkeit.
Dann teste von außerhalb des Netzes mit dem Protokoll selbst. Ping beweist wenig: ICMP wird häufig gefiltert und sagt nichts über UDP 51820. Ein Client-Handshake mit ausführlicher Protokollierung, ausgeführt von einem Telefon über Mobilfunkdaten, ist der billigste echte Test, weil er denselben Weg kreuzt, den ein entfernter Kollege nehmen wird.
Erst danach fasst du Client-Profile an. Auf dem Mac druckt scutil --nc list die VPN-Dienste aus, die das System kennt; ist das Gateway, das du gerade gebaut hast, nicht darunter, konfigurierst du eine andere Maschine als die getestete. Klappt der Handshake im LAN, scheitert aber von außen, liegt der Fehler im eingehenden Pfad: NAT-Regel, CGNAT des Anbieters oder eine Firewall auf dem Gateway, in dieser Reihenfolge.
Bevor du etwas baust, klärst du vier Punkte:
- Welche Seite die Verbindung beginnt, dein Mac oder ein entferntes Gerät.
- Ob OS-Version und Produkt des annehmenden Hosts tatsächlich eine Serverrolle unterstützen.
- Ob dein Anbieter dir überhaupt eine erreichbare öffentliche Adresse gibt.
- Welchen einzelnen Port und welches Protokoll das Gateway annimmt und welcher Dienst dahinter antwortet.
Der nächste Schritt ist konkret: Wähle den Gateway-Host, bestätige seinen Listener von außen, und erst dann lege den Client-Eintrag auf dem Mac an, der darauf zeigt.