Hindi mahanap ng iPhone app ang mga lokal na device habang bukas ang VPN
Dalawang gate ang nagpapasya kung maaabot ng iPhone app ang printer o TV sa pamamagitan ng VPN: ang permission sa Local Network at ang mga ruta ng tunnel mismo. Suriin ang mga ito nang sunod-sunod.
Nagpapakita ng walang laman na listahan ang app ng printer mo, sinasabi ng camera app na walang nakitang device, at umiikot hanggang sumuko ang cast button sa isang video app. Nasa status bar ang icon ng VPN, puno ang signal ng telepono, at maayos na naglo-load ang Safari ng mga page, kaya wala sa koneksyon ang mukhang sira. Pagkatapos ay bubuksan mo ang sariling settings ng app at wala kang makitang maaaring i-toggle.
Eksaktong nabangga ko ang pader na ito gamit ang label printer sa isang home network: hindi kailanman nabigyan ng access sa local network ang app, at ang profile na sinusubukan ko ay isang full tunnel na lumamon sa bawat packet na nakadirekta sa 192.168.1.0/24. Dalawang magkahiwalay na gate ang sarado, at ang pagbukas ng isa ay hindi maaalis ang sintomas.
Dalawang gate sa pagitan ng isang app at isang printer
Ang unang gate ay isang desisyon sa privacy na pag-aari ng operating system, hindi ng app. Nagpapasya ang iOS kung ang isang app ay maaaring magpadala ng traffic sa mga address sa local network, at tinatanong ang user sa unang pagkakataong subukan ito ng app. Ang pangalawang gate ay ang routing table. Ang packet na patungo sa 192.168.1.50 ay lumalabas sa Wi-Fi patungo sa printer, o pumapasok sa tunnel, at ang napiling iyon ay nakasulat sa profile ng VPN.
Iba-iba ang paraan ng pagpalya ng dalawang gate, at iyon ang dahilan kung bakit nagiging posible ang diagnosis. Ang tinanggihang permission ay pumapatay sa sariling socket call ng app, kaya wala itong maipapaalam at bumabalik sa isang generic na walang laman na estado. Ang problema sa routing ay mukhang timeout, dahil umalis ang mga packet sa telepono at namatay sa isang lugar sa kabilang dulo. Parehong blangkong screen, ibang pagkukumpuni.
Basahin ang estado ng permission bago hawakan ang VPN
Buksan ang Settings, pagkatapos ang Privacy at Security, pagkatapos ang Local Network. Bawat app na humiling ng access ay lumilitaw doon na may switch. Inilipat at pinangalanang muli ng Apple ang mga bahagi ng screen na ito sa pagitan ng iOS 14 at iOS 18, kaya kung wala ang entry sa inaasahan mong lugar, i-type ang Local Network sa search field ng Settings kaysa maghalughog sa puno.
Ang madalas makahuli sa mga tao ay ang isahang prompt. Nagtatanong ang iOS kapag unang naabot ng app ang local network, at doon lang. I-tap ang Huwag Payagan at hindi na babalik ang prompt sa susunod na pagbukas; ang switch ang tanging daan pabalik, at patay ito sa simula. Nire-reset ng muling pag-install ng app ang desisyon, kaya sinasabi ng ilang thread sa pag-troubleshoot na inayos ng muling pag-install ang paghahanap. Inayos nga, sa pamamagitan ng pagbura ng pagtanggi.
Sa iPhone na pinangangasiwaan o pinamamahalaan, minsan kulay abo ang switch. Ang privacy preferences payload na ipinapadala ng MDM ay maaaring mag-preset o mag-lock ng access sa local network, at ang naka-lock na switch na patay ay nangangahulugang pagbabago sa patakaran ang pagkukumpuni, hindi pagbabago sa telepono. Dokumentado ng Apple ang prompt at ang switch bawat app dito: support.apple.com/en-us/102229.
Suriin kung ano talaga ang niroruta ng tunnel
Kinukuha ng full tunnel ang 0.0.0.0/0 at kasama nito ang bawat pribadong range. Naglalakbay patungo sa server ang mga packet para sa 10.x, 172.16.0.0/12 at 192.168.x.x, na karaniwang itinatapon o isinasalin ang mga ito sa sariling subnet, kaya hindi maabot ang printer kahit pagkatapos mong magbigay ng permission. Ang split tunnel ay kabaligtaran, ngunit para lamang sa mga range na nakalista sa profile.
Ang mga profile ng IKEv2 na ginawa gamit ang Apple Configurator o ipinamahagi bilang .mobileconfig ay nagpapahayag nito bilang setting na ipadala ang lahat ng traffic kasama ang, kapag split, isang tahasang listahan ng mga lokal na network na dapat ibukod. Ang mga client app na binuo sa NEPacketTunnelProvider ay nagpapahayag ng parehong desisyon sa pamamagitan ng includedRoutes. Wala sa dalawa ang nakikita mula sa status bar, at parehong pinapawalang-bisa ang inaasahang makita ng app.
Ito ang test na ginagamit ko. Kapag nakakonekta ang VPN, buksan sa Safari ang admin page ng router sa LAN address nito. Kung naglo-load ang mga pampublikong site habang nag-timeout ang page na iyon, nasa loob ng tunnel ang pribadong range mo. Kung nag-load ang page, lumalabas pa rin sa Wi-Fi ang lokal na traffic at nasa ibang lugar ang pagharang.
Itugma ang sintomas sa gate
Maaaring hindi magkasundo ang dalawang app sa iisang telepono, dahil bawat app ang binibigyan ng permission samantalang bawat profile ang binibigyan ng ruta. Ihambing kung ano ang pumapalya bago magbago ng kahit ano: karaniwang pinapangalanan ng pattern ang gate mismo.
| 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 |
Ang mDNS row ay dapat bigyan ng tala. Ang discovery traffic para sa Bonjour at karamihan ng cast protocol ay multicast patungo sa 224.0.0.251 at ff02::fb na may link-local scope, at hindi ito dinadala ng rutadong tunnel. Kaya nakakasagot ang device sa direktang koneksyon nang hindi kailanman lumilitaw sa listahan.
Subukan ang operasyon, hindi ang icon
Pagkatapos ilipat ang switch ng Local Network, pilitin ang app na isara mula sa app switcher at buksan muli. Maaaring taglayin ng tumatakbong proseso ang tinanggihang estado mula bago ang pagbabago, at ang app na patuloy na nagbabalik ng walang laman na listahan ay pareho ang hitsura kahit gumana o hindi ang permission. Pagkatapos ay magsagawa ng isang konkretong aksyon, tulad ng pag-print ng test page o pagsisimula ng video, kaysa maghintay na mapuno ang listahan ng device.
Panatilihing hindi nagbabago ang profile ng VPN sa buong paghahambing. Kung gagana lang ang paghahanap pagkatapos mong idiskonekta, nalaman mong ang tunnel ang may kasalanan, hindi ang permission. Isang variable lang ang baguhin bawat pagsubok, kung hindi wala kang mapapala sa susunod na pagtakbo.
Ayusin sa ganitong pagkakasunod-sunod
Ang sumusunod na sekwensiya ang sinusunod ko ngayon, dahil hindi nito kailanman iniiwan ang telepono sa kalahating nabagong estado kung saan hindi mababasa ang susunod na test.
- Kumpirmahin na nakalista ang app sa Privacy at Security, Local Network, at nakabukas ang switch nito.
- Pilitin ang pagsasara, buksan muli ang app, at subukan muli ang tunay na operasyon nang isang beses.
- Buksan ang page ng router sa LAN address habang nakakonekta upang patunayan kung nasa tunnel ang pribadong range.
- Kung nasa tunnel, i-edit ang profile upang ibukod ang mga lokal na network, o hilingin sa may-ari ng profile na gawin ito.
- Kung kulay abo ang switch, ituring na pinamamahalaan ang device at ipasa ang kahilingan sa administrator.
Karaniwang isa lang ang naaangkop. Kung wala sa mga ito ang makapagbabago ng resulta, ang natitirang mga suspek ay ang network mismo, tulad ng access point isolation o listahan ng pinapayagang client na nakatali sa Wi-Fi address, at itinuturo ng mapping table sa itaas kung alin.