MTU du VPN sur iPhone : choisissez le propriétaire avant de changer un nombre

Chaque fil sur la taille des paquets du VPN sur iPhone finit par proposer la même commande Mac contre une interface nommée ppp0, généralement avec un nombre attaché. Elle ne se transpose pas, et ce ne serait pas le bon levier même sur le Mac, sauf si cette interface appartenait à la connexion concernée. Sur le téléphone, le nombre appartient à qui implémente le tunnel : le système d'exploitation pour un profil natif, un fournisseur de tunnel de paquets pour une application, ou la passerelle lorsqu'un attribut documenté est négocié. Trois questions déterminent laquelle de ces situations vous concerne.

Première question : quel client est en cours d'exécution

Un profil IKEv2 natif, le profil Cisco IPsec intégré et un client Cisco tiers sont trois implémentations différentes avec trois ensembles différents d'attributs pris en charge. Le type de profil dans Réglages vous dit lequel le téléphone a réellement démarré, et la liste des applications vous dit si un fournisseur se trouve sur le chemin. Commencez par là, car le reste de la décision en découle. Si aucun fournisseur n'apparaît dans la liste des applications, le système d'exploitation possède le tunnel.

Ne déduisez pas l'implémentation du fournisseur de la passerelle. Une tête de réseau Cisco peut terminer des connexions de clients qui n'ont en commun que le nom du fournisseur. Une capture d'une ancienne version sur un ancien système vous dit ce que ce couple prenait en charge, pas ce que fait le téléphone dans votre main.

Deuxième question : qui possède la valeur

Apple expose une propriété MTU aux développeurs de tunnels de paquets via l'objet de réglages de l'extension réseau. C'est une API pour le fournisseur qui configure son propre tunnel, pas un interrupteur qu'un utilisateur ou un administrateur peut actionner sur le client installé de quelqu'un d'autre. Une application tierce peut choisir de l'exposer, de l'ignorer ou de coder une valeur en dur.

Pour un profil natif, le système d'exploitation choisit la taille de l'interface, et le téléphone n'expose aucun éditeur pour cela. Pour une passerelle Cisco d'accès distant, il existe un attribut documenté pour le profil de connexion, et son application dépend du client, de la version et du transport négocié. C'est précisément dans cet écart entre documenté et respecté qu'un nombre copié se trompe.

Troisième question : le symptôme dépend-il vraiment de la taille

Les problèmes de taille ont une signature : les petites requêtes réussissent, les gros envois ou les grosses réponses se bloquent, et le même service fonctionne sur un autre réseau d'accès. Le filtrage, une limite de charge utile de l'application et un serveur figé peuvent produire une plainte similaire, alors consignez l'opération qui échoue à côté d'une qui fonctionne. Notez les deux avec heures et tailles si l'application les indique. Sans cette paire, chaque changement ultérieur est une conjecture.

Exécutez le même test en Wi-Fi et en réseau mobile. Une panne qui suit le réseau pointe le chemin ; celle qui suit l'appareil pointe le client ou le profil, et les deux exigent des propriétaires différents. Utilisez le même service et le même compte pour les deux exécutions, sinon la comparaison ne vous apprend rien.

Pourquoi la recette Mac ne cesse de réapparaître

Des années de VPN de bureau reposant sur PPP ont fait du changement de taille d'interface un contournement local légitime, et ces instructions ont été recopiées dans les fils mobiles. Sur le téléphone, il n'y a pas de shell, pas un tel nom d'interface, et aucune persistance après une reconnexion. Une recette qui a résolu un problème de bureau en 2011 a voyagé bien plus loin que les conditions qui la rendaient vraie. Les clients mobiles n'acceptent aucune commande shell pour cela, quoi qu'affirme le fil.

Traitez la valeur copiée comme une hypothèse sur un chemin, pas comme un réglage. Si une taille plus petite fait fonctionner un transfert et qu'une plus grande échoue de façon fiable, vous avez des preuves sur le chemin ; il vous reste à trouver le composant autorisé à agir dessus. Cette recherche se termine généralement au profil de la passerelle ou chez l'éditeur de l'application, et rarement sur le téléphone.

Le transport change la réponse

Si la session passe par TLS plutôt que par IPsec, un ajustement de segmentation TCP sur la passerelle peut aider, car il réécrit la taille de segment annoncée pour les flux TCP. Il ne fait rien pour le trafic UDP, qui couvre une plus grande part du web moderne qu'on ne l'imagine. Vérifiez le transport négocié avant de proposer le changement, et indiquez dans le ticket quel transport vous attendez qu'il affecte.

La découverte du MTU de chemin existe pour que les extrémités apprennent la limite réelle au lieu de deviner. Bloquer le retour d'information et coder une petite taille en dur échange un gros transfert qui fonctionne contre un coût permanent et caché sur chaque connexion.

Que demander à l'équipe passerelle

Demandez trois choses : le nom exact de l'attribut et sa portée, si les clients déployés le respectent, et quel transport la session a négocié. Un changement appliqué à une stratégie de groupe est vérifiable ; une modification globale ne l'est pas, et elle reporte le risque sur des utilisateurs qui n'ont jamais signalé de problème. Demandez aussi la référence du document, car les noms d'attributs évoluent entre les versions.

Changez ensuite une seule chose et retestez l'opération d'origine qui échoue, pas un téléchargement de test de débit. Conservez l'enregistrement avant et après avec la version du client et le réseau d'accès, afin que le prochain rapport soit comparé au lieu d'être rouvert.

Si l'opération échoue toujours à la taille d'origine, la taille n'était pas la cause. Consignez aussi cette conclusion, pour que la personne suivante ne rouvre pas la même hypothèse.