DNS-resolverin lokit ja VPN-yhteyden lokit: mitä kumpikin sisältää

DNS-resolverin loki ja VPN-yhteyden loki ovat molemmat verkkotallenteita, molemmat hyödyllisiä eivätkä vaihdettavissa keskenään. Resolver vastaanottaa nimet, joihin sen pyydettiin vastaavan. VPN:n päätepiste käsittelee tunneliyhteyksiä ja kirjaa sen, minkä sen toteutus päätti niistä kirjata. Ne voivat olla samassa rakennuksessa, saman tiimin ylläpitämiä ja saman tietosuojailmoituksen piirissä, ja silti ne kuvaavat eri tapahtumia eri tunnisteilla ja eri säilytysajalla. Toisen lukeminen ikään kuin se olisi toinen on se tapa, jolla tutkinnat menevät pieleen.

Kaksi lokia, kaksi tapahtumaa

Resolverin merkintä vastaa nimeämistä koskevaan kysymykseen: tämä asiakas pyysi tätä nimeä tähän aikaan, ja vastaus oli tämä. VPN:n merkintä vastaa yhteydenmuodostusta koskevaan kysymykseen: tämä vertaiskone loi tai menetti tunnelin, sille annettiin tämä osoite ja se siirsi suunnilleen näin paljon dataa ennen katoamistaan. Kumpikaan ei ole tallenne siitä, mitä käyttäjä teki HTTPS-istunnon sisällä, eikä kumpikaan korvaa toista.

Erolla on käytännön seuraus lupauksille. Väite, ettei VPN-palveluntarjoaja kirjaa tunnelitoimintaa, ei kerro mitään sen jakamasta resolverista, eikä resolverin säilytyskäytäntö kerro mitään siitä, kuka tunnelille yhdisti. Jokainen väite kuuluu omalle operaattorilleen ja omalle järjestelmälleen.

Seuraa kyselyä ennen kuin luet kumpaakaan lokia

Kysely saavuttaa resolverin vain, jos polku todella kysyy sitä. Sovellus voi käyttää käyttöjärjestelmän resolveria, ajaa omaa salattua DNS-asiakastaan tai lukea välimuistissa olevan vastauksen eikä koskaan lähettää mitään. Niinpä resolverin loki, joka ei näytä mitään, ei ole todiste siitä, ettei nimeä koskaan käytetty; se on todiste siitä, ettei tältä resolverilta kysytty.

resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pager

Viimeinen komento lukee paikallisen resolverin omaa lokia, mikä ei ole sama kuin ylävirran palvelimen loki. Jos kyselysi lähtevät DNS over HTTPS:n kautta palveluntarjoajalle, paikallinen stub ei välttämättä näytä mitään, kun taas palveluntarjoajalla on täydellinen tallenne, ja palveluntarjoaja on eri operaattori, jolla on eri käytäntö.

Mitä kukin tallenne voi ja ei voi näyttää

Niiden yhdistäminen on varsinainen työ, eikä yhdistäminen ole aina mahdollista. Resolveria, joka kirjaa asiakkaiden osoitteita, voidaan verrata VPN:ään, joka jakaa osoitteita tunnetusta poolista, ja tämä vertailu tuottaa uskottavan yhteyden kysytyn nimen ja tunnelin välille, ja se pysyy kahden tallenteen välisenä yhteytenä eikä henkilön tallenteena.

Salattu DNS muuttaa siirtotietä, ei näkyvyyttä päätepisteessä. Resolver saa edelleen sen kysymyksen, johon se vastaa, kuten RFC 8484 tekee selväksi, ja säilyttäminen siinä resolverissa on käytäntöpäätös eikä protokollan ominaisuus.

Missä jaettu DNS ja välimuistit sotkevat tarinan

Useat resolverit ovat normaaleja. Jaetun DNS:n rakenne lähettää sisäiset nimet sisäiselle palvelimelle ja kaiken muun julkiselle, joten yksi tutkinta voi käsittää kaksi lokia, joita ei koskaan ollut tarkoitus yhdistää, ja kaksi säilytysasetusta, joita ei koskaan ollut tarkoitus verrata. Kyselyjen näkeminen molemmissa on todiste siitä, että rakenne toimii, ei todiste vuodosta.

Välimuistit leikkaavat toiseen suuntaan. Suosittuun nimeen voidaan vastata välimuistista tunteja, joten resolverin tallenne näyttää ensimmäisen kyselyn ja sitten ei mitään, kun käyttäjän sovellus jatkaa saman nimen ratkomista onnellisena. Merkintöjen puuttuminen tietyn ajan jälkeen ei tarkoita, ettei kukaan käyttänyt nimeä sen ajan jälkeen.

Taustaliikenne on kolmas vääristymä. Puhelin, joka ratkoo telemetrianimen käynnistyksessä, selain, joka ratkoo hakuehdotusverkkotunnuksen, ja päivittäjä, joka ilmoittautuu tunneittain, näkyvät kaikki resolverin lokissa sen nimen rinnalla, josta todella välität. Kyseisen lokin volyymi ei ole huomiota, eikä kyselyjen laskeminen ole käyntien laskemista. Resolverin loki on kysymysten tallenne, ja kysymyksiä on halpaa tuottaa.

Kysy säilytyskysymykset erikseen

Kysy jokaiselta järjestelmältä kolme kysymystä: kuka kerää, mitä kerätään ja kuinka kauan sitä säilytetään. Kysy sitten, kuka voi lukea sen ja millä prosessilla. RFC 8484:n keskustelu DNS over HTTPS:stä on hyvä muistutus siitä, ettei salattu siirtotie poista päätepistettä, ja operaattorin oma dokumentaatio on ainoa luotettava lausuma siitä, mitä se päätepiste säilyttää.

Kun yksityisyydestä esitetään väite ”VPN:stä”, jaa se osiin ennen kuin hyväksyt sen: tunnelin operaattori, tunnelin jakama resolver, mikä tahansa ylävirran resolver, jolle nuo kyselyt päätyvät, ja laitteen sovellukset. Jokaisella on oma vastauksensa, ja yhdelle paikkansapitävä väite toistetaan rutiininomaisesti ikään kuin se kattaisi kaikki neljä.

Vianmääritykseen käytä samaa jakoa. Kysy, mikä sovellus teki kyselyn ja mikä resolver vastasi siihen, ja katso lokia, joka todella omistaa sen tapahtuman. Toisesta lokista arvaaminen säästää minuutin ja maksaa iltapäivän.