VirtualBox-gas se DNS breek nadat die gasheer by 'n VPN aansluit

'n Interne program los op die Windows-gasheer op sodra die VPN koppel, en die Ubuntu-gas agter VirtualBox NAT kan dit steeds nie vind nie. Die gas het sy eie resolveerder, en die NAT-adapter kan DNS op meer as een manier hanteer. Om die gas se resolveerder deur 'n openbare bediener te vervang, laat gewone webwerwe werk en private name misluk, wat die probleem verskuif eerder as om dit op te los. Werk die vier kontroles in volgorde deur en stop by die eerste een wat nie hou nie.

Bevestig watter adaptermodus jy ontfout

Net 'n adapter in gewone NAT-modus gedra hom soos hierdie artikel beskryf. 'n Oorbrugde adapter sit op die fisiese netwerk met sy eie identiteit, 'n NAT-netwerk is 'n benoemde virtuele skakelaar met sy eie DHCP- en DNS-instellings, en 'n VPN-kliënt binne die gas voeg heeltemal 'n tweede resolveerder by. Bevestig die modus voordat jy verder lees, want die herstel verskil in elkeen van daardie gevalle.

Een VM kan twee adapters in verskillende modusse hê, en die geaffekteerde een is nie altyd die eerste nie.

Bevestig ook dat die gasheer die naam hoegenaamd oplos. Maak dieselfde program op die gasheer oop met die tonnel aan, en gebruik dieselfde volledig gekwalifiseerde naam wat die gas sal gebruik. As die gasheer ook faal, is die gas nie die skuld nie en geen verandering aan virtuele netwerkwerk sal dit herstel nie.

Volg een naam deur die gas se resolveerder

Kies een interne naam en een openbare kontrolenaam en toets dan albei op albei plekke. 'n Openbare naam wat oplos terwyl die private een dit nie doen nie, plaas die fout by die private pad eerder as by naamoplossing in die algemeen. Om net die private naam te toets, laat jou nie in staat om 'n stukkende resolveerder van 'n stukkende roete te onderskei nie.

Kyk binne die gas waarvoor die resolveerder werklik opgestel is. Op 'n Ubuntu-gas wat systemd-resolved gebruik, wys die per-skakel-status die bedieners wat aangekom het, en die lêer resolv.conf kan niks anders as 'n stompadres bevat nie, wat korrek eerder as verdag is. 'n Handmatig geredigeerde lêer of 'n aparte geënkripteerde-DNS-kliënt kan opvrae heeltemal elders heen stuur. Skryf neer wat jy vind voordat jy dit verander.

resolvectl status
resolvectl query app.internal.example

Skei oplossing hier van bereikbaarheid. 'n Adres wat aankom terwyl die diens onbereikbaar bly, is 'n roete- of beleidskwessie, nie 'n DNS-een nie.

Probeer gasheer-resolveerder-modus op daardie adapter

VirtualBox se NAT-DNS-opsies beskryf verskillende meganismes, en die verskil maak saak sodra die gasheer se eie resolveerder saam met die tonnel verander. Die DNS-proxy stuur gasopvrae na bedieners wat dit gekry het. Gasheer-resolveerder-modus onderskep die opvrae en roep die gasheer se DNS-API aan, en dit is die modus wat 'n Windows-resolveerder volg wat deur 'n VPN-kliënt herkonfigureer is.

Aktiveer die verkeerde meganisme en die opdrag slaag steeds terwyl die gedrag nie verander nie, wat 'n verwarrende manier is om 'n middag te verloor.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

Teken die VM se huidige instellings aan, skakel dit af en mik op die adapter wat jy vroeër bevestig het. Die syfer aan die einde van die opsie is 'n adapternommer eerder as 'n konstante, so om dit op 'n VM toe te pas waarvan die geaffekteerde adapter tweede is, is 'n stille no-op. Begin die gas en kyk na die resolveerder-opset wat dit werklik ontvang het, want 'n handmatige gasinstelling oorheers alles wat die NAT-laag bied. Onthou dat gasheer-resolveerder-modus ook aanneem dat die gasheer se eie DNS-pad die een is wat jy bedoel het om te deel.

Herhaal dieselfde toetse oor 'n VPN-herverbinding

Herhaal albei opvrae in die gas, maak dan die regte program oop en laat dit die sertifikaat self valideer. 'n Toets wat net adresse gebruik, is nuttig om naamoplossing te isoleer en is nie gelyk aan 'n werkende TLS-sessie nie, so moenie by 'n ping stop nie. Koppel dan, in 'n goedgekeurde venster, die gasheer se tonnel los en weer vas en herhaal nog een keer. Gedrag wat net op die eerste verbinding ná die selflaai hou, is 'n lewensiklusprobleem om te rapporteer, nie 'n DNS-raaisel om met 'n ander resolveerder te jaag nie.

Dat openbare oplossing werk, bewys nie dat private navrae op die pad gebly het wat jou beleid vereis nie.

Wanneer gasheer-resolveerder-modus niks verander nie, sit die aangetekende opset terug en hou die vier waarnemings: wat die gasheer teruggegee het, wat die gas teruggegee het, die adaptermodus en die resolveerder-toestand. 'n Onbereikbare interne bediener, 'n filter wat hipervisor-verkeer uitsluit en 'n oorskrywing aan die gas se kant het elkeen 'n ander regstelling nodig. Om die adapter na 'n brug te omskep, verander die netwerkontwerp en is nie 'n DNS-herstel nie.