L’app iPhone ne trouve plus les appareils locaux quand le VPN est actif
Deux portes décident si une app iPhone peut joindre une imprimante ou un téléviseur via un VPN : l’autorisation Réseau local et les routes propres au tunnel. Vérifiez-les dans l’ordre.
Votre application d’impression affiche une liste vide, l’application photo signale qu’aucun appareil n’a été trouvé, et le bouton de diffusion d’une application vidéo tourne jusqu’à abandonner. L’icône VPN est dans la barre d’état, le téléphone capte pleinement et Safari charge les pages sans problème : rien ne semble cassé du côté de la connexion. Puis vous ouvrez les réglages de l’application et vous ne trouvez rien à activer.
J’ai buté exactement sur ce mur avec une imprimante d’étiquettes sur un réseau domestique : l’application n’avait jamais reçu l’autorisation d’accéder au réseau local, et le profil que je testais était un tunnel complet qui avalait chaque paquet destiné à 192.168.1.0/24. Deux portes indépendantes étaient fermées, et en ouvrir une n’aurait pas fait disparaître le symptôme.
Deux portes entre une application et une imprimante
La première porte est une décision de confidentialité qui appartient au système d’exploitation et non à l’application. iOS décide si une application peut envoyer du trafic vers des adresses du réseau local, et il interroge l’utilisateur la première fois que l’application essaie. La deuxième porte est la table de routage. Un paquet destiné à 192.168.1.50 quitte le téléphone par le Wi-Fi vers l’imprimante, ou il entre dans le tunnel, et ce choix est écrit dans le profil VPN.
Les deux portes échouent de façons différentes, et c’est ce qui rend le diagnostic possible. Une autorisation refusée fait échouer l’appel de socket de l’application elle-même, si bien qu’elle n’a rien à signaler et retombe sur un état vide générique. Un problème de routage ressemble à un délai d’attente, parce que les paquets ont quitté le téléphone et sont morts quelque part de l’autre côté. Même écran vide, réparation différente.
Lisez l’état de l’autorisation avant de toucher au VPN
Ouvrez Réglages, puis Confidentialité et sécurité, puis Réseau local. Chaque application qui a demandé l’accès apparaît là avec un interrupteur. Apple a déplacé et renommé des éléments de cet écran entre iOS 14 et iOS 18 ; si l’entrée n’est pas là où vous l’attendez, tapez Réseau local dans le champ de recherche des Réglages au lieu de fouiller l’arborescence.
Ce qui surprend les gens, c’est la demande unique. iOS pose la question quand une application touche le réseau local pour la première fois, et seulement à ce moment-là. Appuyez sur Ne pas autoriser et la demande ne revient pas au lancement suivant ; l’interrupteur est le seul retour possible, et il est désactivé au départ. Réinstaller l’application réinitialise la décision, d’où certains fils de dépannage qui affirment qu’une réinstallation a réglé la découverte. C’est vrai, en effaçant le refus.
Sur un iPhone supervisé ou géré, l’interrupteur est parfois grisé. Une charge de préférences de confidentialité poussée par MDM peut prédéfinir ou verrouiller l’accès au réseau local, et un interrupteur verrouillé qui est désactivé signifie que la réparation est un changement de politique et non un changement de téléphone. Apple documente la demande et l’interrupteur par application ici : support.apple.com/en-us/102229.
Vérifiez ce que le tunnel route réellement
Un tunnel complet prend 0.0.0.0/0 et, avec lui, toutes les plages privées. Les paquets pour 10.x, 172.16.0.0/12 et 192.168.x.x voyagent vers le serveur, qui les jette généralement ou les traduit dans son propre sous-réseau, si bien que l’imprimante reste injoignable même après avoir accordé l’autorisation. Un tunnel divisé fait l’inverse, mais uniquement pour les plages que le profil énumère.
Les profils IKEv2 créés avec Apple Configurator ou livrés en .mobileconfig expriment cela sous forme d’un réglage consistant à envoyer tout le trafic, plus, en mode divisé, une liste explicite de réseaux locaux à exclure. Les applications clientes bâties sur NEPacketTunnelProvider expriment la même décision via includedRoutes. Ni l’un ni l’autre n’est visible depuis la barre d’état, et les deux écrasent ce que l’application s’attend à voir.
Voici le test que j’utilise. VPN connecté, ouvrez la page d’administration du routeur par son adresse LAN dans Safari. Si les sites publics se chargent alors que cette page expire, votre plage privée est dans le tunnel. Si la page se charge, le trafic local sort encore par le Wi-Fi et le blocage est ailleurs.
Associez le symptôme à la porte
Deux applications sur le même téléphone peuvent être en désaccord, car l’autorisation est accordée par application tandis que les routes le sont par profil. Comparez ce qui échoue avant de changer quoi que ce soit : le schéma nomme généralement la porte de lui-même.
| 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 ligne mDNS mérite une note. Le trafic de découverte pour Bonjour et la plupart des protocoles de diffusion est envoyé en multicast vers 224.0.0.251 et ff02::fb avec une portée lien local, et un tunnel routé ne le transporte pas. C’est pourquoi un appareil peut répondre à une connexion directe sans jamais apparaître dans une liste.
Testez l’opération, pas l’icône
Après avoir basculé l’interrupteur Réseau local, forcez la fermeture de l’application depuis le sélecteur d’applications et relancez-la. Un processus en cours peut conserver l’état refusé d’avant la modification, et une application qui renvoie toujours une liste vide est identique que l’autorisation ait fonctionné ou non. Lancez ensuite une action concrète, comme imprimer une page de test ou démarrer une vidéo, plutôt que de guetter le remplissage d’une liste d’appareils.
Gardez le profil VPN fixe pendant la comparaison. Si la découverte ne fonctionne qu’après la déconnexion, vous avez appris que le tunnel est en cause, pas l’autorisation. Changez une seule variable par essai, sinon l’essai suivant ne vous apprend rien.
Réparez dans cet ordre
La séquence ci-dessous est celle que je suis désormais, parce qu’elle ne laisse jamais un téléphone dans un état à moitié modifié où le test suivant est illisible.
- Vérifiez que l’application figure sous Confidentialité et sécurité, Réseau local, et que son interrupteur est activé.
- Forcez la fermeture puis relancez l’application, et retentez une fois la vraie opération.
- Ouvrez la page du routeur par son adresse LAN pendant que vous êtes connecté, pour prouver si la plage privée est tunnelisée.
- Si elle l’est, modifiez le profil pour exclure les réseaux locaux, ou demandez à la personne qui possède le profil de le faire.
- Si l’interrupteur est grisé, traitez l’appareil comme géré et transmettez la demande à l’administrateur.
En général, une seule de ces causes s’applique. Si aucune ne change le résultat, les suspects restants sont le réseau lui-même, comme l’isolation du point d’accès ou une liste d’autorisation de clients liée aux adresses Wi-Fi, et le tableau de correspondance ci-dessus indique lequel.