iPhone-apo ne trovas lokajn aparatojn dum VPN estas ŝaltita
Du pordegoj decidas ĉu iPhone-apo povas atingi printilon aŭ televidilon per VPN: la permeso por Loka reto kaj la enkursigoj de la tunelo mem. Kontrolu ilin laŭvice.
Via printila apo montras malplenan liston, la kameraa apo raportas ke neniu aparato troviĝis, kaj la dissenda butono en filma apo turniĝas ĝis ĝi rezignas. La VPN-ikono staras en la statobreto, la telefono havas plenan signalon kaj Safari ŝargas paĝojn senprobleme, do nenio pri la konekto ŝajnas rompita. Poste vi malfermas la proprajn agordojn de la apo kaj trovas nenion por ŝalti.
Mi trafis ĝuste tiun ĉi muron per etikeda printilo en hejma reto: al la apo neniam estis donita aliro al la loka reto, kaj la profilo, kiun mi testis, estis plena tunelo, kiu glutis ĉiun paketon adresitan al 192.168.1.0/24. Du sendependaj pordegoj estis fermitaj, kaj malfermi unu ne estus foriginta la simptomon.
Du pordegoj inter unu apo kaj unu printilo
La unua pordego estas privateca decido, kiu apartenas al la operaciumo kaj ne al la apo. iOS decidas ĉu apo rajtas sendi trafikon al adresoj en la loka reto, kaj ĝi demandas la uzanton la unuan fojon, kiam la apo provas. La dua pordego estas la enkursiga tabelo. Paketo celanta 192.168.1.50 aŭ eliras per Wi-Fi al la printilo, aŭ ĝi eniras la tunelon, kaj tiu elekto estas skribita en la VPN-profilo.
La du pordegoj malsukcesas laŭ malsamaj formoj, kaj ĝuste tio ebligas la diagnozon. Rifuzita permeso mortigas la propran soketan alvokon de la apo, do la apo havas nenion raporti kaj falas reen al ĝenerala malplena stato. Enkursiga problemo aspektas kiel tempolimo, ĉar la paketoj forlasis la telefonon kaj mortis ie sur la alia flanko. Sama malplena ekrano, malsama riparo.
Legi la permesan staton antaŭ ol tuŝi la VPN-on
Malfermu Agordoj, poste Privateco kaj sekureco, poste Loka reto. Ĉiu apo, kiu petis aliron, aperas tie kun ŝaltilo. Apple movis kaj renomis partojn de ĉi tiu ekrano inter iOS 14 kaj iOS 18, do se la ero ne estas tie, kie vi atendas ĝin, tajpu Loka reto en la serĉkampon de la agordoj anstataŭ serĉi tra la arbo.
Tio, kio kaptas homojn, estas la unufoja demando. iOS demandas, kiam apo unuafoje tuŝas la lokan reton, kaj nur tiam. Tuŝu Ne permesi kaj la demando ne revenos ĉe la sekva lanĉo; la ŝaltilo estas la sola vojo reen, kaj ĝi komence estas malŝaltita. Reinstali la upon restarigas la decidon, tial iuj problemtraktaj fadenoj asertas, ke reinstalo riparis la malkovron. Ĝi ja riparis, forigante la rifuzon.
Sur superrigardata aŭ administrata iPhone la ŝaltilo foje estas griza. Privateca preferenca utilego puŝita de MDM povas antaŭagordi aŭ ŝlosi aliron al la loka reto, kaj ŝlosita malŝaltita ŝaltilo signifas, ke la riparo estas ŝanĝo de politiko kaj ne ŝanĝo de telefono. Apple dokumentas la demandon kaj la ŝaltilon por ĉiu apo ĉi tie: support.apple.com/en-us/102229.
Kontroli, kion la tunelo efektive enkursigas
Plena tunelo prenas 0.0.0.0/0 kaj kun ĝi ĉiun privatan intervalon. Paketoj por 10.x, 172.16.0.0/12 kaj 192.168.x.x vojaĝas al la servilo, kiu kutime forĵetas ilin aŭ tradukas ilin en sian propran subreton, do la printilo restas neatingebla eĉ post kiam vi donas la permeson. Dividita tunelo faras la malon, sed nur por la intervaloj, kiujn listigas la profilo.
IKEv2-profiloj konstruitaj per Apple Configurator aŭ liveritaj kiel .mobileconfig esprimas tion kiel agordon sendi la tutan trafikon plus, en dividita reĝimo, eksplicitan liston de lokaj retoj por ekskludi. Klientaj apoj konstruitaj sur NEPacketTunnelProvider esprimas la saman decidon per includedRoutes. Neniu el ambaŭ videblas el la statobreto, kaj ambaŭ superregas tion, kion la apo atendas vidi.
Jen la testo, kiun mi uzas. Kun konektita VPN, malfermu en Safari la administran paĝon de la enkursigilo per ĝia LAN-adreso. Se publikaj retejoj ŝargas dum tiu paĝo tempolimas, via privata intervalo estas ene de la tunelo. Se la paĝo ŝargas, loka trafiko ankoraŭ eliras per Wi-Fi, kaj la blokado estas aliloke.
Ligi la simptomon al la pordego
Du apoj sur la sama telefono povas malkonsenti, ĉar permeso doniĝas por apo dum enkursigoj doniĝas por profilo. Komparu, kio malsukcesas, antaŭ ol ŝanĝi ion: la ŝablono kutime mem nomas la pordegon.
| 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 |
La mDNS-vico meritas noton. Malkovra trafiko por Bonjour kaj la plej multaj dissendaj protokoloj iras kiel multdissendo al 224.0.0.251 kaj ff02::fb kun loka ligila amplekso, kaj enkursigita tunelo ne portas ĝin. Tial aparato povas respondi al rekta konekto sen iam aperi en listo.
Testu la operacion, ne la ikonon
Post kiam vi ŝaltis la ŝaltilon Loka reto, devigu la upon fermiĝi el la apa ŝaltilo kaj lanĉu ĝin denove. Rulata procezo povas teni la rifuzitan staton de antaŭ la ŝanĝo, kaj apo, kiu daŭre redonas malplenan liston, aspektas same ĉu la permeso funkciis ĉu ne. Poste plenumu unu konkretan agon, ekzemple presi testan paĝon aŭ lanĉi filmon, anstataŭ atendi, ke lista de aparatoj pleniĝu.
Tenu la VPN-profilon fiksa dum la komparo. Se malkovro komencas funkcii nur post kiam vi malkonektas, vi lernis, ke la tunelo kulpas, ne la permeso. Ŝanĝu unu variablon por provo, alie la sekva rondo diras al vi nenion.
Riparu ĝin en ĉi tiu ordo
La sekva sinsekvo estas tiu, kiun mi nun sekvas, ĉar ĝi neniam lasas telefonon en duone ŝanĝita stato, kie la sekva testo estas nelegebla.
- Konfirmu, ke la apo estas listigita sub Privateco kaj sekureco, Loka reto, kaj ke ĝia ŝaltilo estas ŝaltita.
- Devigu la upon fermiĝi, lanĉu ĝin denove, kaj reprovu la veran operacion unufoje.
- Malfermu la paĝon de la enkursigilo per la LAN-adreso dum vi estas konektita, por pruvi ĉu la privata intervalo iras tra la tunelo.
- Se ĝi iras, redaktu la profilon por ekskludi la lokajn retojn, aŭ petu la posedanton de la profilo fari tion.
- Se la ŝaltilo estas griza, traktu la aparaton kiel administrata kaj plusendu la peton al la administranto.
Kutime validas nur unu. Se neniu ŝanĝas la rezulton, la restantaj suspektatoj estas la reto mem, ekzemple izolado de alirpunkto aŭ permeslisto de klientoj ligita al Wi-Fi-adresoj, kaj la mapada tabelo supre montras, kiu.