Cara membaca keadaan VPN dan proksi untuk apl kerja terurus

Apl kerja gagal pada telefon terurus, seseorang menyemak togol VPN, melihatnya dihidupkan dan mengisytiharkan laluan sihat. Di sinilah kebanyakan diagnosis ini berhenti, dan ia terlalu awal: pengangkutan VPN aktif tidak bermakna permintaan apl ini menggunakannya, dan proksi yang benar-benar digunakan mungkin mengikut apl atau dipilih oleh fail PAC dan bukannya dipaparkan dalam Tetapan. Mulakan dengan apl dan profil tertentu yang anda nyahpepijat, kemudian baca pandangan platform itu sendiri tentang laluan.

Mulakan dengan apl dan profilnya

Apl berlencana kerja biasanya berjalan dalam profil berasingan dengan dasar rangkaiannya sendiri. Pelayar peribadi pada telefon yang sama bukan buktinya, dan hasil daripada peranti rakan sekerja dengan pengurusan berbeza juga bukan. Catat profil mana apl itu milik sebelum anda membaca apa-apa.

Dalam Tetapan, senaraikan entri VPN yang dikonfigurasikan dan catat siapa pemilik setiap satu. Pada binaan Samsung, label menu berubah antara keluaran, jadi huraikan entri itu dan bukan laluan ke sana. Entri kelabu atau terurus milik sesiapa yang mentadbir peranti; mematikannya sebagai eksperimen mengubah perkara yang anda cuba ukur dan mungkin bertentangan dengan dasar.

Baca keadaan yang dilaporkan platform

Di dalam aktiviti sedia ada dalam alat sokongan anda, pada API 23 atau lebih baru, keadaan rangkaian boleh dibaca tanpa menghantar satu bait. Panggilan itu memerlukan kebenaran manifes biasa ACCESS_NETWORK_STATE untuk bacaan keupayaan.

val cm = getSystemService(android.net.ConnectivityManager::class.java) ?: return
val network = cm.activeNetwork
val caps = network?.let { cm.getNetworkCapabilities(it) }
val hasVpn = caps?.hasTransport(android.net.NetworkCapabilities.TRANSPORT_VPN)
val proxy = cm.defaultProxy

Setiap nilai menjawab soalan yang sempit. Rangkaian aktif ialah rangkaian lalai bagi proses pemanggil pada saat itu. Semakan keupayaan memberitahu anda sama ada rangkaian lalai itu disokong VPN. Panggilan proksi melaporkan proksi HTTP lalai yang berkesan, dan objek yang dikembalikan boleh menerangkan sama ada proksi statik atau skrip PAC.

Jika anda memerlukan paparan setiap rangkaian dan bukannya lalai, baca sifat pautan rangkaian yang sama dan bandingkan dengan cm.getLinkProperties(network)?.httpProxy. Proksi yang dipasang oleh pengurusan peranti muncul dalam panggilan proksi lalai dan bukan dalam sifat pautan, yang merupakan cara cepat untuk membezakan proksi yang dibekalkan dasar daripada yang diberikan rangkaian.

Simpan output dalam saluran sokongan anda dan bukannya dalam laporan awam. Nama hos proksi, URL PAC dan akhiran dalaman mendedahkan cara organisasi anda menghalakan trafik, dan tiada satu pun daripadanya diperlukan untuk menerangkan kegagalan.

Tafsirkan setiap medan secara sempit

Rangkaian nol atau objek keupayaan nol bermakna keadaan rangkaian pemanggil tidak tersedia atau berubah semasa bacaan. Ia tidak bermakna tiada VPN. Anggapnya sebagai tidak diketahui dan baca semula selepas apl berada di latar depan, bukan sebagai hasil negatif.

Pengangkutan VPN ialah yang paling lemah antara yang positif. Mana-mana apl yang memegang VpnService menghasilkan satu, termasuk apl penapisan setempat yang tidak pernah menghantar trafik anda ke mana-mana. Jadi nilai true mengatakan rangkaian lalai yang disokong VPN wujud, bukan bahawa pintu keluar organisasi anda digunakan dan pastinya bukan bahawa pemeriksaan berlaku.

Proksi lalai nol bermakna API ini tidak melaporkan proksi HTTP lalai untuk konfigurasi berkesan. Ia mengecualikan sangat sedikit: apl boleh membawa tetapan SOCKS sendiri, melaksanakan klien HTTP sendiri, atau dipandu oleh proksi di pintu masuk yang tidak pernah diketahui peranti.

PAC ialah kes yang mengalahkan jawapan satu nilai. Skrip boleh menghalakan satu destinasi melalui proksi dan menghantar satu lagi secara langsung, jadi dua permintaan daripada apl yang sama dalam satu saat boleh mengambil laluan berbeza. Dan apl yang mengikat soketnya pada rangkaian terpilih, atau memanggil bindProcessToNetwork, tidak wajib mengikut lalai sama sekali.

Apa yang tidak dapat diberitahu oleh petikan ini

Ini bukan sejarah. Tiada apa di sini merekodkan laluan mana yang diambil oleh permintaan yang gagal, dan bacaan berjaya selepas kegagalan bukan bukti tentang kegagalan. Ia juga bukan inventori: anda mendapat rangkaian lalai proses pemanggil, bukan senarai sambungan peribadi setiap apl.

Ia juga tidak mengatakan apa-apa tentang apa yang berlaku di atas soket. Jabat tangan TLS yang gagal pada peranti terurus mungkin masalah stor kepercayaan, ketidakpadanan pinning atau nama yang ditolak proksi, dan tiada satu pun muncul dalam bacaan kesambungan.

Itulah sebabnya kedua-dua bahagian penting bersama: petikan mempersempitkan tempat untuk melihat, dan diagnostik apl itu sendiri mengatakan apa yang sebenarnya gagal.

Laporkan dalam bentuk yang boleh digunakan pentadbir

Berikan apl terjejas, profil, cap masa dan peringkat tepat yang gagal: penyelesaian nama, sambungan TCP, jabat tangan TLS atau status HTTP. Tambahkan nilai petikan seperti yang dibaca, dengan nol ditulis sebagai nol dan bukan sebagai tiada. Catat sama ada apl lain dalam profil yang sama gagal dengan cara yang sama, yang memisahkan masalah apl daripada masalah laluan seluruh profil.

Kemudian berhenti dan biarkan pemilik laluan menjawab. Jangan anggap sijil korporat, alamat proksi atau entri VPN sebagai kebenaran untuk membuang pengurusan atau memintas laluan yang diluluskan; itu menjadikan kes sokongan kepada insiden dasar.

Kontrak proksi lalai adalah pendek dan wajar dibaca sekali, kerana ia mentakrifkan dengan tepat proksi mana yang dilaporkan oleh panggilan itu, dan setiap bacaan berlebihan petikan ini bermula dengan andaian bahawa ia melaporkan lebih banyak.