DNS-feloldó naplók és VPN-kapcsolat naplók: mit tartalmaz mindegyik

A DNS-feloldó napló és a VPN-kapcsolat napló is hálózati feljegyzés, mindkettő hasznos, és nem felcserélhetők. A feloldó azokat a neveket kapja, amelyekre választ kértek tőle. A VPN végpont az alagútkapcsolatokat kezeli, és rögzíti azt, amit a megvalósítása ezekről rögzíteni választott. Lehetnek ugyanabban az épületben, ugyanaz a csapat üzemeltetheti őket, és ugyanaz az adatvédelmi tájékoztató vonatkozhat rájuk, mégis különböző eseményeket írnak le különböző azonosítókkal és különböző megőrzéssel. Az egyiket a másikként olvasni az az út, amelyen a vizsgálatok félremennek.

Két napló, két esemény

A feloldó bejegyzése az elnevezésre vonatkozó kérdésre válaszol: ez az ügyfél ebben az időben ezt a nevet kérte, és a válasz ez volt. A VPN bejegyzése a kapcsolódásra vonatkozó kérdésre válaszol: ez a partner alagutat hozott létre vagy veszített el, ezt a címet kapta, és körülbelül ennyi adatot továbbított, mielőtt eltűnt. Egyik sem feljegyzés arról, hogy a felhasználó mit tett egy HTTPS-munkameneten belül, és egyik sem helyettesíti a másikat.

A különbségnek gyakorlati következménye van az ígéretekre. Az az állítás, hogy egy VPN-szolgáltató nem naplózza az alagút forgalmát, semmit sem mond az általa kiosztott feloldóról, és egy feloldó megőrzési szabályzata semmit sem mond arról, ki kapcsolódott az alagúthoz. Minden állítás a saját üzemeltetőjéhez és a saját rendszeréhez tartozik.

Kövesse a lekérdezést, mielőtt bármelyik naplót elolvasná

Egy lekérdezés csak akkor ér el a feloldóhoz, ha az útvonal ténylegesen tőle kérdez. Egy alkalmazás használhatja az operációs rendszer feloldóját, futtathat saját titkosított DNS-ügyfelet, vagy olvashat egy gyorsítótárazott választ, és soha semmit sem küld. Tehát egy feloldó napló, amely semmit sem mutat, nem bizonyítéka annak, hogy egy nevet soha nem használtak; annak bizonyítéka, hogy ezt a feloldót nem kérdezték.

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

Az utolsó parancs a helyi feloldó saját naplóját olvassa, ami nem ugyanaz, mint a felsőbb kiszolgáló naplója. Ha a lekérdezései DNS over HTTPS-en keresztül egy szolgáltatóhoz mennek ki, a helyi stub semmit sem mutathat, miközben a szolgáltatónál van a teljes feljegyzés, és a szolgáltató egy másik üzemeltető más szabályzattal.

Mit mutathat és mit nem mutathat az egyes feljegyzések

Ezek összekapcsolása az igazi munka, és az összekapcsolás nem mindig lehetséges. Az ügyfélcímeket naplózó feloldó összevethető egy olyan VPN-nel, amely ismert készletből oszt ki címeket, és ez az összevetés hihető kapcsolatot hoz létre egy lekérdezett név és egy alagút között, amely két feljegyzés közötti kapcsolat marad, nem pedig egy személy feljegyzése.

A titkosított DNS a szállítást változtatja meg, nem a láthatóságot a végponton. A feloldó továbbra is megkapja azt a kérdést, amelyre válaszol, ahogyan RFC 8484 egyértelművé teszi, és az adott feloldónál való megőrzés szabályzati döntés, nem a protokoll tulajdonsága.

Ahol a megosztott DNS és a gyorsítótárak összezavarják a történetet

Több feloldó normális. A megosztott DNS-t használó kialakítás a belső neveket belső kiszolgálóra, minden mást nyilvánosra küld, így egyetlen vizsgálat két olyan naplót érinthet, amelyeket soha nem szántak összevonásra, és két olyan megőrzési beállítást, amelyeket soha nem szántak összehasonlításra. Lekérdezések látása mindkettőben annak bizonyítéka, hogy a kialakítás működik, nem pedig szivárgás bizonyítéka.

A gyorsítótárak a másik irányba vágnak. Egy népszerű névre órákig válaszolhat a gyorsítótár, így a feloldó feljegyzése az első lekérdezést mutatja, aztán semmit, miközben a felhasználó alkalmazása boldogan tovább oldja ugyanazt a nevet. A bejegyzések hiánya egy bizonyos idő után nem jelenti azt, hogy utána senki nem használta a nevet.

A háttérforgalom a harmadik torzítás. Az indításkor telemetrianévre kérdező telefon, a keresési javaslat tartományát feloldó böngésző és az óránként jelentkező frissítő mind megjelenik egy feloldó naplóban azon név mellett, amely valóban számít Önnek. A mennyiség abban a naplóban nem figyelem, és a lekérdezések számolása nem a látogatások számolása. A feloldó napló a kérdések feljegyzése, a kérdéseket pedig olcsó előállítani.

Tegye fel a megőrzési kérdéseket külön

Minden rendszernél tegyen fel három kérdést: ki gyűjti, mit gyűjtenek, és meddig őrzik meg. Aztán kérdezze meg, ki olvashatja, és milyen folyamat keretében. Az RFC 8484 DNS over HTTPS-ről szóló vitája jó emlékeztető arra, hogy a titkosított szállítás nem szünteti meg a végpontot, és egy üzemeltető saját dokumentációja az egyetlen megbízható állítás arról, hogy az a végpont mit őriz meg.

Amikor egy adatvédelmi állítás „a VPN-ről” szól, bontsa összetevőkre, mielőtt elfogadja: az alagút üzemeltetője, az alagút által kiosztott feloldó, minden felsőbb feloldó, amelyet ezek a lekérdezések elérnek, és az eszközön lévő alkalmazások. Mindegyiknek megvan a maga válasza, és az egyikre pontos állítást rendszeresen úgy ismételnek, mintha mind a négyet lefedné.

Hibaelhárításhoz ugyanezt a felosztást használja. Kérdezze meg, melyik alkalmazás tette a lekérdezést és melyik feloldó válaszolt rá, majd nézze meg azt a naplót, amely valóban birtokolja azt az eseményt. A másik naplóból való találgatás egy percet spórol és egy délutánba kerül.