DNS-ul oaspetelui VirtualBox NAT se strică după ce gazda se conectează la un VPN

Pe o gazdă Windows numele intern al aplicației se rezolvă imediat ce VPN-ul se conectează, dar într-un oaspete Ubuntu nu. Oaspetele își păstrează propriile setări de resolver, iar adaptorul NAT din fața lui poate răspunde interogărilor DNS în două moduri diferite. Direcționarea oaspetelui către un resolver public face site-urile să se încarce din nou, dar numele private rămân stricate. De aceea calea resolverului este urmărită înainte de a se modifica ceva.

Urmăriți o interogare prin adaptorul NAT

Alegeți un nume intern complet calificat și un nume public ca martor. Cu tunelul ridicat, confirmați pe gazdă că numele intern se rezolvă și că aplicația din spate se deschide. Apoi rulați aceleași două interogări în oaspete și comparați răspunsurile, nu uneltele.

Confirmați că adaptorul este într-adevăr NAT simplu înainte de a merge mai departe. Un adaptor punte, o rețea NAT cu nume și un al doilea client VPN în oaspete au fiecare propria configurație și propria explicație. Ghicitul în acest punct irosește restul investigației.

VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natnet
resolvectl status | head -40
cat /etc/resolv.conf

Prima comandă arată modul adaptorului și orice rețea NAT atașată. Într-un oaspete Ubuntu a doua listează setările DNS pe legătură, iar a treia dezvăluie adesea doar o adresă stub locală, ceea ce înseamnă că upstream-ul real se află în altă parte.

Țineți rezolvarea și accesibilitatea separate. Un oaspete care primește adresa corectă dar nu poate deschide o conexiune are o problemă de rutare, filtrare sau permisiuni ale serviciului, iar modificările suplimentare de DNS nu o vor atinge niciodată. Testați adresa separat și notați care dintre cele două a eșuat.

Modul proxy și modul resolver al gazdei sunt mecanisme diferite

În modul proxy motorul NAT trimite interogările oaspetelui către servere DNS pe care le cunoaște deja. În modul resolver al gazdei interceptează interogarea și cere sistemului de operare al gazdei să rezolve numele cu ceea ce gazda folosește chiar acum. Doar al doilea urmează un client VPN care rescrie rezolvarea pe gazdă când tunelul urcă. De aceea cele două setări produc răspunsuri diferite pe aceeași mașină.

Această distincție este toată problema într-o propoziție. A da oaspetelui o listă de adrese de server nu este același lucru cu a cere Windows-ului să rezolve un nume prin resolverul său configurat, iar într-un VPN cu DNS divizat cele două răspunsuri diferă. Opțiunea adaptorului ține de mecanism, nu de permisiune.

Niciunul dintre moduri nu acordă acces la nimic. Autorizarea trăiește în politica VPN și în serviciu, iar o interogare care funcționează înseamnă doar că un nume a devenit adresă.

Schimbați adaptorul și apoi verificați ce primește oaspetele

Notați mai întâi setările de rețea și DNS ale VM-ului, apoi opriți mașina, astfel încât să editați configurația persistentă. Pentru un VM numit work-ubuntu al cărui prim adaptor poartă NAT, opțiunea pe adaptor se setează de pe gazdă cu VM-ul oprit. Porniți-l din nou după aceea și inspectați rezultatul în loc să vă bazați pe codul de ieșire.

VBoxManage modifyvm work-ubuntu --natdnshostresolver1 on
VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natdns

Ultima cifră selectează numărul adaptorului, deci nu este o valoare universală; o setare pentru adaptorul 2 ar purta un 2 în acea poziție. Folosiți binarul VBoxManage care aparține versiunii instalate de VirtualBox, pentru că unul mai vechi în cale poate scrie setări pe care versiunea care rulează le ignoră.

Activarea opțiunii proxy în schimb alege alt mecanism și nu vă oferă comportamentul resolverului gazdei. După ce oaspetele pornește, verificați configurația DNS pe care o are de fapt, deoarece un resolver fixat sau o setare DNS criptată în oaspete ține aplicațiile pe altă cale, indiferent de ce oferă adaptorul.

Testați de-a lungul întregului ciclu de viață al VPN-ului, nu doar o dată

Repetați ambele interogări în oaspete, apoi deschideți aplicația reală și lăsați-o să valideze numele de gazdă TLS. Un test de conexiune doar prin IP izolează bine DNS-ul, dar nu este o verificare de certificat și nu ar trebui raportat ca atare. Notați împreună numele, adresa și rezultatul aplicației.

Într-o fereastră aprobată, deconectați și reconectați VPN-ul gazdei și repetați testul. Rezultatul ar trebui să corespundă politicii de acces, iar faptul că rezolvarea publică funcționează din nou nu spune nimic despre dacă interogările private au rămas pe calea dorită.

Când modul resolver al gazdei nu schimbă nimic, puneți la loc valoarea înregistrată și păstrați observațiile. Un client VPN care exclude traficul hypervisorului, un resolver intern inaccesibil și o setare fixată a oaspetelui necesită fiecare o corecție diferită, iar punerea adaptorului în punte schimbă proiectarea rețelei în loc să reseteze DNS-ul.