Mehrere WireGuard-Tunnel unter macOS: Optionen, Routing und DNS

Du kannst mehrere WireGuard-Tunnel auf einem Mac nutzen, mit einem Client oder einem Kommandozeilen-Setup, das sie unterstützt. Damit beide entfernten Netze funktionieren, muss der Client beide Tunnel aktiv halten, macOS jedes Ziel über die richtige Schnittstelle schicken und DNS jeden Namen korrekt auflösen.

Diese Anleitung behandelt IPv4-Netze.

Zwei „Verbunden“-Anzeigen reichen nicht. Prüfe den Zugriff auf einen echten Dienst in jedem Netz, während beide Tunnel aktiv sind.

Stand der offiziellen App am 6. Oktober 2026: Die veröffentlichte WireGuard-App für macOS, die wir bei unserer Upstream-Prüfung ermittelt haben, ist Version 1.0.16, mit der Regel, dass nur ein Tunnel aktiv sein kann. Multi-Tunnel-Patches wurden vorgeschlagen, aber unsere Prüfung fand weder einen Upstream-Merge noch eine veröffentlichte Version, die sie enthält. Das ist eine Einschränkung dieser App-Version, keine Ein-Tunnel-Regel des WireGuard-Protokolls. Siehe den Quellcode der offiziellen App und ihren Eintrag im App Store für macOS.

Wähle, wie du beide Netze erreichst

Mehrere [Peer]-Abschnitte in einer WireGuard-Konfiguration sind etwas anderes als zwei unabhängige Tunnel-Schnittstellen. Konfigurationen zusammenzulegen ist keine Abkürzung: Eine Schnittstelle hat genau einen privaten Schlüssel, und jeder entfernte Peer muss so konfiguriert sein, dass er ihn erkennt.

Für den Weg über die Kommandozeile beginne mit den Installationsanleitungen von WireGuard, dem Handbuch zu wg-quick und der Darwin-Implementierung. Die Kommandozeilen-Option ist nach ihrer Upstream-Dokumentation und ihrem Quellcode beschrieben; das validierte Paart-Setup belegt nicht das Verhalten einer separaten Kommandozeilen-Installation.

Zwei Routen vorbereiten, die nebeneinander bestehen können

Was AllowedIPs wirklich tut

Wenn du Datenverkehr sendest, fallen zwei Entscheidungen:

1. Das Betriebssystem wählt für die Zieladresse eine Route und eine Schnittstelle.
2. Auf einer WireGuard-Schnittstelle bestimmt AllowedIPs, welcher Peer dieses Ziel erhält. Es begrenzt außerdem, welche Quelladressen dieses Peers bei eingehendem Verkehr angenommen werden.

Clients legen aus AllowedIPs üblicherweise Routen im Betriebssystem an; wg selbst richtet diese Routen nicht ein. Der Unterschied zählt, wenn du Clients vergleichst oder eigenes Routing verwendest. Siehe die Erklärung zum Cryptokey-Routing von WireGuard.

Für ein gewöhnliches Split Tunneling nimm die entfernten Ziele auf, die du brauchst, statt jeder Adresse im Internet. Halte die Konfiguration im Einklang mit den Vorgaben des entfernten Administrators.

Ein einfaches Beispiel mit zwei Standorten

Das sind fiktive Netze und Namen, keine vollständige Konfiguration:

Der betreffende Peer hätte in A AllowedIPs = 10.20.0.0/24, in B AllowedIPs = 10.30.0.0/24. Beide DNS-Server liegen in ihren jeweils gerouteten Bereichen.

Prüfe auch die eigenen Adressen und Masken der Schnittstellen. So vermeiden getrennt zugewiesene Tunneladressen wie 10.200.1.2/32 und 10.200.2.2/32, dass dasselbe verbundene Subnetz über beide Schnittstellen eingeführt wird. Verwende die Adressen, die jeder Administrator zugewiesen hat, statt sie willkürlich zu ändern.

Jeder öffentliche WireGuard-Endpunkt muss über eine funktionierende darunterliegende Verbindung erreichbar bleiben. Eine Route, die den verschlüsselten Transport des Endpunkts selbst zurück in einen ungeeigneten Tunnel schickt, kann Handshakes verhindern.

Überschneidungen und Standardrouten

Wenn beide Standorte einen Server unter 192.168.1.10 haben, kann eine gewöhnliche, zielbasierte Routensuche nicht erkennen, welchen Standort du meinst. Verschiedene DNS-Namen, die dieselbe Adresse liefern, lösen diese Mehrdeutigkeit nicht.

Prüfe auch Konflikte mit deinem lokalen LAN. Ein entferntes 192.168.50.0/24 kollidiert mit dem lokalen Netz in unserem Beispiel. Spezifischere Routen können einzelne Ziele lenken, aber sie ermöglichen keinen gewöhnlichen, gleichzeitigen Zugriff auf zwei verschiedene Maschinen mit identischer Adresse. Neu nummerieren, Adressübersetzung an einem Gateway oder eine isolierte Umgebung pro Standort sind Optionen auf Ebene der Architektur.

0.0.0.0/0 deckt alle IPv4-Ziele ab. Zwei Full Tunnels konkurrieren um diese breite Abdeckung. Geh nicht davon aus, dass immer der zuletzt aktivierte Tunnel gewinnt: installierte Routen, ihr Geltungsbereich und die Regeln des Clients beeinflussen das Ergebnis. Eine spezifischere Route hat im jeweiligen Routing-Kontext in der Regel Vorrang; prüfe den tatsächlichen Weg.

DNS unabhängig vom Routing zum Laufen bringen

Split Tunneling wählt den Weg für eine IP-Adresse. Split DNS wählt den Resolver für einen Namen. Oft brauchst du beides.

In unserem Beispiel sollen Namen unter a.example.com 10.20.0.53 verwenden, Namen unter b.example.com 10.30.0.53, und alle anderen Namen den passenden lokalen oder öffentlichen Resolver behalten. Beide entfernten DNS-Server müssen selbst erreichbar sein.

Eine Suchdomain und eine Domain zur Resolver-Auswahl sind zwei verschiedene Dinge. Eine Suchdomain kann einen kurzen Namen wie server zu server.a.example.com ergänzen; sie beweist für sich allein nicht, dass Anfragen für diese Domain an den DNS-Server von A gehen. Verwende vollqualifizierte Namen (FQDN), wenn du zwei Standorte prüfst.

Der aktuelle Code der Netzwerkeinstellungen der offiziellen App setzt einen DNS-Abgleich für alle Domains, sobald DNS-Server konfiguriert sind. Das Darwin-Skript von wg-quick ändert mit networksetup die DNS-Einstellungen des Netzwerkdienstes und stellt beim Aufräumen die gesicherten Einstellungen wieder her. Bei keinem der beiden Mechanismen solltest du annehmen, dass sie für zwei Tunnel ein unabhängiges DNS pro Domain einrichten, nur weil jede Konfiguration eine DNS-Zeile hat. Zwei Instanzen, die gemeinsame Einstellungen ändern, können sich außerdem stören, wenn eine stoppt. Prüfe das Verhalten deines Clients und der installierten Version.

Unter macOS zeigt scutil --dns die konfigurierten Resolver, einschließlich schnittstellengebundener (scoped) und ergänzender (supplemental) Einträge. Lies ihre Domains, Server und ihren Schnittstellenbereich; der zuerst aufgeführte Resolver ist nicht unbedingt derjenige, der für jede Anfrage verwendet wird. Anwendungen mit eigenem DNS-Mechanismus können sich anders verhalten als der System-Resolver.

Prüfen, ob beide Zugriffe wirklich funktionieren

Verwende einen Dienst, von dem du weißt, dass er an jedem Standort verfügbar ist. Die Befehle unten zeigen die Prüfungen für das fiktive Beispiel; ersetze Adressen, Namen und Ports durch deine eigenen. Sie untersuchen das Routing und versuchen Verbindungen; sie aktivieren oder ändern kein VPN.

1. Mit jedem Tunnel allein eine Ausgangslage festhalten

Mit A allein aktiv prüfst du seine Route und einen bekannten Dienst:

route -n get 10.20.0.20
nc -vz -G 5 10.20.0.20 443

Wiederhole das mit B allein:

route -n get 10.30.0.20
nc -vz -G 5 10.30.0.20 443

Lies in jedem Routing-Ergebnis die Schnittstelle und ermittle, zu welchem Tunnel sie gehört. Eine Schnittstelle namens utun kann zu einem anderen VPN gehören; ihr Name allein ist kein Beweis.

Eine erfolgreiche TCP-Verbindung zeigt, dass der Port erreichbar ist, nicht dass die Anwendung in Ordnung ist. Öffne auch den eigentlichen Dienst. Ping ist optional: Ein Host kann ICMP blockieren, während sein Dienst funktioniert.

2. Mit A und B gleichzeitig aktiv wiederholen

Führe die Routen- und Dienstprüfungen erneut aus, ohne einen der beiden Tunnel abzuschalten. Halte zu jedem Standort eine echte Sitzung offen und bestätige, dass beide nutzbar bleiben.

Prüfe für jeden Peer mit der Diagnose des Clients einen aktuellen Handshake und empfangenen Verkehr. Erzeuge Verkehr, bevor du einen alten Handshake deutest: Ein untätiger Tunnel muss nicht ständig Pakete austauschen. Wo Kommandozeilen-Schnittstellen von WireGuard für wg sichtbar sind, können diese Abfragen helfen:

sudo wg show all latest-handshakes
sudo wg show all transfer

Sie sind kein universeller Weg, von einer App verwaltete Network-Extension-Tunnel zu untersuchen. Eine in wg fehlende Schnittstelle beweist nicht, dass eine solche App getrennt ist.

3. Namen über macOS und die Anwendung prüfen

scutil --dns
dscacheutil -q host -a name server.a.example.com
dscacheutil -q host -a name server.b.example.com

Vergleiche die zurückgegebenen Adressen mit den vorgesehenen Standorten. Öffne dann jeden Dienst über seinen vollständigen Hostnamen. Das prüft auch den tatsächlichen Auflösungsweg der Anwendung und, bei HTTPS, die Zertifikatsprüfung. Korrektes DNS repariert kein ungültiges Zertifikat.

dig @10.20.0.53 server.a.example.com kann den DNS-Server von A direkt testen. Das beweist nicht, dass macOS oder dein Browser diesen Resolver gewählt hat. Zwischengespeicherte Antworten können ein Resolver-Problem außerdem verdecken; bestätige das Verhalten mit bekannten Einträgen und den Anwendungen, auf die du dich tatsächlich verlässt.

4. Lokalen Zugriff, Internetzugriff und das Stoppen eines Tunnels prüfen

Notiere erwartete und beobachtete Ergebnisse statt nur „verbunden“. Verwende die IPv4-Adressen und Namen, die für dieses Setup konfiguriert sind.

Wenn die zweite Verbindung etwas kaputt macht

Für einen Tunnel, der nie einen Handshake zustande bringt, siehe Wenn der Tunnel nicht zustande kommt. Zum Zusammenspiel von DNS und Routen siehe DNS, Routing und Split Tunneling.

Paart für dieses Setup verwenden

Paart Client ist eine grafische Option, um getrennte WireGuard-Verbindungen auf einem Mac aktiv zu halten, wenn ihre Routen nebeneinander bestehen können. Gleichzeitige Verbindungen gibt es mit Kostenlos wie mit Pro. Erweitertes Networking gibt es auf einer kostenlosen Verbindung deiner Wahl und mit Pro auf jeder Verbindung.

Für die Namen der einzelnen Standorte erklärt der Leitfaden zu Split DNS, wie du die internen Namen und ihren Resolver festlegst. Das sind Paart-spezifische Anleitungen.

Es gibt betriebliche Grenzen. Die Gleichzeitigkeit beruht auf beobachtetem Verhalten von macOS, nicht auf einer Garantie von Apple. Paart meldet Überschneidungen, die es beobachtet; es entscheidet nicht, welche konkurrierende Route gewinnen soll. Im validierten Paart-Setup auf dem Mac hat das Stoppen einer Verbindung die anderen unterbrochen, die danach von selbst wieder aufgenommen wurden. Plane diese Unterbrechung in deine Arbeitsweise ein.

Auf iPhone und iPad unterstützt Paart eine aktive Verbindung zur selben Zeit. Übertrage das Mac-Setup nicht auf diese Geräte.

Technische Quellen

• WireGuard: Schnittstellen und Cryptokey-Routing — Protokoll und Peer-Auswahl.
• Referenz zu wg — AllowedIPs und Abfragen zur Laufzeit.
• Referenz zu wg-quick und Darwin-Quellcode — Einrichten der Routen und DNS-Behandlung unter macOS. Der Darwin-Quellcode ist die plattformspezifische Referenz.
• Netzwerkeinstellungen von wireguard-apple — Routen und DNS-Einstellungen im offiziellen Client.
• Verlauf von wireguard-apple und Vorschlag für Multi-Tunnel-Patches — einen Vorschlag von einem Upstream-Merge und einer veröffentlichten App unterscheiden.

Quellenprüfung: 6. Oktober 2026. Mehrere aktive Tunnel, das Nebeneinander der Routen, DNS sowie das Verhalten beim Stoppen und Wiederaufnehmen wurden in den vorangegangenen Paart-Abnahmetests auf dem Mac validiert. Die Kommandozeilen-Option ist nach den Upstream-Quellen dokumentiert und nicht als Teil dieser Tests dargestellt.