Windows-isännässä sovelluksen sisäinen nimi ratkeaa heti, kun VPN yhdistää, mutta Ubuntun vieraassa ei. Vieras pitää omat resolver-asetuksensa, ja sen edessä oleva NAT-sovitin voi vastata DNS-kyselyihin kahdella eri tavalla. Vieraan osoittaminen julkiseen resolveriin saa sivustot latautumaan uudelleen, mutta yksityiset nimet pysyvät rikki. Siksi resolverin polku jäljitetään ennen kuin mitään muutetaan.

Jäljitä yksi kysely NAT-sovittimen läpi

Valitse yksi sisäinen täysin kelvollinen nimi ja yksi julkinen nimi vertailukohdaksi. Kun tunneli on ylhäällä, vahvista isännässä, että sisäinen nimi ratkeaa ja sen takana oleva sovellus avautuu. Aja sitten samat kaksi kyselyä vieraan sisällä ja vertaa vastauksia, älä työkaluja.

Vahvista, että sovitin on todella tavallinen NAT, ennen kuin jatkat. Sillattu sovitin, nimetty NAT-verkko ja vieraan sisällä oleva toinen VPN-asiakas tarvitsevat kukin oman kokoonpanonsa ja oman selityksensä. Arvaaminen tässä vaiheessa tuhlaa tutkinnan lopun.

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

Ensimmäinen komento näyttää sovittimen tilan ja siihen liitetyn NAT-verkon. Ubuntu-vieraan sisällä toinen luettelee linkkikohtaiset DNS-asetukset, ja kolmas paljastaa usein vain paikallisen stub-osoitteen, mikä tarkoittaa, että todellinen upstream on muualla.

Pidä ratkaisu ja tavoitettavuus erillään. Vieraalla, joka saa oikean osoitteen mutta ei voi avata yhteyttä, on reititys-, suodatus- tai palveluoikeusongelma, eivätkä myöhemmät DNS-muutokset koskaan kosketa sitä. Testaa osoite erikseen ja kirjoita muistiin, kumpi kahdesta epäonnistui.

Välityspalvelintila ja isännän resolveritila ovat eri mekanismeja

Välityspalvelintilassa NAT-moottori välittää vieraan kyselyt DNS-palvelimille, jotka se jo tuntee. Isännän resolveritilassa se sieppaa kyselyn ja pyytää isännän käyttöjärjestelmää ratkaisemaan nimen sillä, mitä isäntä käyttää juuri nyt. Vain jälkimmäinen seuraa VPN-asiakasta, joka kirjoittaa isännän ratkaisun uudelleen tunnelin noustessa. Siksi kaksi asetusta tuottavat eri vastaukset samalla koneella.

Tämä ero on koko ongelma yhdessä lauseessa. Vieraalle annettu luettelo palvelinosoitteista ei ole sama kuin pyytää Windowsia ratkaisemaan nimi määritetyn resolverinsa kautta, ja jaetun DNS:n VPN:ssä kaksi vastausta eroavat. Sovittimen valinta koskee mekanismia, ei lupaa.

Kumpikaan tila ei myönnä pääsyä mihinkään. Valtuutus elää VPN-käytännössä ja palvelussa, ja toimiva kysely tarkoittaa vain sitä, että nimi muuttui osoitteeksi.

Vaihda sovitin ja vahvista sitten, mitä vieras vastaanottaa

Kirjaa ensin VM:n verkko- ja DNS-asetukset, sammuta kone sitten, jotta muokkaat pysyvää kokoonpanoa. VM:lle nimeltä work-ubuntu, jonka ensimmäinen sovitin kantaa NAT:ia, sovitinkohtainen asetus tehdään isännästä VM:n ollessa sammutettuna. Käynnistä se sitten uudelleen ja tarkastele tulosta sen sijaan, että luottaisit poistumistilaan.

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

Viimeinen numero valitsee sovittimen numeron, joten se ei ole yleinen arvo; sovittimen 2 asetus kantaisi 2:tä siinä kohdassa. Käytä VBoxManage-binääriä, joka kuuluu asennettuun VirtualBox-versioon, koska polussa oleva vanhempi voi kirjoittaa asetuksia, jotka käynnissä oleva versio jättää huomiotta.

Välityspalvelinvalinnan ottaminen käyttöön valitsee sen sijaan toisen mekanismin eikä anna sinulle isännän resolverikäyttäytymistä. Kun vieras on käynnistynyt, tarkista DNS-kokoonpano, joka sillä todella on, sillä vieraan sisällä kiinnitetty resolver tai salatun DNS:n asetus pitää sovellukset toisella polulla riippumatta siitä, mitä sovitin tarjoaa.

Testaa koko VPN:n elinkaaren ajan, ei vain kerran

Toista molemmat kyselyt vieraassa, avaa sitten varsinainen sovellus ja anna sen validoida TLS-isäntänimi. Vain IP-pohjainen yhteystesti eristää DNS:n hyvin, mutta se ei ole varmenteen tarkistus eikä sitä pitäisi raportoida sellaisena. Kirjaa nimi, osoite ja sovelluksen tulos yhdessä.

Katkaise ja yhdistä isännän VPN uudelleen hyväksytyssä ikkunassa ja toista testi. Tuloksen pitäisi vastata käyttökäytäntöä, eikä se, että julkinen ratkaisu toimii taas, kerro mitään siitä, pysyivätkö yksityiset kyselyt aiotulla polulla.

Kun isännän resolveritila ei muuta mitään, palauta kirjattu arvo ja säilytä havainnot. VPN-asiakas, joka jättää hypervisor-liikenteen pois, tavoittamaton sisäinen resolver ja kiinnitetty vierasasetus tarvitsevat kukin eri korjauksen, ja sovittimen sillaus muuttaa verkkosuunnittelua sen sijaan, että se nollaisi DNS:n.

Aiheeseen liittyvät artikkelit