So rufen Sie eine interne API aus einer iPhone-App über VPN auf

Die API antwortet in Safari auf demselben Telefon, doch die Anfrage der App läuft in eine Zeitüberschreitung. Diese Lücke ist meistens nicht der Tunnel: Eine App, die einen internen Dienst aufruft, stellt eine gewöhnliche HTTPS-Anfrage, und das vorhandene VPN des Geräts entscheidet nur darüber, ob diese Anfrage einen Pfad hat. Einen zweiten Tunnel in die App zu schreiben, ist eine Produktentscheidung, keine Reparatur für eine Zeitüberschreitung. Was folgt, ordnet den Fehler danach ein, wo er auftritt, und nutzt dabei die Fehleroberfläche, die die App bereits hat.

Am Fehler ansetzen, nicht am Tunnel

URLSession meldet Transportfehler als NSError-Werte in NSURLErrorDomain, und der Code ist der billigste verfügbare Beweis. Bevor Sie eine Konfiguration ändern, protokollieren Sie diesen Code zusammen mit dem fehlschlagenden Hostnamen und der Laufzeit der Aufgabe. Eine Zeitüberschreitung, ein Namensfehler und ein Vertrauensfehler sehen auf dem Bildschirm gleich aus und erfordern drei verschiedene Reparaturen. Erst einordnen, dann den Abschnitt für diese Klasse lesen.

Task-Metriken beantworten die Folgefrage, ob überhaupt eine Verbindung aufgebaut wurde; das trennt eine Anfrage, die nie eine Route hatte, von einer, deren Beantwortung dem Server zu lange dauerte. Nichts davon erfordert eine Änderung am Tunnel; erforderlich ist, die eigenen Diagnosedaten der Anfrage an einer lesbaren Stelle auszugeben.

Die Namensauflösung scheitert, bevor irgendetwas anderes möglich ist

Ein kurzer Firmenname wie api.corp.example hängt normalerweise von einer Suchdomäne ab, die das Telefon nicht mitführt, sodass die App einen Namen auflöst, der nur innerhalb des Gebäudes existiert. NSURLErrorCannotFindHost ist die Signatur. Der vollständige Hostname muss über den Resolver aufgelöst werden, den das VPN installiert, und die App sollte die vollqualifizierte Form anfordern, wann immer die Suchdomäne nicht garantiert ist. Den Namen gegen eine Adresse zu tauschen und Zertifikatsprüfungen abzuschalten, verschiebt den Fehler, statt ihn zu beheben.

Ein privater DNS-Eintrag und ein Zertifikat, das auf genau diesen Namen ausgestellt ist, sind das unterstützte Paar. Alles andere ist ein Workaround, der an Nutzer ausgeliefert wird.

Eine Zeitüberschreitung ist eine Frage des Pfads, nicht des Namens

NSURLErrorTimedOut bedeutet, dass der Name aufgelöst wurde und nichts geantwortet hat, was auf die Route, die Paketrichtlinie oder den Dienst deutet. Wenn der Tunnel pro Anwendung zugewiesen wird, sagt eine andere App, die denselben Server erreicht, nichts über Ihren Build aus, weil diese Zuordnung nicht geteilt wird. Prüfen Sie, ob das Bundle, das Sie ausführen, innerhalb dieser Zuweisung liegt, und prüfen Sie dann, ob der Dienstpfad dafür erlaubt ist. Ein Entwicklungs-Build, der außerhalb der Zuweisung installiert ist, kann vollständig außerhalb des Tunnels liegen und wie eine defekte API aussehen.

Ein Browser-Vergleich zeigt, dass irgendeine App auf dem Gerät einen Pfad hat. Er beweist nie, dass Ihr Build ihn hat, weshalb die beiden Tests getrennt ausgeführt werden müssen.

Vertrauensfehler drehen sich um den Namen auf dem Zertifikat

NSURLErrorServerCertificateUntrusted bedeutet zusammen mit dem darunterliegenden TLS-Fehler, dass die Kette oder die Identitätsprüfung fehlgeschlagen ist. Eine interne CA muss auf dem Gerät vertraut sein, und ein Zertifikat, das für einen anderen Hostnamen ausgestellt wurde, bleibt nach jeder noch so umfangreichen Netzwerkumkonfiguration falsch. Apples Leitfaden zur App Transport Security gilt weiterhin für diese URL-ladenden Verbindungen, und ein Tunnel um einen reinen HTTP-Dienst macht diesen Dienst nicht durchgängig sicher.

Beheben Sie die Identität oder den Vertrauensanker und halten Sie die Ausnahmeliste leer. Eine pauschale Ausnahme für beliebiges Laden verbirgt den Fehler während der Entwicklung und bleibt danach für jeden Nutzer bestehen.

Eine HTTP-Ablehnung gehört zur App, nicht zum Netzwerk

Ein 401 oder 403 nach einem abgeschlossenen Handshake bedeutet, dass die Anfrage ankam und der Dienst sie abgelehnt hat; die verbleibende Frage ist also ein Konto, eine Token-Zielgruppe, ein Scope oder ein Schlüssel. Protokollieren Sie den Statuscode und den Hostnamen, niemals das Bearer-Token oder den Antworttext. Zu diesem Zeitpunkt erledigt der Tunnel seine Aufgabe, und weitere Netzwerkänderungen verzögern nur die eigentliche Lösung.

Die Tabelle ist die Einordnung, die neben dem Terminal bleiben sollte: eine Zeile pro Fehler, den die App tatsächlich melden kann. Geben Sie den Code aus, bevor Sie ihn lesen, denn die Zeile, die Sie wählen, entscheidet, welchen Abschnitt Sie durcharbeiten.

Jede Zeile ist billiger zu testen als die darunter, und jede schließt eine andere Ebene derselben Anfrage aus. Arbeiten Sie die Tabelle nach unten durch, bis eine Zeile passt, und hören Sie dann auf, das Netzwerk zu ändern.