Android VPN marşrutlaşdırması: main cədvəlindən əvvəl siyasət qaydaları

Android-də main cədvəlinə əlavə edilmiş marşrut hər siyahıda düzgün görünür və yenə də trafiki daşımır. Səbəb budur ki, main cədvəli bir neçə variantdan biridir və ona ilk növbədə müraciət edilmir. Android-in şəbəkə xidməti marşrutlaşdırma cədvəlini təyin məntəqəsi ünvanında olmayan məlumatla seçən siyasət qaydaları qurur — tətbiqin uid-i, paket üzərindəki işarə, paketin gəldiyi interfeys — və təyin məntəqəsi axtarışı sonra, həmin qaydaların seçdiyi cədvəlin içində baş verir.

Sabit ardıcıllıqla üç qərar

Çıxan paket üç ayrı qərar verir. Birincisi, siyasət qaydası hansı marşrutlaşdırma cədvəlinin tətbiq olunduğunu müəyyən edir. İkincisi, həmin cədvəlin içindəki marşrut növbəti hopu və çıxış interfeysini müəyyən edir. Üçüncüsü, netfilter qarmaqları paketin qalıb-qalmadığını, dəyişdirildiyini və ya yönləndirildiyini müəyyən edir.

Sıra vacibdir, çünki hər mərhələ yalnız öz sualına cavab verə bilər. Paketi qəbul edən firewall qaydası cədvəl seçmir, heç bir qaydanın seçmədiyi cədvələ əlavə edilmiş marşrut isə fəaliyyətsizdir. Android VPN-ləri ətrafındakı qarışıqlığın çoxu üçündən birini düzəltmək və heç bir dəyişiklik görməməkdən qaynaqlanır, çünki nasazlıq başqa birində idi.

İşarələr yığılmış sahədir, sənin sahib olduğun etiket deyil

Android bir neçə faktı eyni işarə dəyərində yığır: hansı şəbəkənin seçildiyi, tətbiqin şəbəkəni açıq şəkildə seçib-seçmədiyi, socket-in VPN-dən qorunub-qorunmadığı və icazə ilə bağlı bitlər. AOSP fwmark başlığı cari ağac üçün bu düzümü müəyyən edir və düzüm buraxılışlar arasında dəyişən platforma daxili detalıdır.

Buna görə də bütöv işarə dəyərini iptables -j MARK --set-mark ilə yazmaq Android-də təhlükəlidir. Bu, etiket əlavə etmir; sistemin artıq etdiyi şəbəkə seçimini əvəz edir. Sonra paket başqa qaydalara uyğun gəlir və bu, üzərinə yazılan bitlərdən asılı olaraq VPN-in işə başladığı, ya da əlaqəsiz bir tətbiqin bağlantını itirdiyi təəssüratı yarada bilər.

Əgər işarələrə toxunmalısansa, əvvəlcə cari dəyəri oxu və maska istifadə et ki, yalnız başa düşdüyün bitlər dəyişdirilsin:

ip rule show
ip route show table all | head -40
ip route get 10.20.4.11

Bağlantı işarəsi paket işarəsindən ayrı obyektdir və heç biri marşrut deyil. Cavab paketlərində işarəni bərpa etmək çıxışda cədvəl seçməkdən ayrı bir addımdır, buna görə də birtərəfli düzəlişlər açılıb sonra donan bağlantılar yaradır.

Qaydalara və cədvəllərə kim sahibdir

Android-in şəbəkə xidməti, netd, qaydaları və hər şəbəkə üçün cədvəlləri yaradır. AOSP RouteController VPN-lər, fiziki şəbəkələr və uid aralıqları üçün həmin qaydaların yığıldığı yerdir və onun həyat dövrü konfiqurasiya faylına deyil, şəbəkə hadisələrinə bağlıdır.

Bundan iki nəticə çıxır. Birincisi, bir telefonda tapdığın prioritetlər və cədvəl nömrələri interfeys deyil, build daxili detallarıdır: başqa Android versiyasında eyni görünən nömrələr tamamilə başqa şey ifadə edə bilər. İkincisi, şəbəkələr dəyişdikdə vəziyyət yenidən qurulur, buna görə də bu gün root shell-dən əlavə edilən qayda növbəti Wi-Fi keçidindən sonra yox ola bilər.

Bu itmə çox vaxt sistemin marşruta məhəl qoymaması kimi bildirilir. Əslində baş verən odur ki, cədvəli seçən qayda artıq mövcud deyil və cədvəlin içindəki marşrut paketin nöqteyi-nəzərindən əlçatmaz olur. İşləyən konfiqurasiya yenidən qoşulmadan sonra işləməyi dayandırdıqda marşrut siyahısına deyil, qayda siyahısına bax.

Qarmaq sırası suallarının universal cavabı yoxdur

iptables-ın VPN marşrutlaşdırmasından əvvəl işləyib-işləmədiyi sualına paket yolunu adlandırmadan cavab vermək olmaz. Lokal yaradılan paket output qarmağından keçir və burada işarə dəyişikliyi yenidən marşrutlaşdırma yoxlamasına səbəb olur — ikinci axtarış, birincinin geriyə dönük redaktəsi deyil. Tetherinq müştərisindən gələn paket isə prerouting yolundan keçir və yönləndirilir, onu görən zəncirlər başqadır.

Yəni eyni qayda tətbiqin trafiki üçün effektiv, tetherinq trafiki üçün isə görünməz ola bilər və sıfırda qalan sayğac paketin hansı yolla getdiyini deyir, qaydanın səhv olub-olmadığını deyil. Hər hansı uyğunluq şərtini dəyişməzdən əvvəl sayğaclarla yolu müəyyən et.

Bu həm də siyasət marşrutlaşdırma səhvinin görünməz olduğu mərhələdir. Mövcud olan, lakin təyin məntəqəsini ehtiva etməyən cədvələ marşrutlaşdırma firewall drop-una bənzəyən şəbəkə əlçatmazlığı yaradır, firewall drop-u isə marşrutlaşdırma qara dəliyinə bənzəyən timeout yaradır.

Sistemin içində diaqnoz qoy, ya da ona toxunma

Avtorizə edilmiş yoxlama üçün hər şeyə toxunmazdan əvvəl dörd faktı müəyyən et: tətbiqin uid-i və profili, Android-in onun üçün seçdiyi şəbəkə, VPN-in o tətbiqi ümumiyyətlə əhatə edib-etmədiyi və problemin hər iki ünvan ailəsində olub-olmadığı. Hər tətbiq üzrə istisna heç bir marşrutlaşdırma nasazlığı olmadan bir çox VPN işləmir hesabatını izah edir.

Sonra faktiki qüvvədə olan qaydaları, maskaları və cədvəlləri oxu və müşahidə pəncərəsi içində şəbəkə keçidi saxla. Davranış yenidən qoşulma boyunca dəyişirsə, sən idarə olunan həyat dövrünə baxırsan, itkin marşruta deyil.

Adi tələblər üçün dəstəklənən idarəetmə vasitələrindən istifadə et: hər tətbiq üzrə daxil etmə və istisna VPN tətbiqində və xüsusi yol tələb edən hər şey üçün platformanın öz şəbəkə seçimi. Əgər imtiyazlı inteqrasiya həqiqətən marşrutlaşdırma mexanizmi ilə əməkdaşlıq etməlidirsə, dəstəklədiyin dəqiq Android versiyasının tətbiqini hədəflə və onun həyat dövrünü ona sahib olan komponent vasitəsilə saxla. Platforma zəncirlərini boşaltmaq və ya yüksək prioritetli qayda əlavə etmək diaqnozu ikinci şəbəkə menecerinə çevirir və telefon da ona uyğun davranır.