iPhone-App findet lokale Geräte bei aktivem VPN nicht
Zwei Tore entscheiden, ob eine iPhone-App über ein VPN einen Drucker oder Fernseher erreicht: die Freigabe für das lokale Netzwerk und die Routen des Tunnels. Prüfen Sie sie der Reihe nach.
Ihre Drucker-App zeigt eine leere Liste, die Kamera-App meldet kein Gerät gefunden, und der Cast-Button in einer Video-App dreht sich, bis er aufgibt. Das VPN-Symbol steht in der Statusleiste, das Telefon hat vollen Empfang, und Safari lädt Seiten problemlos, an der Verbindung scheint also nichts kaputt zu sein. Dann öffnen Sie die Einstellungen der App selbst und finden nichts zum Umschalten.
Genau an diese Wand bin ich mit einem Etikettendrucker in einem Heimnetz gestoßen: Der App war nie Zugriff auf das lokale Netz gewährt worden, und das Profil, das ich testete, war ein Full Tunnel, der jedes an 192.168.1.0/24 adressierte Paket verschluckte. Zwei unabhängige Tore waren geschlossen, und eines zu öffnen hätte das Symptom nicht beseitigt.
Zwei Tore stehen zwischen einer App und einem Drucker
Tor eins ist eine Datenschutzentscheidung, die dem Betriebssystem gehört und nicht der App. iOS entscheidet, ob eine App Datenverkehr an Adressen im lokalen Netz senden darf, und fragt den Nutzer beim ersten Versuch der App. Tor zwei ist die Routentabelle. Ein Paket an 192.168.1.50 verlässt das Telefon entweder über Wi-Fi in Richtung Drucker, oder es geht in den Tunnel, und diese Wahl steht im VPN-Profil.
Die beiden Tore scheitern auf unterschiedliche Weise, und genau das macht die Diagnose möglich. Eine verweigerte Berechtigung lässt den Socket-Aufruf der App scheitern, sodass die App nichts zu melden hat und auf einen generischen leeren Zustand zurückfällt. Ein Routingproblem sieht wie ein Timeout aus, weil die Pakete das Telefon verlassen haben und irgendwo auf der Gegenseite gestorben sind. Gleicher leerer Bildschirm, andere Reparatur.
Prüfen Sie den Berechtigungsstatus, bevor Sie das VPN anfassen
Öffnen Sie die Einstellungen, dann Datenschutz & Sicherheit, dann Lokales Netzwerk. Jede App, die Zugriff angefragt hat, erscheint dort mit einem Schalter. Apple hat Teile dieses Bildschirms zwischen iOS 14 und iOS 18 verschoben und umbenannt; wenn der Eintrag nicht dort ist, wo Sie ihn erwarten, tippen Sie Lokales Netzwerk in das Suchfeld der Einstellungen, statt den Baum zu durchsuchen.
Was die Leute erwischt, ist die einmalige Abfrage. iOS fragt, wenn eine App das lokale Netz zum ersten Mal berührt, und nur dann. Tippen Sie Nicht erlauben, kommt die Abfrage beim nächsten Start nicht wieder; der Schalter ist der einzige Weg zurück, und er steht anfangs aus. Eine Neuinstallation der App setzt die Entscheidung zurück, weshalb manche Troubleshooting-Threads behaupten, eine Neuinstallation habe die Erkennung repariert. Hat sie auch, indem sie die Ablehnung gelöscht hat.
Auf einem überwachten oder verwalteten iPhone ist der Schalter manchmal ausgegraut. Ein von MDM verteiltes Payload für Datenschutzeinstellungen kann den Zugriff auf das lokale Netz vorbelegen oder sperren, und ein gesperrter Schalter, der aus ist, bedeutet: Die Reparatur ist eine Richtlinienänderung und keine Änderung am Telefon. Apple dokumentiert die Abfrage und den Schalter pro App hier: support.apple.com/en-us/102229.
Prüfen Sie, was der Tunnel tatsächlich routet
Ein Full Tunnel nimmt 0.0.0.0/0 und damit jeden privaten Bereich. Pakete für 10.x, 172.16.0.0/12 und 192.168.x.x wandern zum Server, der sie meist verwirft oder in sein eigenes Subnetz übersetzt, sodass der Drucker unerreichbar bleibt, auch nachdem Sie die Berechtigung erteilt haben. Ein Split Tunnel macht das Gegenteil, aber nur für die Bereiche, die das Profil auflistet.
IKEv2-Profile, die mit Apple Configurator gebaut oder als .mobileconfig ausgeliefert werden, drücken das als Einstellung „gesamten Verkehr senden“ aus plus, im Split-Fall, einer ausdrücklichen Liste lokaler Netze, die ausgenommen werden. Client-Apps auf Basis von NEPacketTunnelProvider drücken dieselbe Entscheidung über includedRoutes aus. Beides ist in der Statusleiste nicht zu sehen, und beides überschreibt, was die App zu sehen erwartet.
So teste ich es. Öffnen Sie bei verbundenem VPN die Admin-Seite des Routers über seine LAN-Adresse in Safari. Wenn öffentliche Seiten laden, während diese Seite in einen Timeout läuft, liegt Ihr privater Bereich im Tunnel. Wenn die Seite lädt, verlässt lokaler Verkehr das Telefon weiterhin über Wi-Fi, und die Sperre sitzt woanders.
Ordnen Sie das Symptom dem Tor zu
Zwei Apps auf demselben Telefon können unterschiedlicher Meinung sein, weil die Berechtigung pro App und die Routen pro Profil vergeben werden. Vergleichen Sie, was scheitert, bevor Sie etwas ändern: Meist benennt das Muster das Tor von selbst.
| What you see | Gate | Next step |
|---|---|---|
| Device list stays empty, Local Network switch is off | Permission | Enable the switch, force-quit the app, reopen it |
| Switch is on, router page times out, public sites load | Routing | Exclude the local range in the profile, or move to a split tunnel |
| Both pass, direct IP works, discovery stays empty | Link-local multicast | Enter the device address by hand, or check profile discovery support |
| Works by IP address, never by name such as printer.local | Name resolution | Fix mDNS reachability or use the numeric address |
| Everything fails with the VPN off, on hotel Wi-Fi | Client isolation | Change network, do not change permissions |
Die mDNS-Zeile verdient eine Anmerkung. Erkennungsverkehr für Bonjour und die meisten Casting-Protokolle geht als Multicast an 224.0.0.251 und ff02::fb mit Link-Local-Gültigkeit, und ein gerouteter Tunnel transportiert ihn nicht. Deshalb kann ein Gerät eine direkte Verbindung beantworten, ohne je in einer Liste zu erscheinen.
Testen Sie den Vorgang, nicht das Symbol
Nachdem Sie den Schalter für Lokales Netzwerk umgelegt haben, beenden Sie die App erzwungen über den App-Umschalter und starten Sie sie neu. Ein laufender Prozess kann den verweigerten Zustand von vor der Änderung halten, und eine App, die weiterhin eine leere Liste liefert, sieht gleich aus, ob die Freigabe gewirkt hat oder nicht. Führen Sie dann eine konkrete Aktion aus, etwa eine Testseite drucken oder ein Video starten, statt darauf zu warten, dass sich eine Geräteliste füllt.
Halten Sie das VPN-Profil über den Vergleich hinweg konstant. Wenn die Erkennung erst nach dem Trennen funktioniert, wissen Sie, dass der Tunnel schuld ist und nicht die Berechtigung. Ändern Sie pro Versuch eine Variable, sonst sagt Ihnen der nächste Lauf nichts.
Beheben Sie es in dieser Reihenfolge
Die folgende Reihenfolge befolge ich inzwischen, weil sie ein Telefon nie in einem halb geänderten Zustand zurücklässt, in dem der nächste Test nichts aussagt.
- Prüfen Sie, ob die App unter Datenschutz & Sicherheit, Lokales Netzwerk aufgeführt ist und ihr Schalter an ist.
- Beenden Sie die App erzwungen, starten Sie sie neu und wiederholen Sie den echten Vorgang einmal.
- Öffnen Sie bei bestehender Verbindung die Router-Seite über die LAN-Adresse, um zu beweisen, ob der private Bereich getunnelt wird.
- Wird er getunnelt, bearbeiten Sie das Profil, um die lokalen Netze auszunehmen, oder bitten Sie die Person, der das Profil gehört, darum.
- Ist der Schalter ausgegraut, behandeln Sie das Gerät als verwaltet und leiten Sie die Anfrage an die Administration weiter.
Meist trifft nur einer davon zu. Wenn keiner das Ergebnis ändert, bleiben als Verdächtige das Netz selbst, etwa Access-Point-Isolation oder eine Client-Allowlist, die an Wi-Fi-Adressen gebunden ist, und die Zuordnungstabelle oben zeigt, welcher davon.