Cara memanggil API internal dari aplikasi iPhone lewat VPN

API menjawab di Safari pada ponsel yang sama, sementara permintaan aplikasi berakhir dengan batas waktu. Celah itu biasanya bukan tunnel: aplikasi yang memanggil layanan internal membuat permintaan HTTPS biasa, dan VPN yang sudah ada di perangkat hanya menentukan apakah permintaan itu punya jalur. Menulis tunnel kedua ke dalam aplikasi adalah keputusan produk, bukan perbaikan untuk batas waktu. Berikut ini mengklasifikasikan kegagalan menurut tempat terjadinya, memakai permukaan kesalahan yang sudah dimiliki aplikasi.

Mulai dari kesalahan, bukan dari tunnel

URLSession melaporkan kegagalan transport sebagai NSError nilai di NSURLErrorDomain, dan kode itu adalah bukti termurah yang tersedia. Sebelum mengubah konfigurasi apa pun, catat kode tersebut bersama nama host yang gagal dan waktu yang telah berlalu untuk tugas itu. Batas waktu, kegagalan nama, dan kegagalan kepercayaan terlihat sama di layar dan menuntut tiga perbaikan berbeda. Klasifikasikan dulu, lalu baca bagian untuk kelas itu.

Metrik tugas menjawab pertanyaan lanjutan, apakah koneksi pernah terbentuk, yang memisahkan permintaan yang tidak pernah punya rute dari permintaan yang terlalu lama dijawab server. Tidak ada satu pun dari ini yang membutuhkan perubahan tunnel; yang dibutuhkan adalah mencetak diagnostik permintaan itu sendiri di tempat yang bisa Anda baca.

Resolusi nama gagal sebelum hal lain bisa terjadi

Nama kantor pendek seperti api.corp.example biasanya bergantung pada domain pencarian yang tidak dibawa ponsel, sehingga aplikasi me-resolve nama yang hanya ada di dalam gedung. NSURLErrorCannotFindHost adalah tanda tangan. Nama host lengkap harus di-resolve melalui resolver apa pun yang dipasang VPN, dan aplikasi sebaiknya meminta bentuk yang sepenuhnya memenuhi syarat setiap kali domain pencarian tidak dijamin. Menukar nama dengan alamat dan mematikan pemeriksaan sertifikat memindahkan kegagalan, bukan memperbaikinya.

Catatan DNS privat dan sertifikat yang diterbitkan untuk nama persis itu adalah pasangan yang didukung. Segala hal lain adalah akal-akalan yang sampai ke pengguna.

Batas waktu adalah pertanyaan jalur, bukan pertanyaan nama

NSURLErrorTimedOut berarti nama berhasil di-resolve dan tidak ada yang menjawab, yang menunjuk ke rute, kebijakan paket, atau layanan. Saat tunnel ditetapkan per aplikasi, aplikasi lain yang mencapai server yang sama tidak mengatakan apa pun tentang build Anda, karena pemetaan itu tidak dibagi. Periksa bahwa bundel yang Anda jalankan berada di dalam penetapan itu, lalu periksa bahwa jalur layanan diizinkan untuknya. Build pengembangan yang dipasang di luar penetapan bisa berada sepenuhnya di luar tunnel dan tampak seperti API yang rusak.

Perbandingan di peramban menunjukkan bahwa salah satu aplikasi di perangkat punya jalur. Itu tidak pernah membuktikan bahwa build Anda punya, karena itu kedua pengujian harus dijalankan terpisah.

Kegagalan kepercayaan berkaitan dengan nama pada sertifikat

NSURLErrorServerCertificateUntrusted bersama kesalahan TLS di bawahnya berarti rantai atau pemeriksaan identitas gagal. CA internal harus dipercaya di perangkat, dan sertifikat yang diterbitkan untuk nama host lain tetap salah setelah konfigurasi ulang jaringan sebanyak apa pun. panduan App Transport Security tetap berlaku untuk koneksi pemuat URL ini, dan tunnel di sekitar layanan HTTP biasa tidak membuat layanan itu aman dari ujung ke ujung.

Perbaiki identitas atau jangkar kepercayaan dan biarkan daftar pengecualian kosong. Pengecualian menyeluruh untuk pemuatan sembarangan menyembunyikan kegagalan selama pengembangan dan membiarkannya tetap ada bagi setiap pengguna sesudahnya.

Penolakan HTTP milik aplikasi, bukan milik jaringan

401 atau 403 pada handshake yang selesai berarti permintaan sampai dan layanan menolaknya, jadi pertanyaan yang tersisa adalah akun, audiens token, cakupan, atau kunci. Catat kode status dan nama host, jangan pernah mencatat token pembawa atau isi respons. Pada titik itu tunnel menjalankan tugasnya dan perubahan jaringan lebih lanjut hanya menunda perbaikan sebenarnya.

Tabel itu adalah klasifikasi yang sebaiknya disimpan di samping terminal: satu baris per kegagalan yang benar-benar bisa dilaporkan aplikasi. Cetak kodenya sebelum Anda membacanya, karena baris yang Anda pilih menentukan bagian mana yang Anda kerjakan.

Setiap baris lebih murah diuji daripada baris di bawahnya, dan masing-masing menyingkirkan lapisan berbeda dari permintaan yang sama. Telusuri tabel ke bawah sampai ada baris yang cocok, lalu berhenti mengubah jaringan.