iPhone-appen finder ikke lokale enheder, mens VPN’et er tændt
To porte afgør, om en iPhone-app kan nå en printer eller et TV via en VPN: tilladelsen til Lokalt netværk og tunnelens egne ruter. Kontroller dem i rækkefølge.
Din printerapp viser en tom liste, kameraappen melder, at der ikke blev fundet nogen enhed, og cast-knappen i en videoapp drejer, indtil den giver op. VPN-ikonet sidder i statuslinjen, telefonen har fuldt signal, og Safari indlæser sider uden problemer, så intet ved forbindelsen ser ødelagt ud. Så åbner du appens egne indstillinger og finder intet at slå til.
Jeg ramte præcis denne mur med en etiketprinter på et hjemmenetværk: appen havde aldrig fået adgang til det lokale netværk, og den profil, jeg testede, var en fuld tunnel, der slugte hver pakke adresseret til 192.168.1.0/24. To uafhængige porte var lukket, og det at åbne én ville ikke have fjernet symptomet.
To porte mellem én app og én printer
Den første port er en beslutning om privatliv, som tilhører styresystemet og ikke appen. iOS afgør, om en app må sende trafik til adresser på det lokale netværk, og spørger brugeren første gang, appen prøver. Den anden port er rutetabellen. En pakke rettet mod 192.168.1.50 forlader enten telefonen via Wi-Fi mod printeren, eller den går ind i tunnelen, og det valg står i VPN-profilen.
De to porte fejler på forskellige måder, og det er netop det, der gør diagnosen mulig. En afvist tilladelse dræber appens eget socket-kald, så appen har intet at rapportere og falder tilbage til en generisk tom tilstand. Et routingproblem ligner en timeout, fordi pakkerne forlod telefonen og døde et sted på den anden side. Samme tomme skærm, anden reparation.
Læs tilladelsestilstanden, før du rører VPN’en
Åbn Indstillinger, derefter Anonymitet og sikkerhed, derefter Lokalt netværk. Hver app, der har bedt om adgang, vises der med en kontakt. Apple har flyttet og omdøbt dele af denne skærm mellem iOS 14 og iOS 18, så hvis posten ikke er, hvor du forventer, så skriv Lokalt netværk i indstillingernes søgefelt i stedet for at lede gennem træet.
Det, der fanger folk, er den enkeltstående forespørgsel. iOS spørger, når en app første gang rører det lokale netværk, og kun da. Tryk på Tillad ikke, og forespørgslen vender ikke tilbage ved næste start; kontakten er den eneste vej tilbage, og den starter slukket. Geninstallation af appen nulstiller beslutningen, og derfor hævder nogle fejlfindings-tråde, at en geninstallation løste opdagelsen. Det gjorde den, ved at slette afvisningen.
På en iPhone, der er overvåget eller administreret, er kontakten nogle gange grå. En nyttelast med privatlivsindstillinger, der sendes ud via MDM, kan forudindstille eller låse adgangen til det lokale netværk, og en låst kontakt, der er slukket, betyder, at reparationen er en politikændring og ikke en telefoniændring. Apple dokumenterer forespørgslen og kontakten per app her: support.apple.com/en-us/102229.
Kontroller, hvad tunnelen faktisk router
En fuld tunnel tager 0.0.0.0/0 og dermed hvert privat område. Pakker til 10.x, 172.16.0.0/12 og 192.168.x.x rejser til serveren, som normalt kasserer dem eller oversætter dem til sit eget subnet, så printeren er uopnåelig, selv efter du giver tilladelsen. En delt tunnel gør det modsatte, men kun for de områder, profilen oplister.
IKEv2-profiler, der bygges med Apple Configurator eller leveres som .mobileconfig, udtrykker det som en indstilling om at sende al trafik plus, når den er delt, en eksplicit liste over lokale netværk, der skal udelades. Klientapps bygget på NEPacketTunnelProvider udtrykker den samme beslutning gennem includedRoutes. Ingen af dem er synlige fra statuslinjen, og begge tilsidesætter det, appen forventer at se.
Her er den test, jeg bruger. Med VPN’en forbundet åbner du routerens admin-side på dens LAN-adresse i Safari. Hvis offentlige sites indlæses, mens den side løber ud i tid, er dit private område inde i tunnelen. Hvis siden indlæses, forlader lokal trafik stadig telefonen via Wi-Fi, og blokeringen er et andet sted.
Knyt symptomet til porten
To apps på samme telefon kan være uenige, fordi tilladelse gives per app, mens ruter gives per profil. Sammenlign, hvad der fejler, før du ændrer noget: mønsteret navngiver som regel porten af sig selv.
| 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 |
mDNS-rækken fortjener en bemærkning. Opdagelsestrafik for Bonjour og de fleste cast-protokoller sendes som multicast til 224.0.0.251 og ff02::fb med link-local rækkevidde, og en routet tunnel bærer den ikke. Derfor kan en enhed svare på en direkte forbindelse uden nogensinde at dukke op på en liste.
Test handlingen, ikke ikonet
Når du har slået kontakten Lokalt netværk til, skal du tvinge appen til at lukke fra appskifteren og starte den igen. En kørende proces kan holde den afviste tilstand fra før ændringen, og en app, der bliver ved med at returnere en tom liste, ser ens ud, uanset om tilladelsen virkede. Kør derefter en konkret handling, for eksempel at printe en testside eller starte en video, i stedet for at vente på, at en enhedsliste bliver fyldt.
Hold VPN-profilen fast gennem sammenligningen. Hvis opdagelsen først begynder at virke, efter du afbryder forbindelsen, har du lært, at tunnelen er skyldig, ikke tilladelsen. Skift én variabel per forsøg, ellers fortæller næste kørsel dig intet.
Ret det i denne rækkefølge
Rækkefølgen nedenfor er den, jeg nu følger, fordi den aldrig efterlader en telefon i en halvt ændret tilstand, hvor den næste test er ulæselig.
- Bekræft, at appen står under Anonymitet og sikkerhed, Lokalt netværk, og at dens kontakt er slået til.
- Tving appen til at lukke, start den igen, og prøv den rigtige handling én gang.
- Åbn routerens side på LAN-adressen, mens du er forbundet, for at bevise, om det private område går gennem tunnelen.
- Hvis det gør, skal du redigere profilen, så lokale netværk udelades, eller bede den, der ejer profilen, om at gøre det.
- Hvis kontakten er grå, skal du behandle enheden som administreret og sende anmodningen til administratoren.
Normalt gælder kun én af dem. Hvis ingen af dem ændrer resultatet, er de resterende mistænkte netværket selv, for eksempel isolering på accesspunktet eller en klienttilladelsesliste bundet til Wi-Fi-adresser, og tabellen ovenfor peger på hvilken.