DNS fan 'e VirtualBox-NAT-gast brekt nei't de host by in VPN komt

Op in Windows-host wurdt de ynterne applikaasjenamme oplost sadree't de VPN ferbynt, en binnen in Ubuntu-gast net. De gast hâldt syn eigen resolverynstellingen, en de NAT-adapter dêrfoar kin DNS-fragen op twa ferskillende manieren beantwurdzje. De gast nei in iepenbiere resolver ferwize lit websiden wer lade wylst priveenammen brutsen bliuwe. Dêrom wurdt it resolverpaad folge foardat der eat feroare wurdt.

Folgje ien opfrege troch de NAT-adapter

Kies ien ynterne folslein kwalifisearre namme en ien iepenbiere namme as kontrôle. Mei de tunnel omheech, befêstigje op de host dat de ynterne namme oplost en dat de applikaasje dêrefter iepenet. Rin dan deselde twa opfregens yn 'e gast en fergelykje de antwurden, net de ark.

Befêstigje dat de adapter echt gewoane NAT is foardat jo fierder geane. In brêgeadapter, in neamd NAT-netwurk en in twadde VPN-klant yn 'e gast hawwe elk har eigen konfiguraasje en har eigen ferklearring. Rieden op dit punt fergriemt de rest fan it ûndersyk.

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

It earste kommando toant de adaptermodus en elk NAT-netwurk dat deroan ferbûn is. Binnen in Ubuntu-gast listet it twadde de DNS-ynstellingen per ferbining op, en it tredde iepenbiere faak allinnich in lokale stub-adres, wat betsjut dat de echte upstream earne oars sit.

Hâld oplossing en berikberens apart. In gast dy't it juste adres krijt mar gjin ferbining iepenje kin, hat in probleem mei routing, filtering of tsjinstrjochten, en fierdere DNS-feroarings sille it nea reitsje. Test it adres apart en skriuw op hokker fan de twa mislearre.

Proksymodus en hostresolvermodus binne ferskillende meganismen

Yn proksymodus stjoert de NAT-motor de fragen fan 'e gast troch nei DNS-tsjinners dy't er al ken. Yn hostresolvermodus ûnderskept er de fraach en freget it bestjoeringssysteem fan 'e host om de namme op te lossen mei wat de host op dat stuit brûkt. Allinnich it twadde folget in VPN-klant dy't de hostoplossing ferwaret as de tunnel omheech komt. Dêrom jouwe de twa ynstellingen ferskillende antwurden op deselde masine.

Dat ferskil is it hiele probleem yn ien sin. De gast in list fan tsjinneradressen jaan is net itselde as Windows freegje om in namme fia syn konfigurearre resolver op te lossen, en by in VPN mei splitst DNS ferskille de twa antwurden. De adapteropsje giet oer meganisme, net oer tastimming.

Gjin fan beide modi jout tagong ta wat dan ek. Autorisaasje libbet yn it VPN-belied en yn 'e tsjinst, en in wurkjende opfrege betsjut allinnich dat in namme in adres wurden is.

Feroarje de adapter, kontrolearje dan wat de gast krijt

Skriuw earst de netwurk- en DNS-ynstellingen fan 'e VM op, slút de masine dan ôf sadat de persistinte konfiguraasje is wat jo bewurkje. Foar in VM mei de namme work-ubuntu wêrfan't de earste adapter NAT draacht, wurdt de opsje per adapter fan 'e host út ynsteld wylst de VM út is. Start it dêrnei wer en ûndersykje it resultaat yn stee fan op 'e exitstatus te fertrouwen.

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

It lêste sifer kiest it adapternûmer, dus it is gjin universele wearde; in ynstelling foar adapter 2 soe in 2 op dat plak drage. Brûk de VBoxManage-binêre dy't by de ynstallearre VirtualBox-ferzje heart, want ien âlder op it paad kin ynstellingen skriuwe dy't de rinnende ferzje negearret.

It ynskeakeljen fan 'e proksyopsje kiest yn stee dêrfan in oar meganisme en jout jo gjin hostresolvergedrach. Kontrolearje nei it starten fan 'e gast de DNS-konfiguraasje dy't er echt hat, want in fêstsette resolver of in fersifere-DNS-ynstelling yn 'e gast hâldt applikaasjes op in oar paad, los fan wat de adapter biedt.

Test oer de hiele VPN-libbenssyklus, net mar ien kear

Werhelje beide opfregens yn 'e gast, iepenje dan de echte applikaasje en lit dy de TLS-hostnamme falidearje. In ferbiningstest allinnich mei IP isolearret DNS goed, mar it is gjin sertifikaatkontrôle en moat net as sadanich rapportearre wurde. Skriuw de namme, it adres en it resultaat fan 'e applikaasje byinoar op.

Ferbreek en ferbyn it VPN fan 'e host yn in goedkarde finster en werhelje de test. It resultaat moat by it tagongsbelied passe, en dat iepenbiere oplossing wer wurket seit neat oer de fraach oft priveefragen op it bedoelde paad bleaun binne.

As hostresolvermodus neat feroaret, set dan de fêstleine wearde werom en hâld de observaasjes. In VPN-klant dy't hypervisorferkear útslút, in net berikbere ynterne resolver en in fêstsette gastynstelling hawwe elk in oare korreksje nedich, en it oerbrêgjen fan 'e adapter feroaret it netwurkûntwerp yn stee fan DNS te resetten.