İç ağ adları VPN üzerinde çözümlenmiyor, genel siteler sorunsuz açılıyor

Bir kullanıcı, iç ağ ana makine adının VPN üzerinden çözümlenmediğini bildiriyor. Aynı dizüstü bilgisayardan gelen ikinci bir bildirim, sızıntı testinin hâlâ sorguların yerel çözümleyici tarafından yanıtlandığını gösterdiğini söylüyor. Tek bir sorun gibi görünüyorlar ama iki taneler; kanıtları farklı ve birincisi için olağan onarım ikinciyi daha kötü hâle getiriyor. Bir ayara dokunmadan önce ikisini ayırın.

Tek bir arıza olmayan iki belirti

İç ağ adını çözümleyememek, sorunun onun için yanıtı olmayan bir yere gittiği anlamına gelir. Sorguların tünelden çıkması ise yanıt mevcut olsa bile sorunun yanlış yere gittiği anlamına gelir. Bunlar zıt arızalardır: biri eksik yanıt, diğeri fazladan bir hedeftir.

Tuzak şurada: ofis çözümleyicisini her yere eklemek birinciyi düzeltir ve ikinciyi garanti eder. Genel bir çözümleyiciyi her yere eklemek bunun tersini yapar.

Her iki gözlemi zaman damgasıyla yazın, sonra aşağıdaki dört kontrolü sırayla uygulayın.

Sorguyu hangi bağdaştırıcının çözümleyicisi alıyor

Windows'ta DNS istemcisi sunucuları bağdaştırıcı bağlama sırasına göre seçer ve tünel bağdaştırıcısı otomatik olarak ilk sırada değildir. Bağdaştırıcının gelişmiş ayarlarını açın, uzak erişim bağlantısını fiziksel bağdaştırıcının üstüne taşıyın ve ardından yeniden bağlanın; böylece değişiklik yeni bir oturumda geçerli olur.

Bağlama sırası işin yalnızca ilk yarısıdır. İstemci ayrıca hangi adların o bağdaştırıcıya ait olduğunu da bilmelidir ve bu, sıralama değil sonek sorunudur.

Çalışan makinenin ipconfig /all çıktısını, ikisi de tünel açıkken alınmış olmak üzere dizüstü bilgisayarınkiyle yan yana koyun. Çalışan makine ofis bağdaştırıcısında bağlantıya özgü bir DNS soneki gösterecek, dizüstü bilgisayar ise tünelde hiç göstermeyebilir. Bu fark, “sunucu tam orada ve ad yine de çözümlenmiyor” türü bildirimlerin bütün bir sınıfını açıklar; çünkü sonek olmadan kısa ad, ofis çözümleyicisinin hizmet ettiği bölgeye hiçbir zaman tamamlanmaz.

Kısa adın yola değil, önce soneke ihtiyacı var

Niteliksiz bir ana makine adı yazmak, çözümleyiciden bir alan adı tahmin etmesini ister. Tahmin, bağlantıya eklenmiş sonek listesinden gelir ve o liste boşsa sorgu, hiçbir özel bölgenin eşleşmeyeceği tek bir etiket olarak dışarı çıkar.

Çalışan makinenin sonekini DNS sekmesindeki VPN bağdaştırıcısının IPv4 özelliklerine kopyalayın, ardından yeniden bağlanın. Linux'ta bunun karşılığı tünel bağlantısındaki arama etki alanıdır; systemd-resolved bunu genel değil, bağlantı başına sunar.

İki ayarı notlarınızda ayrı tutun. Sonek neyin sorulduğunu değiştirir; çözümleyici adresi kimin sorulduğunu değiştirir. Biri yanlışken diğerini düzeltmek, rastgele görünen bir sonuç üretir.

Önce çözümleyiciye, sonra ada sorun

Ofis çözümleyicisine doğrudan sorgu, istemcinin çözümleyici seçimini tamamen atladığı için bir ad sorununu yol sorunundan ayırır.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

İlk komut, belirli bir sunucudan tam nitelikli bir ad ister. Yanıt verirse çözümleyici ve ona giden yol sağlamdır, arıza seçimde veya sonekte. Zaman aşımına uğrarsa adres yanlış ya da ulaşılamaz durumdadır ve sorun DNS değil, yönlendirmedir. İkinci komut kısa adla ne olduğunu gösterir, üçüncüsü ise systemd çalıştıran bir makinede bağlantı başına çözümleyici yapılandırmasını yazdırır.

Bazı ağların bilinmeyen adlar için döndürdüğü joker yanıtlara dikkat edin. Makul görünen bir yanıt, amaçlanan sunucunun yanıt verdiğinin kanıtı değildir; bu yüzden dönen adresi iç hizmetin gerçekte kullandığı adresle karşılaştırın. Adres bir park sayfasına veya bir vekil sunucuya aitse çözümleyici yanıt vermiştir ama yanıt hiçbir zaman sizin olmamıştır. Bu ayrım, baştan beri çalışan bir tünelin peşinden koşacağınız bir saati kurtarır.

Linux'ta /etc/resolv.conf dosyasını yeniden yazan bir VPN istemcisi, yerel çözümleyicileri tamamen değiştirir. vpnc bunu durdurmak için DNSUpdate no seçeneğini sunar ve systemd-resolved yalnızca listelenen etki alanlarını tünel bağlantısına yönlendirebilir. Her iki yaklaşım da genel adları yerel çözümleyicide tutarken iç adları ofise gönderir.

Sızıntılar bir onay kutusu değil, bir kuraldır

Ad çözümlemesi 53 numaralı bağlantı noktasına yapılan bir UDP alışverişidir; bu yüzden web trafiğini taşıyıp UDP'yi taşımayan bir tünel sorguyu fiziksel yolda bırakır. Bunu, genel bir ad çözümlenirken fiziksel ağ kartında yakalama yaparak kanıtlayın. O arayüzde okunabilir biçimde görünen bir sorgu, tünelin onu taşımadığı anlamına gelir.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Sorgu o arayüzde okunabilir biçimde görünüyorsa tünel onu taşımıyor demektir. Onarım, 53 numaralı bağlantı noktasına yalnızca VPN'in ittiği çözümleyiciye izin verip diğer hedefleri düşüren bir kural ile itilen seçeneği sessizce atmayan bir istemci yapılandırmasıdır.

Bu son kısım göründüğünden daha önemlidir. OpenVPN'i route-nopull ile başlatın; çekme filtresi onu tutacak şekilde genişletilmezse itilen DNS seçeneği rotalarla birlikte kaybolur. Ve dhcp-option DNS seçeneğini yok sayan bir istemci, önceden ne kullanıyorsa onu kullanmayı sürdürür. Sunucu tarafındaki her değişiklik yeni bir oturum gerektirir, çünkü çözümleyici listesi tünel açılırken iletilir ve eski bir oturum eski durumu göstermeye devam eder.

Fişi kapatmadan önce gerçekte hangi arızayı gözlediğinizi yazın. Eksik bir iç yanıt ile tünelden kaçan bir sorgu farklı onarımlar gerektirir ve birinciyi düzelten bir sonek değişikliği ikinciyi sessizce kötüleştirebilir. Fişi sıradaki kişi etikete güvenecek, o hâlde etiketi doğru yapın.