Android həmişə aktiv VPN: son nöqtə adı ilk olaraq necə həll olunur

Telefon yenidən başlayır, həmişə aktiv rejim yandırılıb, VPN olmadan bağlantıları blokla seçimi aktivdir və tunel heç vaxt qalxmır. Heç nə səhv qurulmayıb: blok öz işini görür və müştərinin son nöqtəsinə çatmaq cəhdi də ona tabedir. Son nöqtə tunel mövcud olmadan əvvəl həll edilməlidir və bunu hər hansı digər tətbiqə icazə verilmədiyi halda şəbəkə ilə danışmağa icazəsi olan müştəri edir. Hansı komponentin bunu etdiyini və hansı ardıcıllıqla etdiyini anlamaq bu sirri konfiqurasiya sualına çevirir.

VPN qurucusu əslində nə tələb edir

Android VPN tətbiqi platformaya server ünvanı vermir. O, yerli interfeys qurur: tunel üçün ünvanlar və marşrutlar, tətbiqlərin içəridə istifadə etməli olduğu həlledicilər, sonra establish() fayl deskriptoru qaytarır və tətbiq onu xam IP paketləri kimi oxuyub yazır. Uzaq son nöqtə həmin qurucuda ümumiyyətlə görünmür.

Əsas struktur faktı budur. Platforma tun interfeysi yaradır və onun üzərində siyasət tətbiq edir; tətbiq nəqli istifadəçi məkanında həyata keçirir, yəni son nöqtə adını tətbiqin özü həll edir və şifrələnmiş bağlantını açır. Buna görə hostname son nöqtə mümkündür, platforma adları dəstəklədiyi üçün deyil, platforma son nöqtəni heç vaxt görmədiyi üçün.

Qurucunun bir sahəsi ünvan qəbul edir: DNS serverləri. Bunlar rəqəmsal həlledici ünvanları olmalıdır, adətən operatorun tunel vasitəsilə sorğulanmasını istədiyi ünvanlar. Bu sahə tunel qalxdıqdan sonra tətbiqlərin sorğularını hara göndərdiyini təsvir edir. Müştərinin son nöqtəni necə tapdığı barədə heç nə demir və ikisini eyni parametr kimi qəbul etmək qarışıqlığın başladığı yerdir.

İki DNS sualı, bir deyil

Birinci sual budur: tunel qalxdıqdan sonra tətbiqlər sorğularını hara göndərir? Cavab tunelin içindəki həlledici ünvanıdır, tun interfeysi ilə əlçatandır və təbii olaraq rəqəmsaldır.

İkinci sual budur: müştəri həmin tunel mövcud olmadan öz son nöqtəsini necə tapır? Bu axtarış tuneldən kənarda, alt şəbəkədə, müştərinin prosesində baş verir. Ad istifadə edə bilər və cihazın VPN olmadan çata bildiyi həlledicidən istifadə etməlidir.

Üç mərhələ, üç fərqli simptom. Qoşula bilmirəm kimi tək bir xəta mesajı onları birləşdirir, buna görə insanlar heç vaxt oxunmamış sahəni düzəltmək üçün DNS server sahəsini redaktə edirlər.

Bootstrap niyə kilidlənə bilər

Blok aktiv ikən həmişə aktiv demək VPN daxilində olmayan trafikin, o cümlədən VPN-ə sahib tətbiqin trafikinin atıldığı deməkdir. Çıxış yolu açıqdır: tətbiq soket üzərində protect() çağırır, bu onu alt şəbəkəyə bağlayır, beləliklə tuneli keçir və buraxılır. Hər VPN müştərisi öz nəqli üçün bunu etməlidir, əks halda serverə heç vaxt çata bilməz.

İndi son nöqtə adını bilən yeganə həlledicinin özünün tunelin içində olduğu bir yerləşdirməni düşünün. Müştəriyə adı həll etmək üçün tunel, tuneli qurmaq üçün isə ad lazımdır. Bu, həqiqi dairəvi asılılıqdır və heç bir müştəri konfiqurasiyası onu həll etmir. Bu dizayn səhvidir, səhv deyil.

Vaxt eyni asılılığı yumşaq formada üzə çıxarır. İlk açılışdan əvvəl yükləmə zamanı cihazın hələ işlək şəbəkəsi olmaya bilər; əsir portalda şəbəkə var, lakin portaldan başqa hər şeyi bloklayır; Wi-Fi-dən mobil şəbəkəyə keçiddə qorunan soketin alt şəbəkəsi dəyişir və müştəri bunu görüb yenidən həll etməlidir. Bunların hər biri bootstrap hadisəsidir və gecə saat 3-də kəşf etmək əvəzinə qəsdən sınaqdan keçirilməlidir.

Cavabı bərkitmək niyə düzəliş deyil

Cəlbedici yol adı bir dəfə həll edib nəticəni rəqəmsal sahəyə yapışdırmaq və ya fərdi qurmada kodlaşdırmaqdır. İşləyirmiş kimi görünür və adı bir ani görüntüyə çevirir. Operator son nöqtəni köçürdükdə, miqrasiya, anycast dəyişikliyi və ya yeni regional ünvan ilə, müştəri köhnəni yığmağa davam edir və interfeysdə heç nə səbəbi izah etmir.

DNS qeydləri yaşama müddəti daşıyır məhz cavabların dəyişə bilməsi üçün; keşləmə bu müddətlə müəyyən edilir, əbədi deyil. Cavabı bərkitmək adı ünvandan yaxşı edən mexanizmi atır, amma ad istifadəsinin əməliyyat xərcini saxlayır.

Bərkitmə çox vaxt ikinci pis vərdişlə gedir: bağlantı indi başqa cür uğursuz olduğu üçün kimlik yoxlamalarını yumşaltmaq. Server kimliyinin yoxlanması bootstrap probleminin hissəsi deyil və onu zəiflətmək DNS narahatlığını müdaxilə riski ilə dəyişir.

Yenidən başlamaya dözən dizaynlar

Davamlı quruluş təmtəraqsızdır. Qorunan soketləri düzgün həyata keçirən və son nöqtəsini alt şəbəkədə həll edən müştəri istifadə edin, ona açıq şəkildə və ya tuneldən əvvəl əlçatan həlledici vasitəsilə həll olunan son nöqtə adı verin. Bloku aktiv saxlayın; DNS işləsin deyə onu tamamilə söndürmək yerləşdirmənin mövcud olduğu xassəni aradan qaldırır.

Son nöqtə gizli qalmalı olduqda, platformanın istifadə edə biləcəyi açıq bootstrap yolu verin, məsələn tunelsiz əlçatan həlledici və ya operatorun saxladığı idarəetmə bağlantısı, və bu istisnanı dar saxlayın, istifadəçi açarı ilə deyil, siyasətlə idarə edin. Android VpnService sənədi platformanın qorunma və həyat dövrü barədə nəyə təminat verdiyinin mənbəyidir və VpnService.Builder arayışı DNS sahəsinin rəqəmsal ünvanlar qəbul etdiyini təsdiqləyir.

Sonra üç mərhələdə, ardıcıllıqla, yenidən başlamadan sonra təzə bağlantıda yoxlayın: son nöqtə adı həll olunur, tunel qurulur və həmkar autentifikasiya olunur, şəxsi ad tunelin həlledicisi vasitəsilə həll olunur. Birinci mərhələ uğursuz olarsa, sonrakı heç nə işləyə bilməz və düzəliş bootstrap yoluna aiddir, heç vaxt həlledici sahəsinə deyil.

• Son nöqtənin həlli tətbiqdə, tuneldən kənarda, qorunan soketdə baş verir.
• Qurucudakı DNS sahəsi tunel daxilindəki tətbiqlər üçündür, müştərinin öz son nöqtəsi üçün deyil.
• Yalnız tunel vasitəsilə əlçatan həlledici yavaş başlanğıc deyil, kiliddir.
• Yenidən başlamadan sonra son nöqtəni, autentifikasiyanı və şəxsi axtarışı ayrı-ayrı yoxlayın.