Android VPN tam host adını həll edir, qısa adı isə yox

Sizfilesterminal emulyatoruna yazırsınız və heç nə qayıtmır; yenidən yazırsınızfiles.corp.examplevə eyni server dərhal cavab verir. VPN etimad məlumatlarında heç nə dəyişməyib və şəxsi DNS serveri heç vaxt sıradan çıxmayıb. Android-də qısa etiket və tam ad həlledicidən fərqli yollarla keçir və bu yollardan biri tunelin sahibinin təmin etməli olduğu parametrdən asılıdır. Qarşınızda duran qərar hansı DNS serverini dəyişmək deyil, tətbiqin faktiki istifadə etdiyi şəbəkəni kimin idarə etdiyidir.

Axtarış domeni ünvan deyil. O, həlledicinin tək etiketə əlavə etdiyi şəkilçilərin siyahısıdır və bundan sonra əl çəkir.

Axtarış şəkilçisi və DNS serveri ayrı sahələrdir

Həlledici ünvanı Android-ə harada soruşacağını deyir. Axtarış şəkilçisi isə yalnız ən soldakı etiketi verdikdə nəyi soruşacağını bildirir. Hər ikisi eyni şəbəkə obyektində yaşayır və hər biri təkbaşına çatışmaya bilər.

Bu müstəqillik tam host adının niyə işlədiyini izah edir. Tam kvalifikasiya olunmuş adın şəkilçiyə ehtiyacı yoxdur, çünki o, artıq serverə gedən sətirdir.

Android bu ayrılığıLinkPropertiesvasitəsilə göstərir. DNS server siyahısı və domen axtarış siyahısı eyni obyektdə oturur və birincisi tam dolu olsa belə ikincisi adətən boş olur. Həlledicisi olub domeni olmayan şəbəkə, şəkilçinin heç vaxt tətbiq olunmadığı şəbəkədir — qısa adı rədd edən server deyil.

Nəyisə dəyişməzdən əvvəl effektiv şəbəkəni oxuyun

Wi-Fi, mobil şəbəkə və VPN interfeysi üç ayrı şəbəkədir və tunel qalxdıqdan sonra standart olur. Ona görə də ofis Wi-Fi-da işləyən şəkilçi avtomatik olaraq tunel aktivkən qüvvədə olan şəkilçi deyil. Tətbiqin faktiki seçildiyi şəbəkəni yoxlayın, keçən həftə qurduğunuzu yox.

Cihazdakı terminal qabığı burada zəif şahiddir, çünki onunresolv.confhər tətbiqin deyil, həlledicinin bir görünüşünü əks etdirir.

Brauzer ünvan sətirləri üstünə daha bir qat əlavə edir: tək söz axtarış sorğusu kimi qəbul edilə bilər və yabrauzerin öz şifrələnmiş DNS siyasətiilə həll oluna bilər, ona görə Chrome-da açılan səhifə sistem axtarışları haqqında heç nə sübut etmir. Platformanın həlledicisindən istifadə edən və nə qayıtdığını göstərən bir şeylə sınaqdan keçirin. Sonra qısa və tam formanı eyni sessiyada, eyni şəbəkədə işə salın və hansının cavab verdiyini qeyd edin.

Əgər VPN tətbiqini siz qurursunuzsa, şəkilçini builder-də əlavə edin

Tətbiqiniz interfeysiVpnServicevasitəsilə qurursa,addSearchDomainbunun üçün dəstəklənən girişdir. O, belə bir domen sətri qəbul edir:corp.example, və bu, server ünvanını ötürməyin alternativ üsulu deyil.

Bu çağırış şəkilçini qurduğunuz şəbəkəyə bağlayır, ona görə sonradan çevirəcəyiniz qlobal parametr yoxdur. Tətbiq interfeysi dağıdıb yenidən qoşulma zamanı yenidən qurursa, yeni builder şəkilçini yenidən əlavə etməlidir, əks halda əvəzedici şəbəkə onsuz qalxır.

Masaüstü profil idxalının çoxu sahəni burada itirir. İxrac edən domeni öz modelinə yazır, Android ön hissəsi yalnız bildiyi seçimləri xəritələyir və nəticədə interfeys bütün digər cəhətlərdən düzgün görünür. Noutbukda işləyib telefonda uğursuz olan profil adətən xəritələmə boşluğudur, protokol problemi deyil.

Əgər siz yalnız VPN istifadə edirsinizsə, bunu təyin etmək sizin işiniz deyil

Şəkilçi əlavə edən müştəri tərəfində redaktə yoxdur və onu təqlid etmək üçün dəyişə biləcəyiniz qlobal xassə yoxdur. Dəyəri tunelin sahibi təqdim edir: idarə olunan müştərinin profilində, platforma üzrə xəritələməsində və ya serverin ötürdüyü hər hansı vasitə ilə. Hansı platformada olduğunuzu və hansı adın uğursuz olduğunu deyin, çünki masaüstü və mobil ön hissələr məhz bu sahədə fərqlənir.

Masaüstü profilinin yenidən idxalı mobil xəritələmə haqqında heç nə sübut etmir.

Üç şərt qüsurlu olduğunuzu, yoxsa gözlənilən məhdudiyyətlə üzləşdiyinizi müəyyən edir. Birincisi, təşkilat qısa etiketi ümumiyyətlə dəstəklənən ad sayırmı, yoxsa o, yalnız ofis Wi-Fi-da işləmiş rahatlıqdır? İkincisi, uğursuz axtarış sistemi həlledicisini tamamilə yan keçə bilən brauzerdən gəlirmi? Üçüncüsü, qısa ad tunel üzərindən əldə edilməlidirmi, yoxsa yalnız LAN-dan? Əgər son cavab yalnız LAN-dırsa, şəkilçi əlavə etmək ofisdən kənarda həll olunan və sonra marşrutlaşdırıla bilməyən ad yaradar.

Şəkilçi mövcud olduqda və qısa adlar yenə uğursuz olduqda

Əgər domen axtarış siyahısı artıqcorp.examplegöstərirsə, şəkilçini günahlandırmağı dayandırın. Həlledicinin genişləndirilmiş ad üçün ümumiyyətlə cavab qaytarıb-qaytarmadığını yoxlayın, çünki şəkilçi yalnız verdiyiniz sualı dəyişir. O, serveri heç vaxt yerləşdirmədiyi zona üçün səlahiyyətli etmir.

Sonra marşruta baxın. Həll olunan, lakin tunel tərəfindən daşınmayan ünvan qoşulma zamanı uğursuz olur və bu, səssizcə əl çəkən brauzerdəki axtarış uğursuzluğuna eyni görünür.

Sertifikatlar ayrıca qeydə layiqdir. HTTPS yoxlaması faktiki yazdığınız host adından istifadə edir, ona görə düzgün genişlənən qısa ad handshake-də hələ dəfileskimi görünür. Sertifikat isəfiles.corp.exampleüçün verilib və bunun üçün doğrulanmayacaq; bu xəta başladığınız DNS probleminin simptomu deyil, düzgün davranışdır.

Bundan sonra nə etməli

Bir şeyə toxunmazdan əvvəl ayrılığı təsdiqləyin: tam ad həll olunur, qısa ad yox, eyni tətbiq, eyni sessiya. Sonra seçilmiş şəbəkəni tapın və onun domen axtarış siyahısını həlledici siyahısı ilə yanaşı oxuyun. İkisindən hansı boşdursa, kimin hərəkət etməli olduğunu deyir — tətbiq sizindirsə siz; deyilsə tunel operatoru.

Nəhayət, portativliyin vacib olduğu yerlərdə əlfəcinlərdə və müştəri konfiqurasiyasında tam xidmət host adına üstünlük verin. O, şəbəkə dəyişikliyindən sağ çıxır, mobil ön hissənin tətbiq etməyə biləcəyi xəritələmədən asılı deyil və sertifikatın verildiyi adla üst-üstə düşür.