La teva aplicació d’impressió mostra una llista buida, l’aplicació de càmera informa que no s’ha trobat cap dispositiu i el botó d’emissió d’una aplicació de vídeo gira fins que es rendeix. La icona de VPN és a la barra d’estat, el telèfon té senyal complet i Safari carrega pàgines sense problema, així que res de la connexió no sembla trencat. Després obres els ajustos de la mateixa aplicació i no hi trobes res per activar.

Vaig topar exactament amb aquesta paret amb una impressora d’etiquetes en una xarxa domèstica: a l’aplicació mai no se li havia concedit accés a la xarxa local, i el perfil que provava era un túnel complet que s’empassava cada paquet adreçat a 192.168.1.0/24. Dues portes independents estaven tancades, i obrir-ne una no hauria eliminat el símptoma.

Dues portes entre una aplicació i una impressora

La primera porta és una decisió de privadesa que pertany al sistema operatiu i no a l’aplicació. iOS decideix si una aplicació pot enviar trànsit a adreces de la xarxa local, i pregunta a l’usuari la primera vegada que l’aplicació ho intenta. La segona porta és la taula d’encaminament. Un paquet adreçat a 192.168.1.50 o surt per Wi-Fi cap a la impressora, o entra al túnel, i aquesta tria està escrita al perfil de VPN.

Les dues portes fallen de maneres diferents, i això és el que fa possible el diagnòstic. Un permís denegat fa fallar la mateixa crida de socket de l’aplicació, així que l’aplicació no té res a informar i cau en un estat buit genèric. Un problema d’encaminament sembla un temps d’espera esgotat, perquè els paquets van sortir del telèfon i van morir en algun punt de l’altre costat. Mateixa pantalla en blanc, reparació diferent.

Llegeix l’estat del permís abans de tocar la VPN

Obre Configuració, després Privadesa i seguretat, després Xarxa local. Cada aplicació que ha demanat accés apareix allà amb un commutador. Apple ha mogut i ha canviat de nom parts d’aquesta pantalla entre iOS 14 i iOS 18, així que si l’entrada no és on l’esperes, escriu Xarxa local al camp de cerca de Configuració en lloc de recórrer l’arbre.

El que atrapa la gent és l’avís únic. iOS pregunta quan una aplicació toca la xarxa local per primera vegada, i només llavors. Toca No permetre i l’avís no torna a l’obertura següent; el commutador és l’única via de tornada, i comença desactivat. Reinstal·lar l’aplicació reinicia la decisió, i per això alguns fils de resolució de problemes afirmen que una reinstal·lació va arreglar la descoberta. Ho va fer, esborrant la denegació.

En un iPhone supervisat o gestionat el commutador de vegades apareix en gris. Una càrrega de preferències de privadesa enviada per MDM pot predefinir o bloquejar l’accés a la xarxa local, i un commutador bloquejat que està desactivat vol dir que la reparació és un canvi de política i no un canvi de telèfon. Apple documenta l’avís i el commutador per aplicació aquí: support.apple.com/en-us/102229.

Comprova què encamina realment el túnel

Un túnel complet pren 0.0.0.0/0 i, amb això, tots els rangs privats. Els paquets per a 10.x, 172.16.0.0/12 i 192.168.x.x viatgen fins al servidor, que normalment els descarta o els tradueix a la seva pròpia subxarxa, així que la impressora queda inabastable fins i tot després de concedir el permís. Un túnel dividit fa el contrari, però només per als rangs que enumera el perfil.

Els perfils IKEv2 creats amb Apple Configurator o distribuïts com a .mobileconfig expressen això com un ajust d’enviar tot el trànsit més, en mode dividit, una llista explícita de xarxes locals a excloure. Les aplicacions client basades en NEPacketTunnelProvider expressen la mateixa decisió mitjançant includedRoutes. Cap de les dues no és visible des de la barra d’estat, i totes dues anul·len el que l’aplicació espera veure.

Aquesta és la prova que faig servir. Amb la VPN connectada, obre la pàgina d’administració del router per la seva adreça LAN a Safari. Si els llocs públics carreguen mentre aquesta pàgina esgota el temps, el teu rang privat és dins del túnel. Si la pàgina carrega, el trànsit local encara surt per Wi-Fi i el bloqueig és en un altre lloc.

Assigna el símptoma a la porta

Dues aplicacions al mateix telèfon poden discrepar, perquè el permís es concedeix per aplicació mentre que les rutes es concedeixen per perfil. Compara què falla abans de canviar res: el patró normalment anomena la porta tot sol.

What you seeGateNext step
Device list stays empty, Local Network switch is offPermissionEnable the switch, force-quit the app, reopen it
Switch is on, router page times out, public sites loadRoutingExclude the local range in the profile, or move to a split tunnel
Both pass, direct IP works, discovery stays emptyLink-local multicastEnter the device address by hand, or check profile discovery support
Works by IP address, never by name such as printer.localName resolutionFix mDNS reachability or use the numeric address
Everything fails with the VPN off, on hotel Wi-FiClient isolationChange network, do not change permissions

La fila de mDNS mereix una nota. El trànsit de descoberta per a Bonjour i la majoria de protocols d’emissió va per multicast a 224.0.0.251 i ff02::fb amb abast d’enllaç local, i un túnel encaminat no el transporta. Per això un dispositiu pot respondre a una connexió directa sense aparèixer mai en una llista.

Prova l’operació, no la icona

Després de canviar el commutador de Xarxa local, força el tancament de l’aplicació des del selector i torna a obrir-la. Un procés en execució pot conservar l’estat denegat anterior al canvi, i una aplicació que continua tornant una llista buida es veu igual tant si el permís ha funcionat com si no. Després executa una acció concreta, com imprimir una pàgina de prova o iniciar un vídeo, en lloc d’esperar que s’ompli una llista de dispositius.

Mantén fix el perfil de VPN durant la comparació. Si la descoberta només comença a funcionar després de desconnectar, has après que el culpable és el túnel i no el permís. Canvia una sola variable per intent, perquè si no la prova següent no et diu res.

Arregla-ho en aquest ordre

La seqüència de sota és la que segueixo ara, perquè no deixa mai un telèfon en un estat mig canviat on la prova següent és il·legible.

  1. Confirma que l’aplicació apareix a Privadesa i seguretat, Xarxa local, i que el seu commutador està activat.
  2. Força el tancament, torna a obrir l’aplicació i reintenta l’operació real una vegada.
  3. Obre la pàgina del router per la seva adreça LAN mentre estàs connectat per demostrar si el rang privat va pel túnel.
  4. Si hi va, edita el perfil per excloure les xarxes locals, o demana a qui és amo del perfil que ho faci.
  5. Si el commutador és gris, tracta el dispositiu com a gestionat i adreça la sol·licitud a l’administrador.

Normalment només se n’aplica una. Si cap no canvia el resultat, els sospitosos restants són la mateixa xarxa, com l’aïllament de punts d’accés o una llista de clients permesos lligada a adreces Wi-Fi, i la taula de correspondència de dalt assenyala quina.

Articles relacionats