Come chiamare un'API interna da un'app iPhone tramite VPN

L'API risponde in Safari sullo stesso telefono, mentre la richiesta dell'app scade. Quel divario di solito non è il tunnel: un'app che chiama un servizio interno fa una normale richiesta HTTPS, e la VPN già presente sul dispositivo decide solo se quella richiesta ha un percorso. Scrivere un secondo tunnel nell'app è una decisione di prodotto, non una riparazione per un timeout. Quanto segue classifica il guasto in base a dove avviene, usando la superficie di errore che l'app ha già.

Parti dall'errore, non dal tunnel

URLSession segnala i guasti di trasporto come NSError valori in NSURLErrorDomain, e il codice è la prova meno costosa disponibile. Prima di modificare qualsiasi configurazione, registra quel codice con il nome host che fallisce e il tempo trascorso dell'attività. Un timeout, un guasto di nome e un guasto di fiducia appaiono identici sullo schermo e richiedono tre riparazioni diverse. Classifica prima, poi leggi la sezione per quella classe.

Le metriche dell'attività rispondono alla domanda successiva, se sia mai stata stabilita una connessione, il che separa una richiesta che non ha mai avuto un percorso da una a cui il server ha risposto troppo lentamente. Niente di tutto questo richiede di cambiare il tunnel; richiede che la diagnostica della richiesta stessa sia stampata da qualche parte che puoi leggere.

La risoluzione dei nomi fallisce prima di qualsiasi altra cosa

Un nome di ufficio breve come api.corp.example di solito dipende da un dominio di ricerca che il telefono non porta, quindi l'app risolve un nome che esiste solo dentro l'edificio. NSURLErrorCannotFindHost è la firma. Il nome host completo deve essere risolto tramite qualunque resolver installi la VPN, e l'app dovrebbe chiedere la forma completamente qualificata ogni volta che il dominio di ricerca non è garantito. Sostituire il nome con un indirizzo e disattivare i controlli dei certificati sposta il guasto invece di ripararlo.

Un record DNS privato e un certificato emesso per quel nome esatto sono la coppia supportata. Tutto il resto è un aggiramento che arriva agli utenti.

Un timeout è una questione di percorso, non di nome

NSURLErrorTimedOut significa che il nome è stato risolto e nulla ha risposto, il che punta alla rotta, alla politica dei pacchetti o al servizio. Quando il tunnel è assegnato per applicazione, un'altra app che raggiunge lo stesso server non dice nulla sulla tua build, perché quella mappatura non è condivisa. Verifica che il bundle che esegui sia dentro quell'assegnazione, poi verifica che il percorso del servizio sia consentito per esso. Una build di sviluppo installata fuori dall'assegnazione può restare del tutto fuori dal tunnel e sembrare un'API rotta.

Un confronto nel browser mostra che qualche app sul dispositivo ha un percorso. Non dimostra mai che ce l'abbia la tua build, per questo le due prove vanno eseguite separatamente.

I guasti di fiducia riguardano il nome sul certificato

NSURLErrorServerCertificateUntrusted insieme all'errore TLS sottostante significa che la catena o il controllo dell'identità è fallito. Una CA interna deve essere attendibile sul dispositivo, e un certificato emesso per un altro nome host resta sbagliato dopo qualsiasi riconfigurazione di rete. Le linee guida App Transport Security di Apple continuano ad applicarsi a queste connessioni che caricano URL, e un tunnel attorno a un servizio HTTP semplice non rende quel servizio sicuro da un capo all'altro.

Correggi l'identità o l'ancora di fiducia e mantieni vuoto l'elenco delle eccezioni. Un'eccezione generale per il caricamento arbitrario nasconde il guasto durante lo sviluppo e lo lascia al suo posto per ogni utente in seguito.

Un rifiuto HTTP appartiene all'app, non alla rete

Un 401 o 403 dopo un handshake completato significa che la richiesta è arrivata e il servizio l'ha rifiutata, quindi la domanda che resta è un account, un pubblico del token, un ambito o una chiave. Registra il codice di stato e il nome host, mai il token bearer o il corpo della risposta. A quel punto il tunnel fa il suo lavoro e ulteriori modifiche di rete ritardano solo la vera correzione.

La tabella è la classificazione da tenere accanto al terminale: una riga per ogni guasto che l'app può davvero segnalare. Stampa il codice prima di leggerlo, perché la riga che scegli decide quale sezione lavori.

Ogni riga è più economica da provare di quella sotto, e ciascuna esclude uno strato diverso della stessa richiesta. Scendi nella tabella finché una riga corrisponde, poi smetti di cambiare la rete.