iPhone-app vindt geen lokale apparaten terwijl het VPN aan staat
Twee barrières bepalen of een iPhone-app via een VPN een printer of tv bereikt: de toestemming voor het lokale netwerk en de routes van de tunnel zelf. Controleer ze in deze volgorde.
Je printer-app toont een lege lijst, de camera-app meldt dat er geen apparaat is gevonden, en de cast-knop in een video-app draait rond tot hij het opgeeft. Het VPN-pictogram staat in de statusbalk, de telefoon heeft volle ontvangst en Safari laadt pagina's prima, dus aan de verbinding lijkt niets kapot. Dan open je de eigen instellingen van de app en vind je niets om om te zetten.
Precies tegen deze muur liep ik met een labelprinter op een thuisnetwerk: de app had nooit toegang tot het lokale netwerk gekregen, en het profiel dat ik testte was een full tunnel die elk pakket voor 192.168.1.0/24 opslokte. Twee onafhankelijke barrières stonden dicht, en er één openen zou het symptoom niet hebben verholpen.
Twee barrières tussen één app en één printer
Barrière één is een privacybeslissing die bij het besturingssysteem hoort en niet bij de app. iOS bepaalt of een app verkeer mag sturen naar adressen op het lokale netwerk, en het vraagt de gebruiker de eerste keer dat de app het probeert. Barrière twee is de routetabel. Een pakket voor 192.168.1.50 verlaat de telefoon via Wi-Fi richting printer, of het gaat de tunnel in, en die keuze staat in het VPN-profiel.
De twee barrières falen op verschillende manieren, en dat maakt de diagnose mogelijk. Een geweigerde toestemming laat de socket-aanroep van de app zelf stuklopen, zodat de app niets te melden heeft en terugvalt op een algemene lege toestand. Een routeringsprobleem ziet eruit als een time-out, omdat de pakketten de telefoon hebben verlaten en ergens aan de andere kant zijn gestorven. Hetzelfde lege scherm, een andere reparatie.
Lees de toestemmingstoestand voordat je het VPN aanraakt
Open Instellingen, dan Privacy en beveiliging, dan Lokaal netwerk. Elke app die toegang heeft aangevraagd staat daar met een schakelaar. Apple heeft stukken van dit scherm tussen iOS 14 en iOS 18 verplaatst en hernoemd, dus als de vermelding niet staat waar je hem verwacht, typ dan Lokaal netwerk in het zoekveld van Instellingen in plaats van de boom af te zoeken.
Het punt dat mensen vangt is de eenmalige vraag. iOS vraagt het wanneer een app het lokale netwerk voor het eerst aanraakt, en alleen dan. Tik je op Sta niet toe, dan komt de vraag bij de volgende start niet terug; de schakelaar is de enige weg terug, en die staat uit. De app opnieuw installeren zet de beslissing terug, daarom beweren sommige troubleshooting-threads dat een herinstallatie de ontdekking heeft gerepareerd. Dat deed het ook, door de weigering te wissen.
Op een gecontroleerde of beheerde iPhone is de schakelaar soms grijs. Een privacyvoorkeuren-payload die door MDM wordt gepusht kan toegang tot het lokale netwerk vooraf instellen of vergrendelen, en een vergrendelde schakelaar die uit staat betekent dat de reparatie een beleidswijziging is en geen wijziging aan de telefoon. Apple documenteert de vraag en de schakelaar per app hier: support.apple.com/en-us/102229.
Controleer wat de tunnel echt routeert
Een full tunnel neemt 0.0.0.0/0 en daarmee elk privébereik. Pakketten voor 10.x, 172.16.0.0/12 en 192.168.x.x reizen naar de server, die ze meestal laat vallen of naar zijn eigen subnet vertaalt, zodat de printer onbereikbaar blijft ook nadat je toestemming hebt gegeven. Een split tunnel doet het omgekeerde, maar alleen voor de bereiken die het profiel noemt.
IKEv2-profielen die met Apple Configurator zijn gebouwd of als .mobileconfig worden geleverd, drukken dat uit als een instelling voor al het verkeer plus, in splitmodus, een expliciete lijst met lokale netwerken die moeten worden uitgesloten. Client-apps op basis van NEPacketTunnelProvider drukken dezelfde beslissing uit via includedRoutes. Geen van beide is zichtbaar in de statusbalk, en beide overschrijven wat de app verwacht te zien.
Zo lees ik het. Open met het VPN verbonden de beheerderspagina van de router via zijn LAN-adres in Safari. Als openbare sites laden terwijl die pagina een time-out geeft, zit je privébereik in de tunnel. Als de pagina laadt, verlaat lokaal verkeer de telefoon nog via Wi-Fi en zit de blokkade ergens anders.
Koppel het symptoom aan de barrière
Twee apps op dezelfde telefoon kunnen het oneens zijn, omdat toestemming per app wordt gegeven en routes per profiel. Vergelijk wat er faalt voordat je iets verandert: het patroon noemt de barrière meestal zelf.
| 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 |
De mDNS-rij verdient een opmerking. Ontdekkingsverkeer voor Bonjour en de meeste cast-protocollen gaat als multicast naar 224.0.0.251 en ff02::fb met link-local bereik, en een gerouteerde tunnel vervoert dat niet. Daarom kan een apparaat een directe verbinding beantwoorden zonder ooit in een lijst te verschijnen.
Test de handeling, niet het pictogram
Nadat je de schakelaar Lokaal netwerk hebt omgezet, sluit je de app geforceerd via de app-switcher en start je hem opnieuw. Een draaiend proces kan de geweigerde toestand van vóór de wijziging vasthouden, en een app die een lege lijst blijft teruggeven ziet er hetzelfde uit of de toestemming nu werkte of niet. Voer daarna één concrete actie uit, zoals een testpagina printen of een video starten, in plaats van te wachten tot een apparatenlijst zich vult.
Houd het VPN-profiel vast tijdens de vergelijking. Als ontdekking pas werkt nadat je de verbinding verbreekt, heb je geleerd dat de tunnel schuldig is en niet de toestemming. Wijzig één variabele per poging, anders zegt de volgende ronde je niets.
Los het in deze volgorde op
De volgorde hieronder volg ik nu, omdat die een telefoon nooit in een half gewijzigde toestand achterlaat waarin de volgende test onleesbaar is.
- Controleer of de app onder Privacy en beveiliging, Lokaal netwerk staat en of de schakelaar aan is.
- Sluit de app geforceerd, start hem opnieuw en herhaal de echte handeling één keer.
- Open de routerpagina via het LAN-adres terwijl je verbonden bent, om te bewijzen of het privébereik in de tunnel zit.
- Zit het in de tunnel, pas het profiel aan om de lokale netwerken uit te sluiten, of vraag degene die het profiel beheert dat te doen.
- Is de schakelaar grijs, behandel het apparaat dan als beheerd en stuur het verzoek naar de beheerder.
Meestal geldt er maar één. Als geen enkele het resultaat verandert, zijn de overgebleven verdachten het netwerk zelf, zoals access point-isolatie of een client-allowlist die aan Wi-Fi-adressen is gekoppeld, en de koppelingstabel hierboven wijst aan welke.