DNS-ul oaspetelui VirtualBox se strică atunci când gazda se conectează la un VPN

O aplicație internă se rezolvă pe gazda Windows în momentul în care VPN-ul se conectează, iar oaspetele Ubuntu din spatele NAT-ului VirtualBox tot nu o găsește. Oaspetele are propriul resolver, iar adaptorul NAT poate trata DNS-ul în mai multe moduri. Înlocuirea resolverului oaspetelui cu un server public face site-urile obișnuite să funcționeze și numele private să eșueze, ceea ce mută problema în loc să o rezolve. Faceți cele patru verificări în ordine și opriți-vă la prima care nu se confirmă.

Confirmați ce mod de adaptor depanați

Doar un adaptor în modul NAT simplu se comportă așa cum descrie acest articol. Un adaptor punte stă în rețeaua fizică cu propria identitate, o rețea NAT este un comutator virtual numit cu propriile setări DHCP și DNS, iar un client VPN din interiorul oaspetelui adaugă un al doilea resolver complet. Confirmați modul înainte de a citi mai departe, pentru că reparația diferă în fiecare dintre aceste cazuri.

O singură mașină virtuală poate purta două adaptoare în moduri diferite, iar cel afectat nu este întotdeauna primul.

Confirmați și că gazda rezolvă numele. Deschideți aceeași aplicație pe gazdă cu tunelul ridicat, folosind același nume complet calificat pe care îl va folosi oaspetele. Dacă și gazda eșuează, vina nu este a oaspetelui și nicio modificare a rețelei virtuale nu o va repara.

Urmăriți un nume prin resolverul oaspetelui

Alegeți un nume intern și un nume public de control, apoi testați-le pe amândouă în ambele locuri. Un nume public care se rezolvă în timp ce cel privat nu o face localizează defectul pe calea privată, nu în rezolvarea numelor în general. Testarea doar a numelui privat vă lasă incapabil să distingeți un resolver stricat de o rută stricată.

În interiorul oaspetelui, uitați-vă pentru ce este configurat resolverul de fapt. Pe un oaspete Ubuntu cu systemd-resolved, starea pe legătură arată serverele care au sosit, iar fișierul resolv.conf poate conține doar o adresă stub, ceea ce este corect, nu suspect. Un fișier editat manual sau un client DNS criptat separat poate trimite interogările cu totul altundeva. Notați ce ați găsit înainte de a schimba.

resolvectl status
resolvectl query app.internal.example

Separați aici rezolvarea de accesibilitate. O adresă care sosește în timp ce serviciul rămâne inaccesibil este o chestiune de rutare sau de politică, nu de DNS.

Încercați modul resolver al gazdei pe acel adaptor

Opțiunile NAT DNS ale VirtualBox descriu mecanisme diferite, iar diferența contează atunci când resolverul propriu al gazdei se schimbă odată cu tunelul. Proxy-ul DNS transmite cererile oaspetelui către serverele pe care le-a primit. Modul resolver al gazdei interceptează cererile și apelează API-ul DNS al gazdei, iar acesta este modul care urmează un resolver Windows reconfigurat de un client VPN.

Activați mecanismul greșit și comanda reușește în continuare în timp ce comportamentul nu se schimbă, ceea ce este o modalitate confuză de a pierde o după-amiază.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

Notați setările curente ale mașinii virtuale, opriți-o și țintiți adaptorul pe care l-ați confirmat mai devreme. Ultima cifră din opțiune este un număr de adaptor, nu o constantă, așa că aplicarea ei pe o mașină al cărei adaptor afectat este al doilea este o operație silențioasă fără efect. Porniți oaspetele și verificați configurația resolverului pe care a primit-o efectiv, pentru că o setare manuală în oaspete învinge tot ce oferă stratul NAT. Amintiți-vă că modul resolver al gazdei presupune și că calea DNS proprie a gazdei este cea pe care intenționați să o partajați.

Repetați aceleași teste pe parcursul unei reconectări VPN

Repetați ambele interogări în oaspete, apoi deschideți aplicația reală și lăsați-o să valideze certificatul singură. Un test doar pe adresă este util pentru izolarea rezolvării numelor și nu este echivalent cu o sesiune TLS funcțională, așa că nu vă opriți la un ping. Apoi, într-o fereastră aprobată, deconectați și reconectați tunelul gazdei și repetați încă o dată. Un comportament care se menține doar la prima conexiune după pornire este o problemă de ciclu de viață de raportat, nu un mister DNS de urmărit cu alt resolver.

Faptul că rezolvarea publică funcționează nu dovedește că interogările private au rămas pe calea pe care o cere politica dumneavoastră.

Când modul resolver al gazdei nu schimbă nimic, puneți înapoi configurația notată și păstrați cele patru observații: ce a returnat gazda, ce a returnat oaspetele, modul adaptorului și starea resolverului. Un server intern inaccesibil, un filtru care exclude traficul hipervizorului și o suprascriere pe partea oaspetelui au nevoie fiecare de o corecție diferită. Convertirea adaptorului într-o punte schimbă proiectarea rețelei și nu este o resetare DNS.