Android VPN tam ana makine adını çözer ama kısa adı çözmez

Bir terminal emülatörünefilesyazıyorsunuz ve hiçbir şey dönmüyor;files.corp.exampleyazdığınızda aynı sunucu hemen yanıt veriyor. VPN kimlik bilgilerinde hiçbir şey değişmedi ve özel DNS sunucusu hiç bozulmadı. Android'de kısa etiket ile tam ad çözümleyici içinde farklı yollar izler ve bu yollardan biri tünelin sahibinin sağlaması gereken bir ayara bağlıdır. Önünüzdeki karar hangi DNS sunucusunu değiştireceğiniz değil, uygulamanın gerçekte kullandığı ağı kimin denetlediğidir.

Arama alanı bir adres değildir. Çözümleyicinin çıplak bir etikete ekleyip sonra vazgeçtiği son eklerin listesidir.

Arama son eki ile DNS sunucusu ayrı alanlardır

Çözümleyici adresi Android'e nerede soracağını söyler. Arama son eki ise yalnızca en soldaki etiketi verdiğinizde ne soracağını söyler. İkisi de aynı ağ nesnesinde yaşar ve her biri tek başına eksik olabilir.

Tam ana makine adının çalışmasının nedeni tam da bu bağımsızlıktır. Tam nitelikli bir ad son eke ihtiyaç duymaz, çünkü zaten sunucuya giden dizedir.

Android bu ayrımı şunun üzerinden gösterir:LinkProperties. DNS sunucuları listesi ile alan adı arama listesi aynı nesnede durur ve ikincisi birincisi tamamen dolu olsa bile genellikle boştur. Çözümleyicisi olup alan adı olmayan bir ağ, son ekin hiç uygulanmadığı bir ağdır — kısa adı reddeden bir sunucu değil.

Herhangi bir şeyi değiştirmeden önce etkin ağı okuyun

Wi-Fi, hücresel ağ ve bir VPN arayüzü üç ayrı ağdır ve tünel açıldığı anda varsayılan olur. Bu nedenle ofis Wi-Fi'sinde çalışan son ek, tünel etkinken geçerli olan son ek değildir. Uygulamanın gerçekten seçili olduğu ağı inceleyin, geçen hafta yapılandırdığınızı değil.

Cihazdaki terminal kabuğu burada kötü bir tanıktır, çünküresolv.confonunki çözümleyicinin tek bir görünümünü yansıtır, her uygulamanınkini değil.

Tarayıcıların adres çubukları üstüne bir katman daha ekler: çıplak bir sözcük arama sorgusu olarak ele alınabilir veyatarayıcının kendi şifreli DNS ilkesiüzerinden çözülebilir; bu yüzden Chrome'da yüklenen bir sayfa sistem aramaları hakkında hiçbir şey kanıtlamaz. Platformun çözümleyicisini kullanan ve geri ne geldiğini yazdıran bir şeyle test edin. Ardından kısa biçimi ve tam biçimi aynı oturumda, aynı ağda çalıştırın ve hangisinin yanıt ürettiğini not edin.

VPN uygulamasını siz geliştiriyorsanız son eki oluşturucuda ekleyin

Uygulamanız arayüzüVpnServiceüzerinden kurduğunda,addSearchDomainbunun için desteklenen girdi budur. Alttaki gibi bir alan adı dizesi alır:corp.example, ve sunucu adresi geçirmenin alternatif bir yolu değildir.

Çağrı son eki kurduğunuz ağa bağlar, dolayısıyla sonradan çevrilecek küresel bir ayar yoktur. Uygulama arayüzü söküp yeniden bağlanınca yeniden kuruyorsa, yeni oluşturucunun son eki tekrar eklemesi gerekir; aksi hâlde yerine geçen ağ o olmadan açılır.

Masaüstü profil içe aktarımlarının bu alanı kaybettiği yer burasıdır. Dışa aktarıcı alan adını kendi modeline yazar, Android önyüzü yalnızca bildiği seçenekleri eşler ve ortaya çıkan arayüz diğer her bakımdan doğru görünür. Dizüstünde çalışıp telefonda başarısız olan bir profil genellikle bir eşleme boşluğudur, protokol sorunu değil.

VPN'i yalnızca kullanıyorsanız bunu ayarlamak size ait değil

Son ek ekleyen bir istemci tarafı düzenlemesi yok ve birini taklit etmek için değiştirebileceğiniz küresel bir özellik de yok. Değeri tünelin sahibi sağlar: yönetilen istemcinin profilinde, platform bazlı eşlemesinde veya sunucunun gönderdiği şey üzerinden. Hangi platformda olduğunuzu ve hangi adın başarısız olduğunu söyleyin, çünkü masaüstü ve mobil önyüzler tam olarak bu alanda ayrışır.

Masaüstü profilini yeniden içe aktarmak mobil eşleme hakkında yine hiçbir şey kanıtlamaz.

Üç koşul bir kusurunuz mu olduğunu yoksa beklenen bir sınırlama mı olduğunu belirler. Birincisi, kuruluş kısa etiketi hiç desteklenen bir ad olarak görüyor mu, yoksa yalnızca ofis Wi-Fi'sinde işlemiş bir kolaylık mı? İkincisi, başarısız arama sistem çözümleyicisini tamamen atlayabilen bir tarayıcıdan mı geliyor? Üçüncüsü, kısa adın tünel üzerinden mi yoksa yalnızca LAN'dan mı erişilebilir olması gerekiyor? Son yanıt yalnızca LAN ise, son ek eklemek ofis dışında çözülen ve sonra yönlendirilemeyen bir ad yaratırdı.

Son ek varken kısa adlar hâlâ başarısız olduğunda

Alan adı arama listesi zatencorp.examplegösteriyorsa son eki suçlamayı bırakın. Çözümleyicinin genişletilmiş ad için hiç yanıt verip vermediğini kontrol edin, çünkü son ek yalnızca sorduğunuz soruyu değiştirir. Sunucuyu hiç barındırmadığı bir bölge için asla yetkili kılmaz.

Ardından yolu kontrol edin. Çözülen ama tünelin taşımadığı bir adres bağlantı anında başarısız olur ve bu, sessizce pes eden bir tarayıcıdaki başarısız aramayla tamamen aynı görünür.

Sertifikalar ayrı bir anmayı hak eder. HTTPS doğrulaması gerçekte yazdığınız ana makine adını kullanır, bu yüzden doğru genişleyen bir kısa ad el sıkışmada yine defilessunar.files.corp.exampleiçin verilmiş bir sertifika bunun için geçerli olmayacaktır, ve bu hata doğru davranış, başladığınız DNS sorununun belirtisi değil.

Şimdi ne yapmalı

Herhangi bir şeye dokunmadan önce ayrımı doğrulayın: tam ad çözülüyor, kısa ad çözülmüyor, aynı uygulama, aynı oturum. Ardından seçili ağı bulun ve alan adı arama listesini çözümleyici listesinin yanında okuyun. İkisinden hangisi boşsa kimin harekete geçmesi gerektiğini söyler — siz, uygulama sizinse; tünel işletmecisi, değilse.

Son olarak, taşınabilirliğin önemli olduğu her yerde yer imlerinde ve istemci yapılandırmasında tam hizmet ana makine adını tercih edin. Ağ değişimini atlatır, mobil önyüzün uygulamayabileceği bir eşlemeye bağlı değildir ve sertifikanın verildiği adla eşleşir.