Android VpnService icazə siyahısı: icazə verilən səhifələr niyə hələ də donur

Bir domeni icazə siyahısına əlavə etdiniz, sorğu tətbiqinizə çatdı, uyğunlaşdırıcı icazə verildi cavabı qaytardı, amma səhifə yenə heç vaxt yüklənmir. Bu nöqtədə çoxu uyğunlaşdırıcını yenidən yazmağa və əvəzedici simvollarla müqayisə əlavə etməyə başlayır. Təcrübəmdə uyğunlaşdırıcı adətən düzgün olur, nasazlıq isə bir qat sonra yerləşir: sintez etdiyiniz DNS cavabında, quraşdırdığınız marşrutda və ya sorğunu ötürmək üçün istifadə etdiyiniz soketdə. Siyahı asan hissədir; paket yolu icazə siyahılarının qırıldığı yerdir.

Uyğunlaşdırıcı nadir hallarda günahkardır

İlk ayırmalı olduğunuz şey bloklanmış və pozulmuş anlayışlarıdır. Bloklanmış ad tez və görünən şəkildə uğursuz olmalıdır, çünki brauzer adın mövcud olmadığını bildirən cavab alır və dayanır. Pozulmuş ad donur, IPv6 üzərindən yenidən cəhd edir, başqa nəqliyyat növünə keçir və sizi fırlanan göstərici ilə qoyub gedir. Fırlanan göstərici görürsünüzsə, icazə siyahınız çox güman ki, müştərinin istifadə edə bilməyəcəyi bir cavab verir.

Boş A qeydi klassik səhvdir. Sıfır cavabla NOERROR qaytarmaq etibarlı cavab kimi görünür, ona görə stub resolver onu qəbul edir, brauzer yenidən cəhd edir, AAAA yoxlayır, başqa resolver yoxlayır və çox sonra əl çəkir. Cavab kodu 3, yəni NXDOMAIN, sual bölməsi təkrarlandıqda və tranzaksiya ID-si kopyalandıqda söhbəti dərhal bitirir. Bilərəkdən rədd etdiyiniz hər ad üçün ondan istifadə edin.

IPv6 da standart yerinə eyni qərarı haqq edir. Əgər A üçün NXDOMAIN cavabı verib AAAA-nı buraxırsınızsa, müştəri bloklanmış ada IPv6 üzərindən çata bilər və filtr sızır. Bəzi tətbiqlər bloklanmış AAAA sorğularına loopback ünvanı ilə cavab verir ki, əlaqə alternativə keçmək əvəzinə dərhal uğursuz olsun. Bir siyasət seçin, onu hər iki qeyd növünə tətbiq edin və hər ikisini jurnala yazın.

Hər şeyi tutan marşrut hər şeyə sahib olur

Yalnız DNS üzərində qurulmuş dizayn heç vaxt addRoute("0.0.0.0", 0) əlavə etmir, buna görə TUN interfeysinə yalnız sorğular daxil olur, qalan hər şey əsas şəbəkədən istifadə etməyə davam edir. Bu təhlükəsiz formadır və bəzi icazə siyahılarının niyə Wi-Fi-da işləyib mobil şəbəkədə uğursuz olduğunu da izah edir.

Standart marşrut yaranan anda hər axın sizin olur. İnterfeysə gələn və nə ötürülən, nə də cavablandırılan TCP paketi müştərinin vaxtı bitənə qədər növbədə qalır və jurnala yazılacaq heç bir xəta yoxdur, çünki heç nə xəta verməyib. Birinin bütün günortanı əslində 443 portu üçün ötürücünün olmaması olan pozulmuş icazə siyahısı üzərində keçirdiyini görmüşəm. Atmağa qərar verdiyiniz hər paketin protokolunu və təyinatını jurnala yazın.

Resolver soketi tuneldən çıxmalıdır

Ötürmə növbəti tələnin yerləşdiyi mərhələdir. Operator resolverləri çox vaxt tunelin çata bilmədiyi özəl ünvanda yaşayır, buna görə ötürdüyünüz sorğu heç yerə getmir və tətbiq oxuma vaxtının bitməsini bildirir. Təsdiqlənmiş sorğuları çata bildiyini dəqiq bildiyiniz resolverə göndərin və həmin soketi əvvəlcə VpnService.protect() funksiyasına verin. Qorunmayan soket sorğunu öz tunelinizə geri göndərir, orada yenidən tətbiqə çatır və vaxt bitənə qədər dövr edir.

Uğursuzluq şəbəkə kəsilməsi ilə eyni görünür, buna görə xəta hesabatlarında bu qədər uzun yaşayır. Göndərilən sorğular və alınan cavablar üçün sayğaclar saxlayın: birinci rəqəm artır, ikinci sıfırda qalırsa, siz siyahıya deyil, soketə baxırsınız.

Ölçü və yoxlama cəmləri mesajsız uğursuz olur

Səssiz itkilər ölçüdən də qaynaqlanır. Böyük cavab dəsti olan DNS cavabı və ya geniş seçimlərlə TCP əl sıxma heç vaxt açıq şəkildə təyin etmədiyiniz yol MTU-nu keçə bilər; fraqment yuxarı axında yox olur və müştəri ya daha kiçiklə yenidən cəhd edir, ya da cəhdi dayandırır. İnterfeys MTU-nu 1280-ə qoymaq mobil şəbəkələrin çoxunda davam edən ehtiyatlı seçimdir və heç kimin ölçmədiyi standart dəyəri miras almaqdan açıq şəkildə təyin etmək daha yaxşıdır.

Paketləri özünüz qurursunuzsa, yoxlama cəmi digər səssiz qatildir. UDP uzunluğunu və ya protokol sahəsini kənarda qoyan psevdo-başlıq üzərindən hesablanmış UDP yoxlama cəmi sizin tərəfinizdə düzgün görünən, qəbul edən tərəfdə isə heç bir iz qoymadan atılan paket yaradır. Psevdo-başlığınızı spesifikasiya ilə sahə-sahə müqayisə edin və sazlayarkən bir məlum axın üçün hesablanmış yoxlama cəmini çap edin.

VpnService sizin üçün nə etməyəcək

Ətrafında dizayn qurmazdan əvvəl bilməyə dəyər iki məhdudiyyət var. Heç bir adi tətbiq Wi-Fi-dan kənarda sistem səviyyəli proxy və ya PAC faylı quraşdıra bilməz və bu hissə dəyişməyib. Tətbiq başına yol isə dəyişib: API 29-dan əvvəl VpnService.Builder ümumiyyətlə proxy daşıya bilmirdi və API 29-dan başlayaraq setHttpProxy(ProxyInfo.buildPacProxy(uri)) platformaya VPN şəbəkəsi üçün qiymətləndiriləcək PAC skripti verir. Köhnə API-ları hədəflədikdə və ya PAC modeli qaydanı ifadə edə bilmədikdə qaydaları öz kodunuzda qiymətləndirin. UDP də pulsuz deyil: brauzerlər SOCKS proxy vasitəsilə yalnız TCP göndərir və əksər SOCKS5 müştəriləri heç vaxt UDP ASSOCIATE tətbiq etmir, buna görə proxy əsaslı dizayn TCP sağlam görünərkən UDP-ni atır və ya sızdırır.

Bu ikinci məhdudiyyət UDP əsaslı protokolun adi şəbəkədə işləyib VPN qoşulan anda niyə uğursuz olduğunun səbəbidir. Əgər tunelin UDP daşıması gözlənilirsə, ötürücü bunun üçün ötürmə yolunu tətbiq etməlidir, sadəcə başqa soket növü ilə TCP yolunu yox.

Bu sıra ilə yoxlayın

Siyahını sıra ilə işləyin və uğursuz olan ilk mərhələdə dayanın, çünki əvvəlki yoxlama keçməyincə hər sonrakı yoxlama sadəcə səs-küydür.

1. Quraşdırılmış marşrutları sadalayın və DNS olmayan paketlərin ümumiyyətlə TUN interfeysinə daxil olub-olmadığını təsdiqləyin.
2. Bir bloklanmış və bir təsdiqlənmiş ad üçün sorğu adını, qərarı və cavab kodunu jurnala yazın.
3. Resolver soketinin qorunduğunu və seçilmiş resolverin tunelin içindən cavab verdiyini təsdiqləyin.
4. İnterfeys MTU-nu və əl ilə qurduğunuz bir cavabın yoxlama cəmini təsdiqləyin.
5. Eyni səhifəni Wi-Fi və mobil şəbəkədə təkrarlayın, çünki operator resolverləri və yol MTU fərqlidir.

Beşi də doğrudursa və səhifə hələ də donursa, növbəti şübhəli ötürücünün özüdür: tutulmuş sorğunu tutulmuş cavabla müqayisə edin və çatışmayan bayt sayını və ya yarımbağlı soketi axtarın. VpnService.Builder sənədi marşrut, DNS və MTU müqavilələrini əhatə edir və protect() builder seçimi deyil, ayrıca VpnService çağırışıdır; qoşulmuş interfeys yalnız birinci müqavilənin uğurlu olduğunu bildirir.