DNS van de VirtualBox-gast breekt zodra de host met een VPN verbindt

Een interne toepassing wordt op de Windows-host opgelost op het moment dat de VPN verbindt, en de Ubuntu-gast achter de NAT van VirtualBox vindt hem nog steeds niet. De gast heeft zijn eigen resolver, en de NAT-adapter kan DNS op meer dan één manier afhandelen. De resolver van de gast vervangen door een publieke server laat gewone websites werken en privénamen falen, wat het probleem verplaatst in plaats van het op te lossen. Werk de vier controles op volgorde af en stop bij de eerste die niet klopt.

Bevestig welke adaptermodus je debugt

Alleen een adapter in gewone NAT-modus gedraagt zich zoals dit artikel beschrijft. Een bridge-adapter staat met eigen identiteit op het fysieke netwerk, een NAT-netwerk is een benoemde virtuele switch met eigen DHCP- en DNS-instellingen, en een VPN-client in de gast voegt een heel tweede resolver toe. Bevestig de modus voordat je verder leest, want de reparatie verschilt in elk van die gevallen.

Eén VM kan twee adapters in verschillende modi dragen, en de getroffen adapter is niet altijd de eerste.

Bevestig ook dat de host de naam überhaupt oplost. Open dezelfde toepassing op de host met de tunnel omhoog, en gebruik dezelfde volledig gekwalificeerde naam die de gast zal gebruiken. Als de host ook faalt, ligt de schuld niet bij de gast en geen enkele wijziging in het virtuele netwerk zal dat verhelpen.

Volg één naam door de resolver van de gast

Kies één interne naam en één openbare controlenaam, en test beide op beide plaatsen. Een openbare naam die oplost terwijl de privénaam dat niet doet, lokaliseert de fout in het privépad en niet in naamresolutie in het algemeen. Alleen de privénaam testen laat je niet in staat een kapotte resolver van een kapotte route te onderscheiden.

Kijk in de gast waarvoor de resolver werkelijk is geconfigureerd. Op een Ubuntu-gast met systemd-resolved toont de status per koppeling de servers die zijn aangekomen, en het bestand resolv.conf kan alleen een stub-adres bevatten, wat correct is en niet verdacht. Een met de hand bewerkt bestand of een aparte versleutelde-DNS-client kan opzoekingen heel ergens anders heen sturen. Noteer wat je vindt voordat je iets wijzigt.

resolvectl status
resolvectl query app.internal.example

Scheid hier resolutie van bereikbaarheid. Een adres dat aankomt terwijl de dienst onbereikbaar blijft, is een routerings- of beleidsvraag, geen DNS-vraag.

Probeer de resolversmodus van de host op die adapter

De NAT-DNS-opties van VirtualBox beschrijven verschillende mechanismen, en het verschil telt zodra de eigen resolver van de host met de tunnel verandert. De DNS-proxy stuurt verzoeken van de gast door naar servers die hij heeft gekregen. De resolversmodus van de host onderschept de verzoeken en roept de DNS-API van de host aan, en dat is de modus die een door een VPN-client geherconfigureerde Windows-resolver volgt.

Activeer het verkeerde mechanisme en de opdracht slaagt nog steeds terwijl het gedrag niet verandert, wat een verwarrende manier is om een middag te verliezen.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

Noteer de huidige instellingen van de VM, schakel hem uit en richt je op de adapter die je eerder hebt bevestigd. Het laatste cijfer in de optie is een adapternummer en geen constante, dus toepassing op een VM waarvan de getroffen adapter de tweede is, is een stille no-op. Start de gast en controleer de resolverconfiguratie die hij werkelijk heeft gekregen, want een handmatige instelling in de gast gaat boven alles wat de NAT-laag biedt. Bedenk dat de resolversmodus van de host er ook van uitgaat dat het eigen DNS-pad van de host het pad is dat je wilde delen.

Herhaal dezelfde tests tijdens een VPN-herverbinding

Herhaal beide opzoekingen in de gast, open dan de echte toepassing en laat die het certificaat zelf valideren. Een test op alleen het adres is nuttig om naamresolutie te isoleren en is niet gelijk aan een werkende TLS-sessie, dus stop niet bij een ping. Verbreek en herstel daarna in een goedgekeurd venster de tunnel van de host en herhaal nog één keer. Gedrag dat alleen bij de eerste verbinding na het opstarten standhoudt, is een levenscyclusprobleem om te melden, geen DNS-mysterie om met een andere resolver te achtervolgen.

Dat openbare resolutie werkt, bewijst niet dat privéquery's op het pad zijn gebleven dat je beleid vereist.

Als de resolversmodus van de host niets verandert, zet dan de genoteerde configuratie terug en houd de vier observaties vast: wat de host teruggaf, wat de gast teruggaf, de adaptermodus en de toestand van de resolver. Een onbereikbare interne server, een filter dat hypervisorverkeer uitsluit en een overschrijving aan de gastzijde vragen elk een andere correctie. De adapter omzetten naar een bridge verandert het netwerkontwerp en is geen DNS-reset.