Android-dən VPN profilinin ixracı ehtiyat nüsxə addımı kimi görünür və bu menyu belə təəssüratı düzəltmək üçün heç nə etmir. Əlinizdə qalan şey parser girişi, əməliyyat sisteminin heç vaxt qaytarmaya biləcəyi açar və məhz həmin telefona verilmiş avtorizasiyadır. Bu üçünü ayırın və faydalı sual ortaya çıxır: yeni cihazda hansı hissə hələ də çatışmır?

Fayl asan hissəsidir. Digər ikisi miqrasiyanın işləyib-işləmədiyini müəyyən edir.

İxrac edilmiş profildə həqiqətən nə var

Faylı açmazdan əvvəl onu mətn redaktorunda açın. OpenVPN profili kiçik konfiqurasiya dilidir: remote, proto, data-ciphers və çox vaxt müştərinin TLS yığınına verdiyi daxili <ca>, <cert>, <key> və ya <tls-crypt> blokları. WireGuard konfiqurasiyası daha sadədir: [Interface] içində PrivateKey və Address daşıyır, sonra hər son nöqtə üçün bir [Peer] PublicKey, AllowedIPs və Endpoint daşıyır. IKEv2 isə açar blokları əvəzinə yük lüğətləri olan .mobileconfig kimi gəlir.

Bu mətnin heç biri təkbaşına etimadnamə deyil. Etimadnamə şəxsi açardır və hər format onu ya daxildə yapışdırır, ya da yalnız onu yaradan müştərinin içində həll olunan ləqəbə işarə edir.

Açar Android-də həqiqətən harada yaşayır

Android tətbiq məlumatlarını /data/data/<package> altında saxlayır və onu yalnız həmin tətbiqin UID-i oxuya bilər. Root edilməmiş telefondan başqa tətbiqin şəxsi qovluğunu kopyalamağın dəstəklənən yolu yoxdur və Android 12 bunu ləğv etdikdən və müştərilər allowBackup="false" elan etməyə başladıqdan sonra adb backup ümumi cavab olmaqdan çıxdı. Beləliklə, Android müştərisindən ixrac həmin müştərinin nə tətbiq etdiyi deməkdir, fayl sistemi kopyası deyil.

Şəxsiyyət qatı tətbiqin altındadır. Əgər müştəri açarınızı Android Keystore-a idxal edibsə, material orada yaradılır və ya sarılır və sonrakı ixraclar baytların əvəzinə Keystore ləqəbinə istinad daşıya bilər. Aparatla dəstəklənən açarlar elə qurulub ki, hətta sahib tətbiq belə onları oxuya bilmir, Keystore documentation bunu təsvir edir, buna görə həmin ləqəbə işarə edən profil eyni telefonda təmiz idxal olunur, hər yerdə isə uğursuz olur.

Bu pozulmuş ixrac deyil. Bu, platformadan tələb olunan xüsusiyyətdir.

Profilin keçirə bilmədiyi şeylər

Obyektləri hədəfin qəbul edəcəyi ilə müqayisə edin:

ObyektKeçir?Nə üçün
Protokol və son nöqtəBəli, hədəf müştəri onu dəstəkləyirsəProfildə adi mətn
CA sertifikatı və host adı yoxlamasıAdətənAçıq material, lakin host adı yenə də sertifikata uyğun olmalıdır
Müştəri sertifikatıBəli, cihaz üzrə bağlanmayıbsaSertifikatlar daşına biləndir; birinin neçə cihazda istifadə oluna biləcəyini verən tərəf müəyyən edir
Şəxsi açarYalnız Keystore-dan kənarda yaradılıbsaAparatla dəstəklənən açarlar ixrac oluna bilməz, yalnız dəyişdirilə bilər
Hesab, MFA, SSO sessiyasıXeyrTokenlər vaxtı bitir və onları alan cihaza bağlı qalır
Marşrutlar, DNS və tətbiq əhatəsiYalnız konfiqurasiya mətni kimiAndroid onları qoşulma zamanı VpnService.Builder vasitəsilə tətbiq edir
Split-tunnel tətbiq siyahısıNadir hallardaPaket adları cihazlar arasında fərqlənir və siyahı müştəri vəziyyətidir

İki sətir qarışıqlığın çoxunu yaradır. Cihazda yaradılan və ixrac edilə bilməyən kimi işarələnən açar həqiqətən tətbiq məlumatları ilə birlikdə yox olur, buna görə əvəz yeni açar və ona verilən sertifikatdır. Yeni telefona kopyalanan sessiya tokeni adətən ilk yeniləmədə ölür və bu, uğursuz idxal kimi görünür.

İdxal əvvəlcə təhlil, sonra razılıq sorğusudur

Qəbul edən tərəfdə idxal təhlildən sonra icradır. Müştəri konfiqurasiyanı oxuyur, istinad edilən hər blokun mövcud olduğunu yoxlayır, sonra tunel tərifini öz sandbox-ına yazır; buna görə Daxilolmalar qovluğundan seçdiyiniz fayl sonradan qoşulan şey deyil.

Sonra heç bir faylın keçə bilmədiyi avtorizasiya addımı gəlir. Android tətbiqin VpnService.prepare() çağırmasını və tunel qurmazdan əvvəl sizin razılığınızı almasını tələb edir, buna görə yeni idxal edilmiş profil sistem dialoqunu yenə də bir dəfə göstərir. Sonra tunel açıq şəkildə addAddress, addRoute, addDnsServer və hər tətbiq üçün addAllowedApplication və ya addDisallowedApplication vasitəsilə qurulur. Bunların heç biri son nöqtədən irəli gəlmir, buna görə eyni profil iki müştəridə fərqli effektiv marşrut dəsti yarada bilər.

Sertifikata əsaslanan qurğular daha bir çəngəl əlavə edir. Server müəyyən cihaza sertifikat verdikdə, MDM və SCEP qeydiyyatı kimi, onu ikinci telefonda təkrar istifadə ya server hər şəxsiyyət üçün bir sessiya tətbiq edənə qədər işləyir, ya da TLS əl sıxma mərhələsində uğursuz olur. Təkrar istifadəni planlaşdırmazdan əvvəl verən tərəfin siyasətini yoxlayın.

Köhnəni təqaüdə çıxarmazdan əvvəl yeni cihazı yoxlayın

Yeni telefon yaşıl ikonadan daha yaxşı bir şeyi keçənə qədər köhnə telefonu qoşulu saxlayın. Yeni cihazdan çıxış ünvanını və onun həqiqətən istifadə etdiyi DNS həlledicisini təsdiqləyin. Əgər split tunneling vacibdirsə, tuneldən yan keçməli olan bir tətbiqi və keçməməli olan birini işə salın, sonra hansının provayderinizə çatdığına baxın.

Bir yoxlama çıxış ünvanını həll edir. Telefon brauzerində https://ifconfig.me açın, sonra eyni Wi-Fi şəbəkəsindəki noutbukdan curl -s https://ifconfig.me işə salın və hər iki cavabı provayderinizin təyin etdiyi ünvanla müqayisə edin.

Yalnız bundan sonra köhnə şəxsiyyəti təqaüdə çıxarın və bunu verən tərəf vasitəsilə edin: sertifikatı ləğv edin və ya cihazı hesabdan çıxarın. Daxilolmalar qovluğundan fayl silmək heç nəyi bitirmir, çünki eyni sertifikatı daşıyan iki cihaz server jurnalında eyni görünür.

Əgər ixrac daşınmaz olarsa, düzəliş açıq konfiqurasiya paketi deyil, yeni qeydiyyatdır. İkinci cihaz profili istəyin və ya yeni telefonda açar cütünü yaradıb CSR təqdim edin; daha yavaşdır və verən tərəfin dəstəklədiyi yoldur.

Nəyisə silməzdən əvvəl yoxlama siyahısını keçin: yeni cihaz qoşulur, çıxış ünvanı və DNS uyğundur, hər tətbiq əhatəsi nəzərdə tutduğunuz kimidir, köhnə şəxsiyyət ləğv edilib və saxladığınız hər hansı konfiqurasiya faylı şifrələnmiş yaddaşdadır.

Əlaqəli məqalələr