DNS i mysafirit në VirtualBox prishet pasi hosti lidhet me një VPN

Një aplikacion i brendshëm zgjidhet në hostin Windows në momentin që VPN lidhet, ndërsa mysafiri Ubuntu pas NAT të VirtualBox ende nuk e gjen. Mysafiri ka zgjidhësin e vet, dhe përshtatësi NAT mund ta trajtojë DNS në më shumë se një mënyrë. Zëvendësimi i zgjidhësit të mysafirit me një server publik i bën faqet e zakonshme të punojnë dhe emrat privatë të dështojnë, gjë që e zhvendos problemin në vend që ta zgjidhë. Kryeni katër kontrollet me radhë dhe ndaloni në të parën që nuk qëndron.

Konfirmo se cilën mënyrë të përshtatësit po korrigjon

Vetëm një përshtatës në mënyrën NAT të thjeshtë sillet ashtu siç përshkruan ky artikull. Përshtatësi urë qëndron në rrjetin fizik me identitetin e vet, një rrjet NAT është një ndërprerës virtual i emërtuar me cilësimet e veta DHCP dhe DNS, dhe një klient VPN brenda mysafirit shton një zgjidhës të dytë tërësisht. Konfirmoni mënyrën përpara se të lexoni më tej, sepse riparimi ndryshon në secilin prej atyre rasteve.

Një makinë virtuale mund të mbajë dy përshtatës në mënyra të ndryshme, dhe ai i prekuri nuk është gjithmonë i pari.

Konfirmoni gjithashtu se hosti e zgjidh emrin fare. Hapni të njëjtin aplikacion në host me tunelin lart, duke përdorur të njëjtin emër plotësisht të kualifikuar që do të përdorë mysafiri. Nëse edhe hosti dështon, faji nuk është i mysafirit dhe asnjë ndryshim në rrjetin virtual nuk do ta rregullojë.

Ndiqni një emër përmes zgjidhësit të mysafirit

Zgjidhni një emër të brendshëm dhe një emër kontrolli publik, pastaj provoni të dy në të dyja vendet. Një emër publik që zgjidhet ndërsa ai privat nuk zgjidhet e lokalizon defektin në rrugën private dhe jo në zgjidhjen e emrave në përgjithësi. Testimi vetëm i emrit privat ju lë të paaftë të dalloni një zgjidhës të prishur nga një rrugë e prishur.

Brenda mysafirit, shikoni për çfarë është konfiguruar zgjidhësi në të vërtetë. Në një mysafir Ubuntu me systemd-resolved, statusi për lidhje tregon serverët që mbërritën, dhe skedari resolv.conf mund të përmbajë vetëm një adresë stub, gjë që është e saktë dhe jo e dyshimtë. Një skedar i redaktuar me dorë ose një klient i veçantë DNS i kriptuar mund t'i dërgojnë kërkesat diku krejt tjetër. Shkruani atë që gjetët përpara se ta ndryshoni.

resolvectl status
resolvectl query app.internal.example

Ndani këtu zgjidhjen nga arritshmëria. Një adresë që mbërrin ndërsa shërbimi mbetet i paarritshëm është çështje rrugëtimi ose politike, jo DNS.

Provoni mënyrën e zgjidhësit të hostit në atë përshtatës

Opsionet NAT DNS të VirtualBox përshkruajnë mekanizma të ndryshëm, dhe ndryshimi ka rëndësi kur zgjidhësi i vetë hostit ndryshon me tunelin. Proxy DNS i përcjell kërkesat e mysafirit serverëve që i janë dhënë. Mënyra e zgjidhësit të hostit i kap kërkesat dhe thërret API-n DNS të hostit, dhe kjo është mënyra që ndjek një zgjidhës Windows të rikonfiguruar nga një klient VPN.

Aktivizoni mekanizmin e gabuar dhe komanda përsëri ka sukses ndërsa sjellja nuk ndryshon, që është një mënyrë konfuze për të humbur një pasdite.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

Shkruani cilësimet aktuale të makinës virtuale, fikeni atë dhe synoni përshtatësin që konfirmuat më parë. Shifra e fundit në opsion është numri i përshtatësit dhe jo një konstante, pra aplikimi i saj në një makinë përshtatësi i prekur i së cilës është i dyti është një veprim i heshtur pa efekt. Nisni mysafirin dhe kontrolloni konfigurimin e zgjidhësit që mori në të vërtetë, sepse një cilësim manual në mysafir anashkalon gjithçka që ofron shtresa NAT. Mos harroni se mënyra e zgjidhësit të hostit supozon gjithashtu se rruga DNS e vetë hostit është ajo që keni dashur të ndani.

Përsëritni të njëjtat teste gjatë një rilidhjeje VPN

Përsëritni të dyja kërkesat në mysafir, pastaj hapni aplikacionin e vërtetë dhe lëreni ta vërtetojë vetë certifikatën. Një test vetëm me adresë është i dobishëm për të izoluar zgjidhjen e emrave dhe nuk është i barabartë me një sesion TLS që punon, prandaj mos u ndalni në ping. Pastaj, në një dritare të miratuar, shkëputni dhe rilidhni tunelin e hostit dhe përsëritni edhe një herë. Sjellja që qëndron vetëm në lidhjen e parë pas nisjes është një problem i ciklit të jetës për t'u raportuar, jo një mister DNS për t'u ndjekur me një zgjidhës tjetër.

Fakti që zgjidhja publike punon nuk dëshmon se kërkesat private mbetën në rrugën që kërkon politika juaj.

Kur mënyra e zgjidhësit të hostit nuk ndryshon asgjë, ktheni konfigurimin e shënuar dhe mbani katër vëzhgimet: çfarë ktheu hosti, çfarë ktheu mysafiri, mënyrën e përshtatësit dhe gjendjen e zgjidhësit. Një server i brendshëm i paarritshëm, një filtër që përjashton trafikun e hipervizorit dhe një anashkalim nga ana e mysafirit kanë nevojë secili për një korrigjim tjetër. Shndërrimi i përshtatësit në urë ndryshon projektimin e rrjetit dhe nuk është rivendosje DNS.