iPhone-appen finner ikke lokale enheter mens VPN-en er på

Skriverappen din viser en tom liste, kameraappen melder at ingen enhet ble funnet, og cast-knappen i en videoapp spinner til den gir opp. VPN-ikonet sitter i statuslinjen, telefonen har full dekning og Safari laster sider uten problem, så ingenting ved tilkoblingen ser ødelagt ut. Så åpner du appens egne innstillinger og finner ingenting å slå på.

Jeg traff nøyaktig denne veggen med en etikettskriver på et hjemmenettverk: appen hadde aldri fått tilgang til det lokale nettverket, og profilen jeg testet var en full tunnel som slukte hver pakke adressert til 192.168.1.0/24. To uavhengige porter var stengt, og å åpne én ville ikke ha fjernet symptomet.

To porter mellom én app og én skriver

Den første porten er et personvernvedtak som tilhører operativsystemet og ikke appen. iOS avgjør om en app får sende trafikk til adresser på det lokale nettverket, og spør brukeren første gang appen prøver. Den andre porten er rutingtabellen. En pakke rettet mot 192.168.1.50 forlater enten telefonen via Wi-Fi mot skriveren, eller den går inn i tunnelen, og det valget står i VPN-profilen.

De to portene feiler på ulike måter, og det er nettopp det som gjør diagnosen mulig. En avslått tillatelse dreper appens eget socket-kall, så appen har ingenting å rapportere og faller tilbake til en generisk tom tilstand. Et rutingproblem ser ut som en timeout, fordi pakkene forlot telefonen og døde et sted på den andre siden. Samme tomme skjerm, annen reparasjon.

Les tillatelsestilstanden før du rører VPN-en

Åpne Innstillinger, deretter Personvern og sikkerhet, deretter Lokalt nettverk. Hver app som har bedt om tilgang vises der med en bryter. Apple har flyttet og gitt nye navn til deler av denne skjermen mellom iOS 14 og iOS 18, så hvis oppføringen ikke er der du forventer, skriver du Lokalt nettverk i søkefeltet i innstillingene i stedet for å lete gjennom treet.

Det som fanger folk er engangsforespørselen. iOS spør når en app først berører det lokale nettverket, og bare da. Trykk Ikke tillat, og forespørselen kommer ikke tilbake ved neste start; bryteren er den eneste veien tilbake, og den starter av. Å installere appen på nytt nullstiller vedtaket, og derfor hevder noen feilsøkingstråder at en reinstallasjon fikset oppdagelsen. Det gjorde den, ved å slette avslaget.

På en iPhone som er overvåket eller administrert er bryteren noen ganger grå. En nyttelast med personverninnstillinger som sendes ut via MDM kan forhåndsinnstille eller låse tilgangen til det lokale nettverket, og en låst bryter som er av betyr at reparasjonen er en policyendring og ikke en telefoniendring. Apple dokumenterer forespørselen og bryteren per app her: support.apple.com/en-us/102229.

Kontroller hva tunnelen faktisk ruter

En full tunnel tar 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 reiser til serveren, som vanligvis forkaster dem eller oversetter dem til sitt eget subnett, så skriveren er utilgjengelig selv etter at du gir tillatelsen. En delt tunnel gjør det motsatte, men bare for områdene profilen lister opp.

IKEv2-profiler som bygges med Apple Configurator eller leveres som .mobileconfig uttrykker dette som en innstilling om å sende all trafikk pluss, når den er delt, en eksplisitt liste over lokale nettverk som skal utelates. Klientapper bygget på NEPacketTunnelProvider uttrykker samme vedtak gjennom includedRoutes. Ingen av dem er synlige fra statuslinjen, og begge overstyrer det appen forventer å se.

Her er testen jeg bruker. Med VPN-en tilkoblet åpner du admin-siden til ruteren på LAN-adressen i Safari. Hvis offentlige nettsteder lastes mens den siden får timeout, ligger ditt private område inne i tunnelen. Hvis siden lastes, forlater lokal trafikk fortsatt telefonen via Wi-Fi, og blokkeringen er et annet sted.

Knytt symptomet til porten

To apper på samme telefon kan være uenige, fordi tillatelse gis per app mens ruter gis per profil. Sammenlign hva som feiler før du endrer noe: mønsteret navngir vanligvis porten av seg selv.

mDNS-raden fortjener en kommentar. Oppdagelsestrafikk for Bonjour og de fleste cast-protokoller sendes som multicast til 224.0.0.251 og ff02::fb med link-local rekkevidde, og en rutet tunnel bærer den ikke. Derfor kan en enhet svare på en direkte tilkobling uten å noen gang dukke opp i en liste.

Test handlingen, ikke ikonet

Etter at du har slått om bryteren for Lokalt nettverk, tvinger du appen til å lukkes fra appbytteren og starter den igjen. En kjørende prosess kan holde på den avslåtte tilstanden fra før endringen, og en app som fortsetter å returnere en tom liste ser lik ut enten tillatelsen virket eller ikke. Kjør deretter én konkret handling, som å skrive ut en testside eller starte en video, i stedet for å vente på at en enhetsliste skal fylles.

Hold VPN-profilen fast gjennom sammenligningen. Hvis oppdagelsen først begynner å virke etter at du kobler fra, har du lært at tunnelen er skyldig, ikke tillatelsen. Endre én variabel per forsøk, ellers forteller neste kjøring deg ingenting.

Fiks det i denne rekkefølgen

Rekkefølgen nedenfor er den jeg følger nå, fordi den aldri etterlater en telefon i en halvendret tilstand der neste test er uleselig.

1. Bekreft at appen står under Personvern og sikkerhet, Lokalt nettverk, og at bryteren er på.
2. Tving appen til å lukkes, start den igjen, og prøv den virkelige handlingen én gang.
3. Åpne ruteren sin side på LAN-adressen mens du er tilkoblet, for å bevise om det private området går gjennom tunnelen.
4. Hvis det gjør det, redigerer du profilen så lokale nettverk utelates, eller ber den som eier profilen om å gjøre det.
5. Hvis bryteren er grå, behandler du enheten som administrert og sender forespørselen til administratoren.

Vanligvis gjelder bare én av dem. Hvis ingen endrer resultatet, er de gjenværende mistenkte nettverket selv, for eksempel isolasjon på tilgangspunktet eller en klienttillatelsesliste knyttet til Wi-Fi-adresser, og tabellen ovenfor peker på hvilken.