Android OpenVPN: telefonu root etmədən özəl marşrut əlavə etmək

Hazırda profildə olmayan bir özəl alt şəbəkə lazımdır, məsələn 10.60.0.0/24. Noutbukda marşrut əlavə edib davam edərdiniz. Android-də VPN tətbiqdir, tun qurğusu həmin tətbiqə aiddir və root olmadan redaktə edə biləcəyiniz marşrut cədvəli yoxdur. Marşrut yenə də mövcud olmalıdır, lakin müştərinin yüklədiyi profilə daxil olur və yalnız qarşı tərəf razılaşsa işləyir. Budur düzəliş, yenidən qoşulma, server tərəfi və geri qaytarma.

Düzəlişdən əvvəl: marşrut nə edə bilər, nə edə bilməz

Marşrut bir suala cavab verir: bu təyinat üçün trafiki hansı interfeys daşımalıdır. Heç bir icazə vermir. Şəbəkə sahibi bu telefonun həmin alt şəbəkəyə çıxmasına razı deyilsə, düzgün marşrut düzgün görünən konfiqurasiya və şlüzə səssiz itki yaradır, siz isə növbəti saatı səhv faylı redaktə etməklə keçirirsiniz.

Əvvəlcə həmin razılığı alın, şəbəkənin sahibi varsa yazılı şəkildə. Sonra nə etmədiyinizi qeyd edin: telefonu həmin LAN daxilində ünvanla təmin etmirsiniz, serverin dinləyicisini dəyişmirsiniz və host adı ilə sayt seçmirsiniz. Bunlar dörd fərqli dəyişiklikdir və yalnız birincisi sizindir.

Müştərinin həqiqətən yüklədiyi profili redaktə edin

Adi OpenVPN seçim mətnini idxal edən uyğun müştəri üçün əlavə bir sətirdir:

route 10.60.0.0 255.255.255.0

Onu profil gövdəsinə, digər marşrut direktivlərinin yanına əlavə edin; operatorun son nöqtəsini, sertifikatları, açar idarəetməsini və yoxlama sətirlərini olduğu kimi saxlayın. Bir sətir götürmək üçün köhnə nümunənin hamısını yapışdırmayın: sıxılma, mütləq fayl yolları və köhnəlmiş şifrə parametrləri onunla gəlir və sizə ayrı bir sazlama sessiyası baha başa gəlir.

İnsanların qaçırdığı addım faylın sahibliyidir. Tətbiq profili idxal edibsə, istifadə etdiyi nüsxə tətbiqindir və endirdiyiniz orijinalı redaktə etmək heç nəyi dəyişmir. Müştərinin dəstəklədiyi redaktordan istifadə edin və ya düzəliş edilmiş faylı yeniləmə yolu ilə yenidən idxal edin, oxşar adlar çox olduqda aktiv profilin adını təsdiqləyin. Hansını dəyişdiyinizi qeyd edin.

Profil artıq route-nopull daşıyırsa, serverdən heç bir marşrut quraşdırılmır və telefonun ehtiyac duyduğu hər prefiks açıq şəkildə sadalanmalıdır. Bu qanuni dizayndır, amma bu o deməkdir ki, buraxılmış sətir serverin imtinası kimi görünür.

Yenidən qoşulun və cihazda yoxlayın

Əvvəlcə bağlantını kəsin, sonra tətbiqin son sessiyanı bərpa etməsinə imkan vermək əvəzinə düzəltdiyiniz konkret profilə yenidən qoşulun. Bağlantı jurnalını açın və müştərinin yeni sətri oxuduğunu təsdiqləyin; ön hissənin nəzərə almadığı marşrut direktivi səhv nüsxəni redaktə etməyin adi nəticəsidir.

Təyinatı adla deyil, ünvanla sınayın. Bir tanınmış xidmət portuna TCP yoxlaması ping-dən daha çox məlumat verir, çünki bir çox host ICMP-yə cavab verir, xidmət portu isə filtrlənir. Ünvan cavab verir, ad vermirsə, marşrut deyil, həlledici sualınız var və növbəti bölmə sizin üçün deyil.

Buraya iki əhatə yoxlaması da aiddir. Per-app VPN o deməkdir ki, ünvan marşrutu mövcud ola bilər, sınadığınız tətbiq isə daxil edilmiş çoxluqdan kənardadır, yəni həqiqətən içəridə olan tətbiqlə sınayın. IPv4 prefiksi IPv6 yolu haqqında heç nə demir; xidmət iki stack-lidirsə, uyğun IPv6 marşrutunu əlavə edin və ya müştərinin nəzərdə tutmadığınız yolu seçməsini gözləyin.

Bir mənfi nəticəni erkən tanımağa dəyər: tam tunel marşrutu artıq 0.0.0.0/0 əhatə edirsə, prefiks çatmır deyil və onu yenidən əlavə etmək heç nəyi dəyişmir. İkiqat əhatə server tərəfindəki imtinanı və ya itkin cavabı düzəltmir.

Yolu serverdə tamamlayın

Telefondan kənarda üç şey doğru olmalıdır. Şlüzün təyinat üçün marşrutu və telefonun mənbəyini oraya yönləndirmə icazəsi olmalıdır. Hədəf həmin mənbəni qəbul etməli və cavabları şlüzdən geri qaytarmalıdır, əks halda dizayn çıxışda qəsdən tərcümə tələb edir. OpenVPN təlimatının marşrut seçimi müştəri tərəfinin direktivini əhatə edir; yönləndirmə və geri marşrutu ayrı maşınlarda ayrı parametrlərdir.

Təyinat birbaşa şlüzün arxasında deyil, başqa VPN müştərisinin arxındadırsa, serverə həmin peer-in alt şəbəkəsi üçün iroute lazımdır. Bu direktiv serverə aiddir və hansı müştərinin prefiksə sahib olduğunu təsvir edir; telefon bunu öz profilindən verə bilməz və müştəri tərəfindəki heç bir düzəliş onu əvəz etmir.

Geri yolu açıq şəkildə yoxlayın. Tuneldən deyil, default marşrutdan çıxan cavab klassik yarım-açıq simptomu yaradır: əlaqə bir istiqamətdə qurulur və heç nə geri qayıtmır. Hədəf geri marşrut qura bilmirsə, şlüzdə mənbə tərcüməsi qanuni həlldir, lakin bu, öz nəticələri olan siyasət qərarıdır.

Geri qaytarma və qəbul

Redaktə etməzdən əvvəl əvvəlki profili saxlayın. Dəyişiklik vəziyyəti pisləşdirsə, həmin nüsxəni eyni yenidən idxal yolu ilə bərpa edin, yenidən qoşulun və köhnə davranışın qayıtdığını təsdiqləyin; bu, düşündüyünüz şeyi dəyişdiyinizi təsdiqləyir. Köhnə vəziyyəti bərpa etməyən geri qaytarma, tətbiqin hələ tapmadığınız üçüncü nüsxə saxladığı deməkdir.

Dəyişikliyi dörd şərt yerinə yetdikdə qəbul edin, təzə yenidən qoşulmadan sonra bu sıra ilə sınanır: təyinat xidmət portunda cavab verir, xüsusi ad gözlənilirsə həll olunur, HTTPS hədəflənən host adını hələ də təsdiqləyir və hər şey yenidən başlatmadan və ya Wi-Fi-dan mobil şəbəkəyə keçiddən sonra da işləyir. Son yoxlama Android tuneli yenidən qurana qədər mövcud olan marşrutu tutur.

• Redaktə etməzdən əvvəl şəbəkə sahibinin təyinat icazə verdiyini təsdiqləyin.
• Marşrutu müştərinin yüklədiyi profilə qoyun, sonra yenidən idxal edin və qoşulun.
• Xidmət portu ilə, per-app əhatə daxilində, düzgün ünvan ailəsi üçün yoxlayın.
• Yönləndirməni, geri marşrutu və iroute-u telefonda deyil, serverdə düzəldin.
• Geri qaytarma nüsxəsi saxlayın və yenidən başlatmadan sonra yenidən sınayın.