Host VPN-ə qoşulduqdan sonra VirtualBox qonağının DNS-i sıradan çıxır

Daxili tətbiq VPN qoşulan anda Windows hostunda həll olunur, VirtualBox NAT-ının arxasındakı Ubuntu qonağı isə onu hələ də tapa bilmir. Qonağın öz həlledicisi var və NAT adapteri DNS-i birdən çox üsulla idarə edə bilər. Qonağın həlledicisini açıq serverlə əvəz etmək adi saytları işlədir və daxili adları uğursuz edir, bu da problemi həll etmək əvəzinə başqa yerə yönəldir. Dörd yoxlamanı ardıcıllıqla aparın və uyğun gəlməyən ilk yoxlamada dayanın.

Hansı adapter rejimini ayırdığınızı təsdiqləyin

Bu məqalənin təsvir etdiyi kimi yalnız adi NAT rejimində olan adapter davranır. Körpü adapteri öz kimliyi ilə fiziki şəbəkədə oturur, NAT şəbəkəsi öz DHCP və DNS ayarları olan adlı virtual kommutatordur, qonağın içindəki VPN klienti isə tamamilə ikinci həlledici əlavə edir. Oxumağa davam etməzdən əvvəl rejimi təsdiqləyin, çünki təmir bu halların hər birində fərqlidir.

Bir VM müxtəlif rejimlərdə iki adapter daşıya bilər və təsirlənən adapter həmişə birinci olmur.

Hostun adı ümumiyyətlə həll etdiyini də təsdiqləyin. Eyni tətbiqi hostda tunel açıq halda açın və qonağın istifadə edəcəyi eyni tam kvalifikasiyalı addan istifadə edin. Host da uğursuz olursa, günah qonaqda deyil və heç bir virtual şəbəkə dəyişikliyi bunu düzəltməyəcək.

Bir adı qonağın həlledicisindən keçirin

Bir daxili ad və bir açıq nəzarət adı seçin, sonra hər ikisini hər iki yerdə sınayın. Daxili ad uğursuz olarkən həll olunan açıq ad xətanı ad həllinə ümumiyyətlə deyil, daxili yola yerləşdirir. Yalnız daxili adı sınamaq sizi xarab həlledicini xarab marşrutdan ayırmaq imkanından məhrum edir.

Qonağın içində həlledicinin həqiqətən nəyə qurulduğuna baxın. systemd-resolved işlədən Ubuntu qonağında hər keçid üzrə status gələn serverləri göstərir və resolv.conf faylı yalnız stub ünvanından ibarət ola bilər, bu isə şübhəli deyil, düzgündür. Əl ilə redaktə edilmiş fayl və ya ayrı şifrələnmiş-DNS klienti axtarışları tamamilə başqa yerə göndərə bilər. Dəyişməzdən əvvəl tapdıqlarınızı yazın.

resolvectl status
resolvectl query app.internal.example

Burada həlli əldə edilə bilənlikdən ayırın. Xidmət əlçatmaz qalarkən gələn ünvan DNS deyil, marşrut və ya siyasət məsələsidir.

Həmin adapterdə host həlledici rejimini sınayın

VirtualBox-ın NAT DNS seçimləri müxtəlif mexanizmləri təsvir edir və hostun öz həlledicisi tunellə dəyişdikdə fərq əhəmiyyətli olur. DNS proksisi qonaq sorğularını ona verilmiş serverlərə yönəldir. Host həlledici rejimi sorğuları tutur və hostun DNS API-sini çağırır, bu da VPN klienti tərəfindən yenidən qurulmuş Windows həlledicisini izləyən rejimdir.

Səhv mexanizmi aktivləşdirin və əmr yenə də uğurla keçər, davranış isə dəyişməz, bu da günorta vaxtını itirməyin çaşdırıcı yoludur.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

VM-in cari ayarlarını qeyd edin, onu söndürün və əvvəl təsdiqlədiyiniz adapteri hədəf alın. Seçimdəki son rəqəm sabit deyil, adapter nömrəsidir, ona görə də onu təsirlənən adapteri ikinci olan VM-ə tətbiq etmək səssiz nəticəsizlikdir. Qonağı başladın və həqiqətən aldığı həlledici konfiqurasiyasını yoxlayın, çünki qonaqda əl ilə edilən ayar NAT qatının təklif etdiyi hər şeyi üstələyir. Yadda saxlayın ki, host həlledici rejimi həm də hostun öz DNS yolunun paylaşmaq istədiyiniz yol olduğunu fərz edir.

Eyni testləri VPN yenidən qoşulması boyunca təkrarlayın

Qonaqda hər iki axtarışı təkrarlayın, sonra əsl tətbiqi açın və sertifikatı özü yoxlamasına icazə verin. Yalnız ünvana əsaslanan test ad həllini təcrid etmək üçün faydalıdır və işlək TLS sessiyasına bərabər deyil, ona görə ping ilə dayanmayın. Sonra təsdiqlənmiş pəncərədə host tunelini ayırın və yenidən qoşun və bir daha təkrarlayın. Yalnız yükləmədən sonra ilk bağlantıda davam edən davranış DNS sirri deyil, bildirilməli həyat dövrü problemidir.

Açıq həllin işləməsi daxili sorğuların siyasətinizin tələb etdiyi yolda qaldığını sübut etmir.

Host həlledici rejimi heç nəyi dəyişmədikdə, qeydə alınmış konfiqurasiyanı geri qaytarın və dörd müşahidəni saxlayın: hostun qaytardığı, qonağın qaytardığı, adapter rejimi və həlledici vəziyyəti. Əlçatmaz daxili server, hipervisor trafikini istisna edən filtr və qonaq tərəfindəki üstəlik hər biri fərqli düzəliş tələb edir. Adapteri körpüyə çevirmək şəbəkə dizaynını dəyişir və DNS sıfırlaması deyil.