Ana makine bir VPN'e bağlandığında VirtualBox konuk makinesinin DNS'i bozulur

VPN bağlandığı anda Windows ana makinesinde bir iç uygulama çözümleniyor, ancak VirtualBox NAT'ının arkasındaki Ubuntu konuğu onu hâlâ bulamıyor. Konuğun kendi çözümleyicisi vardır ve NAT bağdaştırıcısı DNS'i birden fazla şekilde işleyebilir. Konuğun çözümleyicisini ortak bir sunucuyla değiştirmek sıradan sitelerin çalışmasını ve özel adların başarısız olmasını sağlar; bu, sorunu çözmek yerine başka yere taşır. Dört kontrolü sırayla yapın ve uymayan ilkinde durun.

Hangi bağdaştırıcı kipinde hata ayıkladığınızı doğrulayın

Bu makalenin anlattığı gibi yalnızca düz NAT kipindeki bir bağdaştırıcı davranır. Köprü bağdaştırıcı kendi kimliğiyle fiziksel ağda oturur, NAT ağı kendi DHCP ve DNS ayarlarına sahip adlandırılmış bir sanal anahtardır ve konuğun içindeki VPN istemcisi tamamen ikinci bir çözümleyici ekler. Okumaya devam etmeden önce kipi doğrulayın, çünkü onarım bu durumların her birinde farklıdır.

Bir VM farklı kiplerde iki bağdaştırıcı taşıyabilir ve etkilenen her zaman ilki değildir.

Ana makinenin adı hiç çözümleyip çözümlemediğini de doğrulayın. Tünel açıkken ana makinede aynı uygulamayı açın ve konuğun kullanacağı aynı tam nitelikli adı kullanın. Ana makine de başarısız olursa hata konukta değildir ve hiçbir sanal ağ değişikliği bunu onarmaz.

Bir adı konuğun çözümleyicisinden geçirerek izleyin

Bir iç ad ve bir genel denetim adı seçin, sonra ikisini de iki yerde sınayın. Özel ad çözümlenmezken genel adın çözümlenmesi, hatayı genel ad çözümlemesinde değil özel yolda konumlandırır. Yalnızca özel adı sınamak, bozuk bir çözümleyiciyi bozuk bir yoldan ayırmanızı engeller.

Konuğun içinde çözümleyicinin gerçekte ne için yapılandırıldığına bakın. systemd-resolved çalıştıran bir Ubuntu konuğunda bağlantı başına durum, gelen sunucuları gösterir ve resolv.conf dosyası yalnızca bir stub adresi içerebilir; bu doğrudur, şüpheli değildir. Elle düzenlenmiş bir dosya veya ayrı bir şifreli DNS istemcisi sorguları tamamen başka bir yere gönderebilir. Değiştirmeden önce bulduğunuzu yazın.

resolvectl status
resolvectl query app.internal.example

Burada çözümlemeyi erişilebilirlikten ayırın. Hizmet erişilemez kalırken gelen bir adres, DNS değil yönlendirme veya ilke sorunudur.

Ana makine çözümleyici kipini o bağdaştırıcıda deneyin

VirtualBox'ın NAT DNS seçenekleri farklı mekanizmalar tanımlar ve ana makinenin kendi çözümleyicisi tünelle birlikte değiştiğinde bu fark önemlidir. DNS vekili, konuğun isteklerini kendisine verilen sunuculara iletir. Ana makine çözümleyici kipi istekleri yakalar ve ana makinenin DNS API'sini çağırır; bir VPN istemcisinin yeniden yapılandırdığı Windows çözümleyicisini izleyen kip budur.

Yanlış mekanizmayı etkinleştirin, komut yine de başarılı olur ama davranış değişmez; bu, bir öğleden sonrayı kaybetmenin kafa karıştırıcı bir yoludur.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

VM'in geçerli ayarlarını yazın, kapatın ve daha önce doğruladığınız bağdaştırıcıyı hedefleyin. Seçenekteki son rakam sabit değil bağdaştırıcı numarasıdır, bu yüzden etkilenen bağdaştırıcısı ikinci olan bir makineye uygulamak sessiz ve etkisiz bir işlemdir. Konuğu başlatın ve gerçekte aldığı çözümleyici yapılandırmasını denetleyin, çünkü konukta elle yapılan ayar NAT katmanının sunduğu her şeyi geçersiz kılar. Ana makine çözümleyici kipinin, paylaşmak istediğinizin ana makinenin kendi DNS yolu olduğunu da varsaydığını unutmayın.

Aynı testleri bir VPN yeniden bağlantısı boyunca yineleyin

Konukta iki sorguyu da yineleyin, sonra gerçek uygulamayı açın ve sertifikayı kendisinin doğrulamasına izin verin. Yalnızca adrese dayalı bir test ad çözümlemesini yalıtmak için yararlıdır ve çalışan bir TLS oturumuna eşdeğer değildir, bu yüzden ping'de durmayın. Ardından onaylı bir zaman aralığında ana makinenin tünelini kesip yeniden bağlayın ve bir kez daha yineleyin. Yalnızca açılıştan sonraki ilk bağlantıda süren davranış, raporlanması gereken bir yaşam döngüsü sorunudur; başka bir çözümleyiciyle kovalanacak bir DNS gizemi değildir.

Genel çözümlemenin çalışması, özel sorguların ilkenizin gerektirdiği yolda kaldığını kanıtlamaz.

Ana makine çözümleyici kipi hiçbir şeyi değiştirmediğinde, kaydedilen yapılandırmayı geri koyun ve dört gözlemi saklayın: ana makinenin ne döndürdüğü, konuğun ne döndürdüğü, bağdaştırıcı kipi ve çözümleyicinin durumu. Erişilemeyen bir iç sunucu, hipervizör trafiğini dışlayan bir filtre ve konuk tarafındaki bir geçersiz kılma her biri farklı bir düzeltme gerektirir. Bağdaştırıcıyı köprüye çevirmek ağ tasarımını değiştirir ve bir DNS sıfırlaması değildir.