Muuttiko VPN DNS:äni? Vertaa ennen ja jälkeen
Profiili voi siirtää kyselysi tarkoituksella. Vertaa ratkaisijan käytäntöä ja todellista vastausta ennen VPN-yhteyttä ja sen jälkeen pitäen yhden muuttujan.
Yhdistät tunnelin, avaat yksityisen kojelaudan ja nimi ratkeaa osoitteeksi, jota et ole koskaan nähnyt. Tai käy päinvastoin: selain jatkaa toimintaansa, kun komentorivityökalu ei yhtäkkiä ratkaise mitään. Molemmat tulokset tulevat samasta muutoksesta, ja ihmiset selittävät sen yleensä yhdellä lauseella VPN:stä, joka "käyttää omaa DNS:ään", mikä ei ole tarpeeksi täsmällistä vianetsintään tai varmistamiseen. Siinä lauseessa piilee kaksi kysymystä: mitkä kyselyt tämän profiilin on tarkoitus ottaa haltuunsa, ja lähettikö koneesi ne todella sille ratkaisijalle, joka sille annettiin? Niiden erillään pitäminen on koko menetelmä, sillä testi, joka sekoittaa ne, antaa itsevarman väärän vastauksen molempiin suuntiin.
Miksi profiili ylipäätään tarjoaa ratkaisijan
Tunnelin sisällä kaukopään takana olevat nimet ratkeavat yleensä osoitteiksi, joita on vain siinä verkossa. Yksityisellä vyöhykkeellä kuten corp.internal ei ole julkista delegointia, joten sitä vastaavan ratkaisijan on oltava tavoitettavissa tunnelin sisältä. Sama mekanismi palvelee toistakin tarkoitusta: kun kyselyt muuten lähtisivät operaattorisi kautta, kaukopäässä oleva ratkaisija pitää kyselyn salatun polun sisällä. Siksi DNS-palvelimen osoite tulee yhteyden käytännön osana eikä globaalina asetuksena, jonka valitsit kerran koneelle.
Osoite yksin ei ratkaise mitään. Ratkaisija voi vastata vain, jos sinne on reitti, ja yleisin vika on ratkaisija, joka on tavoitettavissa vain tunnelin ollessa pystyssä. Kun tunneli putoaa ja käytäntö jää, kyselyt menevät osoitteeseen, jolla ei ole polkua, ja oireena on aikakatkaisu eikä puhdas virhe. Tämä ero on merkityksellinen, kun luet seuraavaa testitulosta, sillä aikakatkaisu lähettää ihmiset kuljetusasetuksiin, jotka eivät olleet koskaan mukana.
Vertaa kahta mallia ennen vastausten vertaamista
Täystunneli ja jaettu DNS tuottavat vastakkaiset odotukset, eikä kumpikaan ole toimintahäiriö. Täystunnelissa jokainen kysely voi siirtyä operaattorille tai yrityksen ratkaisijalle, joten julkisten nimien erilainen vastaus yhteyden jälkeen on odotettua. Jaetussa DNS:ssä vain luetellut verkkotunnukset menevät yksityiselle ratkaisijalle ja kaikki muu pysyy paikallisena; Windowsissa verkkotunnusluettelo asuu Name Resolution Policy Table -taulussa, macOS:ssä DNS-asetusten vastaavissa verkkotunnuksissa ja systemd-resolved-isännässä linkkikohtaisissa reititysverkkotunnuksissa.
Tämä vertailu on tehtävä ensin, koska se päättää, mikä lasketaan viaksi. Jaetussa DNS:ssä julkinen nimi, joka vastaa uudesta ratkaisijasta, on tutkimisen arvoinen, kun taas sisäinen nimi, joka vastaa oikein, on järjestelmä tekemässä työtään. Täystunnelissa poikkeavuus on julkinen nimi, joka vastaa edelleen operaattorisi ratkaisijasta. Microsoftin dokumentaatio VPN-nimien ratkaisemisesta kuvaa näiden sääntöjen Windows-järjestyksen, mukaan lukien sen, miten vastaava käytäntökohde tarkistetaan ennen sovittimen omia palvelimia.
Huoneessa on kolmaskin ratkaisija, joka on helppo unohtaa. Selaimen suojattu DNS ratkaisee nimiä itse ja voi jatkaa vastaamista sen jälkeen, kun tunneli muutti käyttöjärjestelmän käytäntöä, joten latautuva sivu todistaa selaimen ratkaisijan toimineen, ei sitä että profiili otettiin käyttöön. Jos vertaat vain sitä, mitä selain näyttää, testaat puolet ajasta väärää kerrosta.
Kirjaa perustaso vain yhdellä muuttujalla
Vaihda tunnelia. Älä vaihda samassa vaiheessa myös nimeä, työkalua tai hakupäätettä. Valitse nimi, jota sinulla on lupa kysellä, merkitse muistiin mitä sovellusta käytit ja kirjoita joko palautunut osoite tai tarkka virhe. Windowsissa Get-DnsClientServerAddress -AddressFamily IPv4 tulostaa palvelimet sovitinkohtaisesti ja Get-DnsClientNrptPolicy tulostaa käytäntökohdat; Linuxissa systemd-resolvedin kanssa resolvectl status näyttää DNS-palvelimet ja reititysverkkotunnukset linkeittäin; macOS:ssä scutil --dns tulostaa ratkaisijajärjestyksen, jota järjestelmä todella noudattaa.
Yhdistä sitten asiakkaan tavallisilla säätimillä ja toista täsmälleen samat komennot. Säilytä ensimmäinen tuloste muistin sijaan, koska vertailu on koko pointti ja välimuistin tyhjennyksen jälkeen otettu toinen lukema on jo eri mittaus. Jos perustaso otettiin selain edessä ja yhteyden jälkeinen ajo tapahtuu päätteessä, vertaat kahta ratkaisijaa, et yhden ratkaisijan kahta tilaa.
Selkeä kysely ja sovelluksen haku ovat eri testejä
Yhdeltä tietyltä palvelimelta kysyminen, komennolla nslookup name 10.20.0.1 tai dig @10.20.0.1 name, todistaa yhden asian: nimeämäsi palvelin vastaa, kun siihen pääsee. Se ohittaa valintalogiikan täysin, joten se ei voi kertoa, olisiko järjestelmä valinnut kyseisen palvelimen tälle nimelle. Käytä sitä testaamaan, onko määritetty ratkaisija tavoitettavissa, äläkä käytä sitä käytännön testaamiseen.
Paikallisen ratkaisijan kautta tehty haku todella harjoittaa valintaa. resolvectl query name kulkee samat reititysverkkotunnusten säännöt ja kertoo, mikä protokolla vastasi, Resolve-DnsName Windowsissa kulkee käytäntötaulun ja asiakkaan välimuistin kautta, ja scutil --dns näyttää järjestyksen, jota haku noudattaisi. Aja molempia tyyppejä ja pidä ne muistiinpanojesi eri sarakkeissa. Onnistunut selkeä kysely epäonnistuneen sovellushaun vieressä on reititys- tai valintaongelma, ei ratkaisija, joka kieltäytyy toimimasta.
Välimuisti seisoo sinun ja vastauksen välissä. Käyttöjärjestelmä, paikallinen stub-ratkaisija, selain ja negatiivinen välimuisti pitävät kaikki tuloksia, joten haku voi onnistua ilman että yksikään paketti lähtee koneesta. Kirjaa tulos ennen kuin tyhjennät mitään: ipconfig /flushdns, resolvectl flush-caches tai sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder macOS:ssä. Ohita laaja verkon nollaus tässä vaiheessa, koska se tuhoaa todisteet, joita vielä keräät.
Mitä ero tarkoittaa
Vertaa kahta kirjaamaasi riviä ja luokittele muutos ennen kuin kosket yhteenkään asetukseen.
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
Yksi rivi ansaitsee korostuksen. Nimi, joka ratkeaa, ei ole palvelu, joka toimii, ja DNS:n onnistuminen kertoo vain, että osoite löytyi. Se ei kerro mitään edelleenlähetyksestä, palomuurisäännöistä tai siitä, saako tilisi ylipäätään käyttää palvelua, joten lopeta testaamalla todellista sovellusta sen sijaan, että olettaisit vian väistyneen itsestään.
Palauta perustaso ja varmista se
Katkaise yhteys asiakkaan omilla säätimillä prosessia tappamatta ja lue sitten samat kolme komentoa uudelleen. Linkkikohtaiset palvelimet, käytäntökohdat ja testinimesi vastaus pitäisi palata aiemmin kirjaamaasi perustasoon. Puhtaan katkaisun jälkeen jäljelle jäävä käytäntökohde on todellinen vika, joka kannattaa kirjata, ja juuri siksi luodun ratkaisijatiedoston käsin muokkaaminen on huono tapa: tiedosto kirjoitetaan uudelleen ja muokkaus katoaa, tai muokkaus jää ja kiinnittää ratkaisijan, jolla ei enää ole reittiä.
Käy tämä luettelo läpi kerran järjestyksessä. Päätä, minkä mallin profiili toteuttaa, ennen kuin arvioit mitään tulosta. Pidä nimi, työkalu ja pääte kiinteinä molemmissa ajoissa. Erota selkeä kysely sovellushausta. Lue voimassa oleva käytäntö, älä vain vastausta. Tyhjennä välimuistit viimeiseksi, kun vertailu on kirjoitettu. Varmista todellisella sovelluksella, käynnistä sitten kerran uudelleen ja vahvista, että katkaistu tila on edelleen puhdas.