Sisäinen sovellus ratkeaa Windows-isännällä samalla hetkellä, kun VPN yhdistää, eikä VirtualBoxin NAT:n takana oleva Ubuntu-vieras silti löydä sitä. Vieraalla on oma resolverinsa, ja NAT-sovitin voi käsitellä DNS:ää useammalla kuin yhdellä tavalla. Vieraan resolverin korvaaminen julkisella palvelimella saa tavalliset sivustot toimimaan ja yksityiset nimet epäonnistumaan, mikä siirtää ongelmaa sen ratkaisemisen sijaan. Käy neljä tarkistusta järjestyksessä läpi ja pysähdy ensimmäiseen, joka ei pidä.

Vahvista, mitä sovittimen tilaa olet selvittämässä

Vain tavallisessa NAT-tilassa oleva sovitin käyttäytyy niin kuin tämä artikkeli kuvaa. Siltasovitin istuu fyysisessä verkossa omalla identiteetillään, NAT-verkko on nimetty virtuaalikytkin omilla DHCP- ja DNS-asetuksillaan, ja vieraan sisällä oleva VPN-asiakas lisää kokonaan toisen resolverin. Vahvista tila ennen kuin luet eteenpäin, koska korjaus on erilainen jokaisessa näistä tapauksista.

Yksi virtuaalikone voi kantaa kahta sovitinta eri tiloissa, eikä kärsivä ole aina ensimmäinen.

Vahvista myös, että isäntä ylipäänsä ratkaisee nimen. Avaa sama sovellus isännällä tunneli pystyssä ja käytä samaa täysin kvalifioitua nimeä, jota vieras tulee käyttämään. Jos myös isäntä epäonnistuu, vika ei ole vieraassa eikä mikään virtuaaliverkon muutos korjaa sitä.

Seuraa yhtä nimeä vieraan resolverin läpi

Valitse yksi sisäinen nimi ja yksi julkinen kontrollinimi ja testaa sitten molemmat molemmissa paikoissa. Julkinen nimi, joka ratkeaa, kun yksityinen ei ratkea, paikantaa vian yksityiselle polulle eikä nimien ratkaisemiseen yleisesti. Pelkän yksityisen nimen testaaminen jättää sinut kykenemättömäksi erottamaan rikkinäisen resolverin rikkinäisestä reitistä.

Katso vieraan sisällä, mihin resolveri on todella asetettu. systemd-resolvedia ajavassa Ubuntu-vieraassa linkkikohtainen tila näyttää saapuneet palvelimet, ja resolv.conf-tiedosto voi sisältää vain stub-osoitteen, mikä on oikein eikä epäilyttävää. Käsin muokattu tiedosto tai erillinen salatun DNS:n asiakas voi lähettää kyselyt aivan muualle. Kirjoita muistiin, mitä löysit, ennen kuin muutat sitä.

resolvectl status
resolvectl query app.internal.example

Erottele tässä ratkaiseminen saavutettavuudesta. Osoite, joka saapuu palvelun jäädessä saavuttamattomaksi, on reititys- tai käytäntökysymys, ei DNS-kysymys.

Kokeile isännän resolverin tilaa kyseisellä sovittimella

VirtualBoxin NAT DNS -valinnat kuvaavat eri mekanismeja, ja ero on merkityksellinen, kun isännän oma resolveri muuttuu tunnelin mukana. DNS-välityspalvelin välittää vieraan pyynnöt palvelimille, jotka se on saanut. Isännän resolverin tila sieppaa pyynnöt ja kutsuu isännän DNS-rajapintaa, ja se on tila, joka seuraa VPN-asiakkaan uudelleenmäärittämää Windowsin resolveria.

Ota väärä mekanismi käyttöön ja komento onnistuu silti, kun käyttäytyminen ei muutu, mikä on hämmentävä tapa menettää iltapäivä.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

Kirjaa virtuaalikoneen nykyiset asetukset, sammuta se ja kohdista aiemmin vahvistamaasi sovittimeen. Valinnan viimeinen numero on sovittimen numero eikä vakio, joten sen soveltaminen koneelle, jonka kärsivä sovitin on toinen, on hiljainen vaikutukseton toimenpide. Käynnistä vieras ja tarkista resolverin kokoonpano, jonka se todella sai, koska vieraan käsin tehty asetus ohittaa kaiken, mitä NAT-kerros tarjoaa. Muista, että isännän resolverin tila olettaa myös, että isännän oma DNS-polku on se, jonka halusit jakaa.

Toista samat testit VPN:n uudelleenyhdistämisen yli

Toista molemmat haut vieraassa, avaa sitten varsinainen sovellus ja anna sen validoi sertifikaatti itse. Pelkkään osoitteeseen perustuva testi on hyödyllinen nimien ratkaisemisen eristämiseen eikä vastaa toimivaa TLS-istuntoa, joten älä pysähdy pingiin. Katkaise ja yhdistä sitten isännän tunneli uudelleen hyväksytyssä ikkunassa ja toista vielä kerran. Käyttäytyminen, joka kestää vain käynnistyksen jälkeisellä ensimmäisellä yhteydellä, on raportoitava elinkaariongelma, ei DNS-arvoitus, jota kannattaisi jahdata toisella resolverilla.

Julkisen ratkaisun toimiminen ei todista, että yksityiset kyselyt pysyivät polulla, jota käytäntösi vaatii.

Kun isännän resolverin tila ei muuta mitään, palauta kirjattu kokoonpano ja pidä neljä havaintoa: mitä isäntä palautti, mitä vieras palautti, sovittimen tila ja resolverin tila. Saavuttamaton sisäinen palvelin, suodatin, joka jättää hypervisor-liikenteen pois ja vieraan puolen ohitus tarvitsevat kukin eri korjauksen. Sovittimen muuttaminen sillaksi muuttaa verkkosuunnittelua eikä ole DNS-nollaus.

Aiheeseen liittyvät artikkelit