AirDrop fehlt bei aktivem VPN? Prüfen Sie das lokale Routing

AirDrop funktioniert, dann verbindet sich das VPN, und der andere Mac oder das iPhone verschwindet aus dem Freigabeblatt. Im VPN-Protokoll steht nichts über die Erkennung, weil der Fehler meist die lokale Erreichbarkeit betrifft und nicht die Kryptografie. Apples Supportseite räumt ein, dass eine VPN-Konfiguration, die das lokale Netzwerk einschränkt, Continuity und AirDrop stören kann; das ist ein nützlicher Hinweis und keine Diagnose. Beginnen Sie mit den billigen Prüfungen, lesen Sie dann die Routentabelle, und behandeln Sie den Schalter für lokalen Zugriff als Entscheidung über Ihre Privatsphäre statt als Voreinstellung, die man einfach umlegt.

Was bricht, bevor der Tunnel überhaupt beteiligt ist

Beide Geräte brauchen aktives Wi-Fi oder Bluetooth, AirDrop muss innerhalb seines Empfangsfensters von Kontakten oder von allen empfangen, und die beiden Konten müssen füreinander auffindbar sein. Den Empfänger zehn Minuten lang auf alle zu stellen ist ein legitimes Experiment: erscheint das andere Gerät dort, waren die Einstellungen das Problem, und der Tunnel ist unschuldig. Testen Sie mit einem bekannten Empfänger, statt nach dem zu urteilen, was das Freigabeblatt anbietet.

Ein Browser, der Seiten lädt, beweist, dass der Internetweg funktioniert, nicht dass die lokale Erkennung funktioniert. Lassen Sie beide Geräte und den Standort unverändert, schalten Sie dann das VPN an und aus, und notieren Sie, ob das andere Gerät nur verschwindet, solange der Tunnel steht. Stirbt die Erkennung mit dem Tunnel und kehrt ohne ihn zurück, ist der Tunnel die Variable, und der Rest dieser Liste gilt. Scheitert es in beiden Zuständen, brauchen die Voraussetzungen einen weiteren Durchgang, bevor irgendeine Netzwerkrichtlinie geändert wird.

Das Freigabeblatt leert sich, wenn sich die Standardroute verschiebt

Ein Full-Tunnel-Client installiert meist eine Standardroute durch den Tunnel plus zwei Halbrouten, die die meisten Ziele einfangen. Ein lokales Subnetz überlebt diese Anordnung nur mit einer spezifischeren Route; sonst verschwindet es im Tunnel. AirDrop selbst läuft über die AWDL-Peer-Schnittstelle, daher kann ein Client, der lokale Schnittstellen filtert oder aggressiv routet, stören, während der Internetweg perfekt bleibt. Vier Befehle decken die Schnittstelle, die Routen, die aktive Verbindung und den Paketfilter ab.

ifconfig awdl0 | grep -E "status|inet"
netstat -rn | grep -E '^default|^0/1|^128.0/1|awdl'
scutil --nc list
sudo pfctl -s rules | head -40

Lesen Sie zuerst die Standardzeile: zeigt sie auf eine utun-Schnittstelle und deckt keine spezifischere Route Ihr Subnetz ab, geht lokaler Verkehr in den Tunnel, und die Wahrnehmung verschwindet mit ihm. Das Paar 0/1 und 128.0/1 ist eine verbreitete Full-Tunnel-Form, weil diese Routen die echte Standardroute schlagen, ohne sie zu ersetzen. Eine awdl0-Zeile mit aktivem Status und einer Adresse schließt aus, dass die Peer-Schnittstelle ausgefallen ist. Wenn alle drei normal aussehen, kommt die Einschränkung aus der Client-Richtlinie oder einem Filter auf dem Host und nicht aus der Routentabelle.

Eine Form verdient Erwähnung, weil sie Leute in Gastnetzwerken erwischt, und es sind nicht die Halbrouten. DHCP installiert die gerade zugewiesene Adresse als On-Link-Route, und dieser Eintrag ist spezifischer als jede der beiden Hälften, sodass ein Gast-Subnetz den Tunnel genauso übersteht wie ein privates. Was es entfernt, ist Richtlinie und nicht Routing: eine Voreinstellung, die das lokale Netzwerk blockiert und eine Verwerfungsregel installiert, ein Host-Filter, der das Subnetz verwirft, oder die macOS-Berechtigung für lokales Netzwerk für den Client. Eine normal aussehende Tabelle mit totem Freigabeblatt ist daher die Signatur des nächsten Abschnitts und nicht der Routenform.

Ein verwalteter Mac bietet den Schalter für lokalen Zugriff vielleicht nicht an

Viele Clients bieten eine Voreinstellung, die lokalen Netzwerkzugriff erlaubt, solange der Tunnel steht, aber diese Voreinstellung wird vom Client und vom Verwaltungsprofil durchgesetzt, sodass sie auf einem verwalteten Mac gesperrt, verborgen oder überschrieben sein kann. Eine Host-Firewall-Regel oder ein Sicherheitsagent kann den Peer-Verkehr unabhängig davon blockieren, was der VPN-Client anbietet. Suchen Sie den Schalter, bevor Sie schließen, dass er nichts bewirkt. Dieser Schalter liegt in den eigenen Voreinstellungen des Clients und nicht in den macOS-Netzwerkeinstellungen, weshalb ein Client, dessen Fenster ihn nicht zeigt, meist von einem Verwaltungsprofil gesteuert wird.

Die Verwaltung zu entfernen oder jeden Filter abzuschalten, damit ein Empfänger erscheint, tauscht eine kontrollierte Konfiguration gegen eine unbekannte. Schalten Sie die Option für lokalen Zugriff nur an, wenn sie zu der Richtlinie passt, unter der Sie arbeiten, und lassen Sie sie in einem Gastnetzwerk aus, in dem lokale Erkennung nie gewollt war.

Beweisen Sie es mit einer Datei, nicht mit einem Symbol

Senden Sie nach einer Änderung an Routing oder Richtlinie eine echte Datei an den vorgesehenen Empfänger und bestätigen Sie, dass die Übertragung abgeschlossen wird. Ein Name im Blatt ist Erkennung, und die Rückkehr der Erkennung ist nicht dasselbe wie eine beendete Übertragung.

Erscheint das Gerät weiterhin nicht, vergleichen Sie ein zweites Gerätepaar im selben Netzwerk, um ein Host-Problem von einem netzwerkweiten zu trennen. Dieser Vergleich ist schneller als das Durchschalten der VPN-Optionen und liefert eine Tatsache für das Ticket. Notieren Sie die Standardschnittstelle, die Routenform und den Zustand des Schalters für lokalen Zugriff, solange der Fehler reproduzierbar ist. Sonst wiederholt die nächste Person alle vier Prüfungen von vorn.