TL;DR:
Ce trebuie să configurez pentru a putea rezolva a .local numele de gazdă pe oaspetele meu VM ca și cum l-aș rezolva pe gazda mea VM.
Versiune lungă:
Rulez un VM cu Ubuntu 21.04 pe Windows 10 folosind VMware Workstation (16.1.1 build-17801498). Ubuntu în sine este aproape vanilie, nu am schimbat aproape nimic despre sistemul de operare/env în sine (de fapt, nu îmi vine nimic în minte în acest moment). Poate că este de remarcat că am făcut upgrade de la o versiune anterioară de Ubuntu, cred că era 20.04.
Pe gazdă, pot rezolva foo.bar.local foarte bine folosind nslookup:
> nslookup foo.bar.local
Server: <...>
Adresa: 10.73.1.9
Nume: <...>
Adresa: 10.132.0.30
Alias: foo.bar.local
La invitat, aceeași încercare de rezolvare eșuează în mod implicit
> gazdă foo.bar.local
Gazdă foo.bar.local nu a fost găsită: 2(SERVFAIL)
dar pot rezolva numele dacă spun gazdă pentru a utiliza același server DNS care a răspuns mai devreme pe gazda (VM):
> host ordermanagement-migration.comventure.local 10.73.1.9
Folosind serverul de domeniu:
Nume: 10.73.1.9
Adresa: 10.73.1.9#53
Aliasuri:
foo.bar.local este un alias pentru hello.world.local.
hello.world.local are adresa 10.132.0.30
Așa că mă gândeam „de ce să nu folosești acel server mereu?” și a încercat să-l configureze prin GUI manager de rețea: deschideți setările de rețea, accesați fila IPv4, dezactivați „automat” și introduceți IP-ul în câmp. Deoarece VM-ul meu are două interfețe configurate (rețea doar pentru gazdă și NAT normal pentru acces public la rețea) și doar pentru a fi în siguranță, am făcut acest lucru pentru ambele interfețe. Spre surprinderea mea, nicio cantitate de timp de așteptare după confirmarea acelor modificări nu a condus de fapt la o schimbare observabilă a producției de systemd-resolve --status: Pentru ambele interfețe, doar a păstrat respectiva a.b.c.1 adresa ca server DNS. În schimb, a trebuit mai întâi să dezactivez interfețele, după care se afișează IP-ul serverului:
Global
Protocoale: -LLMNR -mDNS -DNSOverTLS DNSSEC=nu/neacceptat
modul rezoluție.conf: stub
Link 2 (ens33)
Domenii curente: DNS
Protocoale: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=nu/neacceptat
Server DNS curent: 10.73.1.9
Servere DNS: 10.73.1.9
Link 3 (ens38)
Domenii curente: niciuna
Protocoale: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=nu/neacceptat
Link 4 (docker0)
Domenii curente: niciuna
Protocoale: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=nu/neacceptat
Nu am inteles de ce pt ens38 (acces public la rețea), nu a mai fost afișat niciun server DNS. În acest moment, lucrurile au devenit și mai confuze, deoarece activarea unei interfețe (în managerul de rețea) pe care anterior dezactivasem „automat” pentru DNS a arătat brusc „automat” ca fiind activat, dar a enumerat și IP-ul DNS manual și systemd-resolve --status totuși încă nu am putut rezolva foo.bar.local.
Am încercat și eu să setez 10.73.1.9 ca server DNS principal direct în setările NAT/DNS ale stației de lucru VMware, dar fără rezultat.
Deci cum pot ajunge foo.bar.local să fie rezolvabil pe oaspetele meu (VM) în mod implicit, cu alte cuvinte, fără a fi nevoie să specific 10.73.1.9 ca server de nume de utilizat - ceea ce nu pot face în contextul aplicației unde am nevoie foo.bar.local solubil.
addendum: Există un VPN implicat pe gazda mea VM în cazul în care ar putea fi relevant. Îl mențin activat și conectat în orice moment când folosesc gazda (VM).
