Comment appeler une API interne depuis une app iPhone via un VPN

L'API répond dans Safari sur le même téléphone, alors que la requête de l'app expire. Cet écart n'est généralement pas le tunnel : une app qui appelle un service interne fait une requête HTTPS ordinaire, et le VPN déjà présent sur l'appareil décide seulement si cette requête a un chemin. Écrire un second tunnel dans l'app est une décision produit, pas une réparation pour un délai d'attente. Ce qui suit classe la panne selon l'endroit où elle se produit, en s'appuyant sur la surface d'erreur que l'app possède déjà.

Partez de l'erreur, pas du tunnel

URLSession signale les échecs de transport comme des NSError valeurs dans NSURLErrorDomain, et le code est la preuve la moins chère dont vous disposez. Avant de modifier une configuration, journalisez ce code avec le nom d'hôte en échec et le temps écoulé de la tâche. Un délai d'attente, un échec de nom et un échec de confiance se ressemblent à l'écran et demandent trois réparations différentes. Classez d'abord, puis lisez la section de cette classe.

Les métriques de tâche répondent à la question suivante, savoir si une connexion a jamais été établie, ce qui sépare une requête qui n'a jamais eu de route d'une requête à laquelle le serveur a mis trop de temps à répondre. Rien de tout cela n'exige de changer le tunnel ; cela exige d'imprimer les diagnostics de la requête elle-même quelque part où vous pouvez les lire.

La résolution de noms échoue avant tout le reste

Un nom de bureau court comme api.corp.example dépend généralement d'un domaine de recherche que le téléphone ne porte pas, si bien que l'app résout un nom qui n'existe qu'à l'intérieur du bâtiment. NSURLErrorCannotFindHost est la signature. Le nom d'hôte complet doit être résolu par le résolveur que le VPN installe, et l'app devrait demander la forme pleinement qualifiée chaque fois que le domaine de recherche n'est pas garanti. Remplacer le nom par une adresse et désactiver les vérifications de certificat déplace la panne au lieu de la réparer.

Un enregistrement DNS privé et un certificat émis pour ce nom exact forment la paire prise en charge. Tout le reste est un contournement qui part chez les utilisateurs.

Un délai d'attente est une question de chemin, pas de nom

NSURLErrorTimedOut signifie que le nom a été résolu et que rien n'a répondu, ce qui pointe vers la route, la politique de paquets ou le service. Quand le tunnel est attribué par application, une autre app qui atteint le même serveur ne dit rien de votre build, car ce mappage n'est pas partagé. Vérifiez que le bundle que vous exécutez se trouve dans cette attribution, puis vérifiez que le chemin du service y est autorisé. Un build de développement installé hors de l'attribution peut rester entièrement hors du tunnel et ressembler à une API cassée.

Une comparaison dans le navigateur montre qu'une app de l'appareil a un chemin. Elle ne prouve jamais que le vôtre en a un, et c'est pourquoi les deux tests doivent être menés séparément.

Les échecs de confiance concernent le nom sur le certificat

NSURLErrorServerCertificateUntrusted associé à l'erreur TLS en dessous signifie que la chaîne ou le contrôle d'identité a échoué. Une CA interne doit être approuvée sur l'appareil, et un certificat émis pour un autre nom d'hôte reste faux après n'importe quelle reconfiguration réseau. Les recommandations App Transport Security d'Apple continuent de s'appliquer à ces connexions qui chargent des URL, et un tunnel autour d'un service HTTP simple ne rend pas ce service sûr de bout en bout.

Corrigez l'identité ou l'ancre de confiance et gardez la liste d'exceptions vide. Une exception globale pour le chargement arbitraire masque la panne pendant le développement et la laisse en place pour chaque utilisateur ensuite.

Un refus HTTP appartient à l'app, pas au réseau

Un 401 ou 403 après une poignée de main terminée signifie que la requête est arrivée et que le service l'a refusée, donc la question restante est un compte, une audience de jeton, une portée ou une clé. Journalisez le code de statut et le nom d'hôte, jamais le jeton porteur ni le corps de la réponse. À ce stade, le tunnel fait son travail et d'autres changements réseau ne font que retarder la vraie correction.

Le tableau est la classification à garder près du terminal : une ligne par panne que l'app peut réellement signaler. Imprimez le code avant de le lire, car la ligne que vous choisissez décide de la section que vous parcourez.

Chaque ligne est moins coûteuse à tester que celle du dessous, et chacune écarte une couche différente de la même requête. Descendez le tableau jusqu'à ce qu'une ligne corresponde, puis arrêtez de changer le réseau.