iPhone-app vind nie plaaslike toestelle terwyl die VPN aan is nie
Twee hekke bepaal of ’n iPhone-app ’n drukker of TV oor ’n VPN kan bereik: die toestemming vir Plaaslike netwerk en die tonnel se eie roetes. Kontroleer hulle in volgorde.
Jou drukker-app wys ’n leë lys, die kamera-app meld dat geen toestel gevind is nie, en die cast-knoppie in ’n video-app draai tot dit tou opgooi. Die VPN-ikoon sit in die statusbalk, die foon het volle sein en Safari laai bladsye sonder probleme, so niks aan die verbinding lyk stukkend nie. Dan maak jy die app se eie instellings oop en vind niks om om te skakel nie.
Ek het presies teen hierdie muur vasgeloop met ’n etiketdrukker op ’n tuisnetwerk: die app het nooit toegang tot die plaaslike netwerk gekry nie, en die profiel wat ek getoets het, was ’n vol tonnel wat elke pakkie na 192.168.1.0/24 ingesluk het. Twee onafhanklike hekke was toe, en om een oop te maak sou die simptoom nie verwyder nie.
Twee hekke tussen een app en een drukker
Die eerste hek is ’n privaatheidsbesluit wat aan die bedryfstelsel behoort, nie aan die app nie. iOS besluit of ’n app verkeer na adresse op die plaaslike netwerk mag stuur, en vra die gebruiker die eerste keer wat die app probeer. Die tweede hek is die roetetabel. ’n Pakkie na 192.168.1.50 verlaat óf die foon oor Wi-Fi na die drukker, óf dit gaan die tonnel in, en daardie keuse staan in die VPN-profiel.
Die twee hekke misluk op verskillende maniere, en dit is juis wat die diagnose moontlik maak. ’n Geweierde toestemming maak die app se eie socket-oproep dood, so die app het niks om te rapporteer nie en val terug na ’n generiese leë toestand. ’n Roeterprobleem lyk soos ’n tydverstryking, want die pakkies het die foon verlaat en iewers aan die ander kant gesterf. Dieselfde leë skerm, ander herstel.
Lees die toestemmingsstatus voordat jy aan die VPN raak
Maak Instellings oop, dan Privaatheid en veiligheid, dan Plaaslike netwerk. Elke app wat toegang aangevra het, verskyn daar met ’n skakelaar. Apple het dele van hierdie skerm tussen iOS 14 en iOS 18 geskuif en hernoem, so as die inskrywing nie is waar jy dit verwag nie, tik Plaaslike netwerk in die soekveld van Instellings eerder as om die boom deur te snuffel.
Wat mense die meeste vang, is die eenmalige navraag. iOS vra wanneer ’n app die plaaslike netwerk die eerste keer aanraak, en net dan. Tik Moet nie toelaat nie en die navraag keer nie terug by die volgende opening nie; die skakelaar is die enigste pad terug, en dit begin af. Om die app weer te installeer stel die besluit terug, en daarom beweer sommige foutopsporing-drade dat ’n herinstallering die ontdekking reggemaak het. Dit het, deur die weiering te skrap.
Op ’n iPhone onder toesig of bestuur is die skakelaar soms grys. ’n Privaatheidvoorkeure-nutsvrag wat deur MDM gestuur word, kan toegang tot die plaaslike netwerk vooraf instel of sluit, en ’n geslote skakelaar wat af is, beteken die herstel is ’n beleidsverandering en nie ’n foonverandering nie. Apple dokumenteer die navraag en die skakelaar per app hier: support.apple.com/en-us/102229.
Kyk wat die tonnel werklik roeteer
’n Vol tonnel neem 0.0.0.0/0 en daarmee elke private reeks. Pakkies vir 10.x, 172.16.0.0/12 en 192.168.x.x reis na die bediener, wat dit gewoonlik weggooi of in sy eie subnet vertaal, so die drukker bly onbereikbaar selfs nadat jy toestemming gegee het. ’n Gedeelde tonnel doen die teenoorgestelde, maar net vir die reekse wat die profiel lys.
IKEv2-profiele wat met Apple Configurator gebou of as .mobileconfig versprei word, druk dit uit as ’n instelling om alle verkeer te stuur plus, in gedeelde modus, ’n uitdruklike lys plaaslike netwerke om uit te sluit. Kliënt-apps wat op NEPacketTunnelProvider gebou is, druk dieselfde besluit deur includedRoutes uit. Nie een van die twee is van die statusbalk af sigbaar nie, en albei oorskryf wat die app verwag om te sien.
Hier is die toets wat ek gebruik. Met die VPN verbind, maak die roeteerder se admin-blad in Safari oop deur sy LAN-adres. As openbare werwe laai terwyl daardie blad tydverstryk, is jou private reeks in die tonnel. As die blad laai, verlaat plaaslike verkeer nog steeds die foon oor Wi-Fi en sit die blokkade elders.
Koppel die simptoom aan die hek
Twee apps op dieselfde foon kan verskil, want toestemming word per app gegee terwyl roetes per profiel gegee word. Vergelyk wat misluk voordat jy iets verander: die patroon noem gewoonlik die hek self.
| 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-ry verdien ’n nota. Ontdekkingsverkeer vir Bonjour en die meeste cast-protokolle gaan as multicast na 224.0.0.251 en ff02::fb met link-local omvang, en ’n geroteerde tonnel dra dit nie. Daarom kan ’n toestel op ’n direkte verbinding antwoord sonder om ooit in ’n lys te verskyn.
Toets die handeling, nie die ikoon nie
Nadat jy die Plaaslike netwerk-skakelaar omgesit het, forseer die app toe uit die app-wisselaar en begin dit weer. ’n Lopende proses kan die geweierde toestand van voor die verandering vashou, en ’n app wat aanhou om ’n leë lys terug te gee, lyk dieselfde of die toestemming gewerk het of nie. Voer dan een konkrete handeling uit, soos om ’n toetsblad te druk of ’n video te begin, eerder as om te wag dat ’n toestellys vol word.
Hou die VPN-profiel vas tydens die vergelyking. As ontdekking eers werk nadat jy die verbinding verbreek, het jy geleer dat die tonnel skuldig is, nie die toestemming nie. Verander een veranderlike per poging, anders sê die volgende rondte jou niks.
Herstel dit in hierdie volgorde
Die volgorde hieronder is die een wat ek nou volg, want dit laat nooit ’n foon in ’n halfveranderde toestand waar die volgende toets onleesbaar is nie.
- Bevestig dat die app onder Privaatheid en veiligheid, Plaaslike netwerk gelys is en dat sy skakelaar aan is.
- Forseer die app toe, begin dit weer en probeer die werklike handeling een keer.
- Maak die roeteerder se blad oop deur die LAN-adres terwyl jy verbind is, om te bewys of die private reeks deur die tonnel gaan.
- As dit deurgaan, wysig die profiel om plaaslike netwerke uit te sluit, of vra die eienaar van die profiel om dit te doen.
- As die skakelaar grys is, hanteer die toestel as bestuur en stuur die versoek na die administrateur.
Gewoonlik geld net een van hulle. As nie een die uitslag verander nie, is die oorblywende verdagtes die netwerk self, soos toegangspunt-isolasie of ’n kliënttoelaatlys wat aan Wi-Fi-adresse gekoppel is, en die karteringstabel hierbo wys watter een.