iPhone-appen finn ikkje lokale einingar medan VPN-en er på
To portar avgjer om ein iPhone-app kan nå ein skrivar eller TV via ein VPN: løyvet for Lokalt nettverk og rutene til tunnelen sjølv. Kontroller dei i rekkjefølgje.
Skrivarappen din viser ei tom liste, kameraappen melder at ingen eining vart funnen, og cast-knappen i ein videoapp snurrar til han gir opp. VPN-ikonet sit i statuslinja, telefonen har full dekning og Safari lastar sider utan problem, så ingenting ved sambandet ser øydelagt ut. Så opnar du appens eigne innstillingar og finn ingenting å slå på.
Eg trefte nøyaktig denne veggen med ein etikettskrivar på eit heimenettverk: appen hadde aldri fått tilgang til det lokale nettverket, og profilen eg testa var ein full tunnel som sluka kvar pakke adressert til 192.168.1.0/24. To uavhengige portar var stengde, og å opne éin ville ikkje ha fjerna symptomet.
To portar mellom éin app og éin skrivar
Den første porten er eit personvernvedtak som høyrer til operativsystemet og ikkje appen. iOS avgjer om ein app får senda trafikk til adresser på det lokale nettverket, og spør brukaren første gongen appen prøver. Den andre porten er rutetabellen. Ei pakke retta mot 192.168.1.50 går anten ut over Wi-Fi mot skrivaren, eller ho går inn i tunnelen, og det valet står i VPN-profilen.
Dei to portane sviktar på ulike måtar, og det er nettopp det som gjer diagnosen mogleg. Ei avslått løyve drep appens eigen socket-kall, så appen har ingenting å rapportera og fell tilbake til ein generell tom tilstand. Eit ruteproblem ser ut som ein timeout, fordi pakkene forlét telefonen og døydde ein stad på den andre sida. Same tomme skjerm, annan reparasjon.
Les løyvestatusen før du rører VPN-en
Opne Innstillingar, deretter Personvern og tryggleik, deretter Lokalt nettverk. Kvar app som har bede om tilgang, visest der med ein brytar. Apple har flytta og gjeve nye namn til delar av denne skjermen mellom iOS 14 og iOS 18, så om oppføringa ikkje er der du ventar, skriv Lokalt nettverk i søkjefeltet i innstillingane i staden for å leita gjennom treet.
Det som fangar folk er eingongsførespurnaden. iOS spør når ein app første gongen rører det lokale nettverket, og berre då. Trykk Ikkje tillat, og førespurnaden kjem ikkje tilbake ved neste start; brytaren er den einaste vegen tilbake, og han startar av. Å installera appen på nytt nullstiller vedtaket, og difor hevdar nokre feilsøkingstrådar at ein reinstallasjon fiksa oppdaginga. Det gjorde han, ved å sletta avslaget.
På ein iPhone som er overvaka eller styrt er brytaren av og til grå. Ein nyttelast med personverninnstillingar som blir send ut via MDM kan førehandsinnstilla eller låsa tilgangen til det lokale nettverket, og ein låst brytar som er av tyder at reparasjonen er ei policyendring og ikkje ei telefonenendring. Apple dokumenterer førespurnaden og brytaren per app her: support.apple.com/en-us/102229.
Kontroller kva tunnelen faktisk rutar
Ein full tunnel tek 0.0.0.0/0 og dermed kvart privat område. Pakker til 10.x, 172.16.0.0/12 og 192.168.x.x reiser til tenaren, som vanlegvis kastar dei eller omset dei til sitt eige subnett, så skrivaren er utilgjengeleg sjølv etter at du gir løyvet. Ein delt tunnel gjer det motsette, men berre for områda profilen listar opp.
IKEv2-profilar bygde med Apple Configurator eller leverte som .mobileconfig uttrykkjer dette som ei innstilling om å senda all trafikk pluss, når han er delt, ei eksplisitt liste over lokale nettverk som skal utelatast. Klientappar bygde på NEPacketTunnelProvider uttrykkjer same vedtaket gjennom includedRoutes. Ingen av dei er synlege frå statuslinja, og begge overstyrer det appen ventar å sjå.
Her er testen eg brukar. Med VPN-en tilkopla opnar du admin-sida til rutaren på LAN-adressa hans i Safari. Viss offentlege nettstader lastar medan den sida får timeout, ligg det private området ditt inne i tunnelen. Viss sida lastar, går lokal trafikk framleis ut over Wi-Fi, og blokkeringa er ein annan stad.
Knytt symptomet til porten
To appar på same telefon kan vera usamde, fordi løyve blir gitt per app medan ruter blir gitt per profil. Samanlikn kva som sviktar før du endrar noko: mønsteret namngjev vanlegvis porten av seg sjølv.
| 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-raden fortener ei merknad. Oppdagingstrafikk for Bonjour og dei fleste cast-protokollane går som multicast til 224.0.0.251 og ff02::fb med link-local omfang, og ein ruta tunnel ber han ikkje. Difor kan ei eining svara på ein direkte tilkopling utan å nokon gong dukka opp i ei liste.
Test handlinga, ikkje ikonet
Etter at du har slått om brytaren for Lokalt nettverk, tving appen til å lukkast frå appbytaren og start han på nytt. Ein køyrande prosess kan halda på den avslåtte tilstanden frå før endringa, og ein app som fortset å returnera ei tom liste ser lik ut anten løyvet verka eller ikkje. Køyr deretter éi konkret handling, som å skriva ut ei testside eller starta ein video, i staden for å venta på at ei einingliste skal fyllast.
Hald VPN-profilen fast gjennom samanlikninga. Viss oppdaginga først byrjar å verka etter at du koplar frå, har du lært at tunnelen er skuldig, ikkje løyvet. Endra éin variabel per forsøk, elles fortel neste køyring deg ingenting.
Fiks det i denne rekkjefølgja
Rekkjefølgja nedanfor er den eg følgjer no, fordi ho aldri lèt ein telefon stå i ein halvendra tilstand der neste test er uleseleg.
- Stadfest at appen står under Personvern og tryggleik, Lokalt nettverk, og at brytaren hans er på.
- Tving appen til å lukkast, start han på nytt og prøv den verkelege handlinga éin gong.
- Opne sida til rutaren på LAN-adressa medan du er tilkopla, for å prova om det private området går gjennom tunnelen.
- Viss det gjer det, rediger profilen så lokale nettverk blir utelatne, eller be den som eig profilen om å gjera det.
- Viss brytaren er grå, handsam eininga som styrt og send førespurnaden til administratoren.
Vanlegvis gjeld berre éin av dei. Viss ingen endrar resultatet, er dei attverande mistenkte nettverket sjølv, til dømes isolasjon på tilgangspunktet eller ei klientløyveliste knytt til Wi-Fi-adresser, og tabellen ovanfor peikar på kven.