VPN:si työntää kolme DNS-palvelinta: mikä vastaa?

Avaa asetussivu yhteyden muodostamisen jälkeen, niin näet kolme DNS-osoitetta; auditoinnin kysymys on, mikä niistä käsitteli viimeisimmän kyselysi. Pelkkä määrä ei vastaa mihinkään, koska asiakasohjelman työntö, fyysinen liitäntä ja verkkotunnuskohtainen käytäntö kirjoittavat kaikki samaan näkymään. Näillä merkinnöillä on eri laajuudet, ja laajuus eikä sijainti ratkaisee, kuka vastaa. Aloita erottamalla lähteet ja testaa sitten se, joka omistaa sinulle tärkeän nimen.

Miksi lista on profiiliasi pidempi

VPN-asiakasohjelma työntää selvityspalvelimien osoitteita tunnelilinkille, ja käyttöjärjestelmä pitää niitä sen rinnalla, mitä fyysisellä liitännällä jo oli. Reititin, yrityksen DHCP-vuokraus, toinen VPN ja verkkotunnuskohtainen käytäntö tuovat kukin oman merkintänsä. Kolme osoitetta sivulla voi siis tarkoittaa kolmea laajuutta eikä kolmea ehdokasta yhteen tehtävään. Määrän lukeminen vuodon todisteeksi on tämän auditoinnin ensimmäinen virhe.

Yhden liitännän sisällä asiakasohjelma todella kokeilee palvelimiaan järjestyksessä, joten järjestetty lista ei ole merkityksetön. Se, mikä ei ole jono, on yhdistetty näkymä, jossa profiilin, fyysisen linkin ja verkkotunnuskohtaisten sääntöjen merkinnät seisovat rinnakkain ilman yhtä ainoaa järjestystä. Tämä ero ratkaisee, mitä testaat: järjestys selittää käyttäytymistä yhden laajuuden sisällä ja laajuus selittää kaiken muun.

Salattu DNS rikkoo kuvan sovelluksen sisältä. Selain tai chat-asiakasohjelma, jolla on oma DNS-over-HTTPS-selvityspalvelin, lähettää kyselyt kokonaan käyttöjärjestelmän listan ohi, joten asetussivun osoitteet kuvaavat liikennettä, jota sovellus ei koskaan tuottanut. Tarkista sovelluksen oma selvityspalvelinasetus ennen kuin syytät profiilia väärin menneestä nimestä.

Mitä kukin kolmesta tarkistuksesta kertoo

Jokainen lähde jättää jälkensä eri paikkaan, eikä mikään yksittäinen komento näytä niitä kaikkia. Tämä on kartoitus, joka kannattaa pitää asetussivun vieressä:

Järjestelmässä, joka käyttää systemd-resolved-ohjelmaa, resolvectl status on määräävä, koska se raportoi DNS:n linkeittäin yhdessä reititysverkkotunnusten kanssa. macOS vastaa scutil --dns-komennolla, joka luettelee laajuudelliset selvityspalvelimet kokeilujärjestyksessä. Windows jakaa kaksi puoliskoa: Get-DnsClientServerAddress liitäntäkohtaisille palvelimille ja Get-DnsClientNrptPolicy pääte-ehtosäännöille. Suorita komento, joka kuuluu tosiasiassa käytössä olevalle selvityspalvelimelle, sillä koneessa, jossa on konttiajoympäristö ja työpöytäselvityspalvelin, voi olla useampi kuin yksi asennettuna.

Varalla oleva selvityspalvelin, joka ei osaa vastata vyöhykkeestäsi

Toinen merkintä on yleensä siellä käytettävyyden vuoksi, ja käytettävyys toimii vain, jos vara tuntee nimet. Kysy julkiselta selvityspalvelimelta sisäistä isäntänimeä, niin se palauttaa NXDOMAINin tai jokerimerkkivastauksen hakutoimialueelta, jolla ei ole mitään tekemistä sinun kanssasi. Testaamaton varasiirtymä tuottaa silloin katkoksen juuri sillä hetkellä, kun sitä tarvitaan.

Split DNS on olemassa sen estämiseksi: yrityksen päätteet menevät selvityspalvelimelle, jolla vyöhyke on, ja julkiset nimet pysyvät oletuspolulla. Suunnittelu on kestävä, ja se riippuu siitä, että pääte-luettelo on täydellinen. Microsoft dokumentoi päätekohtaisen selvityspalvelinkäytännön, joka ohjaa tätä Windowsissa, ja sama ajatus esiintyy reititysverkkotunnuksina systemd-resolvedissa ja laajuudellisina selvityspalvelimina macOSissa.

Vertaa vyöhykkeitä, joihin vara saa vastata, käytännössä oleviin päätteisiin. Tämä vertailu löytää aukon ennen kuin käyttäjä ilmoittaa, että yksi sisäinen sivusto lakkasi selvittämästä tunnelimuutoksen jälkeen.

Kysy käytännön kautta, älä sen ohi

Kysy käyttöjärjestelmän selvityspalvelimen kautta, koska suora kysely palvelimelle ohittaa käytännön ja raportoi vain, mitä se palvelin sanoisi. Kahden vastauksen välinen aukko on koko pointti:

resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53

Jos järjestelmäkysely palauttaa yksityisen osoitteen ja suora kysely palauttaa NXDOMAINin, käytäntö toimii ja vara on heikko kohta. Jos molemmat palauttavat saman julkisen vastauksen, nimi selvitetään aikomanasi laajuuden ulkopuolella, ja pääte-luettelo on paikka, josta kannattaa katsoa. Tallenna molemmat tulosteet, sillä selvityspalvelinkeskustelu ratkeaa kahdella rivillä nopeammin kuin asetussivun kuvakaappauksella.

Harjoittele sitten epäonnistumispolku, sillä testaamaton vara on oletus. Tee ensisijaisesta selvityspalvelimesta musta aukko yhtä kyselyä varten ja katso, mikä osoite palaa:

ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32

Poista kyseinen reitti heti kyselyn päätyttyä, tai seuraava henkilö perii mysteerin. Jos sisäiset nimet vielä selvitetään siinä ikkunassa, jokin aiottuun laajuuteen kuulumaton taho vastasi niihin. Jos ne sen sijaan aikakatkaistaan, vara puuttuu tai se on rajattu oikein, ja selvityspalvelimen oma loki kertoo kumpi se oli.

Päätä: pidä, rajaa tai poista

Pidä toinen selvityspalvelin, kun se vastaa tarvitsemaasi nimiavaruuteen ja pysyy tavoitettavissa profiilin alla. Rajaa se, kun sen pitäisi nähdä yksi pääte eikä mitään muuta, ja poista se, kun sillä ei ole laajuutta eikä dokumentoitua tarkoitusta. Merkintä ilman työtä on tuleva vuoto ilman hyötyä, eikä toimittajan oletus ole tarkoitus.

Kirjaa tulos neljänä sarakkeena: pääte, selvityspalvelin, liitäntä ja omistaja. Tämä rivi vastaa seuraavaan auditointikysymykseen nopeammin kuin mikään kuvakaappaus, ja se kestää asiakasohjelman päivityksen, joka hiljaa järjestää listan uudelleen.