Журналы DNS-рэзолвера і журналы VPN-злучэнняў: што ў кожным з іх
Рэзолвер запісвае імёны, на якія яго прасілі адказаць; VPN запісвае падзеі тунэля з уласнай рэалізацыі. Адна палітыка захавання не пакрывае другую.
Журнал DNS-рэзолвера і журнал VPN-злучэнняў — абодва сеткавыя запісы, абодва карысныя і не ўзаемазаменныя. Рэзолвер атрымлівае імёны, на якія яго прасілі адказаць. Канечная кропка VPN апрацоўвае тунэльныя злучэнні і запісвае тое, што яе рэалізацыя вырашыла пра іх запісаць. Яны могуць знаходзіцца ў адным будынку, абслугоўвацца адной камандай і падпадаць пад адно паведамленне пра прыватнасць — і ўсё ж апісваюць розныя падзеі з рознымі ідэнтыфікатарамі і рознымі тэрмінамі захавання. Чытанне аднаго як другога — гэта шлях, якім расследаванні збіваюцца з курсу.
Два журналы, дзве падзеі
Запіс рэзолвера адказвае на пытанне пра імёны: гэты кліент запытаў гэтае імя ў гэты час, і адказам было гэта. Запіс VPN адказвае на пытанне пра злучнасць: гэты аднарангавы вузел усталяваў або страціў тунэль, атрымаў гэты адрас і перадаў прыкладна столькі даных, перш чым знік. Ні адзін з іх не з'яўляецца запісам таго, што карыстальнік рабіў унутры HTTPS-сесіі, і ні адзін не замяняе другі.
Гэтае размежаванне мае практычныя наступствы для абяцанняў. Заява пра тое, што пастаўшчык VPN не запісвае актыўнасць тунэля, нічога не кажа пра рэзолвер, які ён выдае, а палітыка захавання рэзолвера нічога не кажа пра тое, хто падключыўся да тунэля. Кожнае сцвярджэнне належыць свайму аператару і сваёй сістэме.
Прасочыце запыт, перш чым чытаць любы з журналаў
Запыт дасягае рэзолвера толькі тады, калі шлях сапраўды звяртаецца да яго. Праграма можа выкарыстоўваць рэзолвер аперацыйнай сістэмы, запускаць уласны шыфраваны DNS-кліент або чытаць закешаваны адказ і нічога не адпраўляць. Таму журнал рэзолвера, які нічога не паказвае, не з'яўляецца доказам таго, што імя ніколі не выкарыстоўвалася; гэта доказ таго, што ў гэтага рэзолвера не пыталіся.
resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pager
Апошняя каманда чытае ўласны журнал лакальнага рэзолвера, што не тое самае, што журнал вышэйшага сервера. Калі вашыя запыты выходзяць праз DNS over HTTPS да пастаўшчыка, лакальная заглушка можа нічога не паказваць, пакуль у пастаўшчыка ёсць поўны запіс, і пастаўшчык — гэта іншы аператар з іншай палітыкай.
Што кожны запіс можа і не можа паказаць
| Record | Typically shows | Does not show |
|---|---|---|
| Resolver log | Queried name, client address, time, response | Which page was fetched, or what the tunnel did |
| VPN connection log | Peer identity, assigned address, connect and disconnect times, volume | Which name the application asked for |
| Application or proxy log | Requests, status codes, sometimes full URLs | Resolved addresses for every dependency |
Злучыць іх — вось дзе сапраўдная праца, і злучыць іх удаецца не заўсёды. Рэзолвер, які запісвае адрасы кліентаў, можна параўнаць з VPN, які выдае адрасы з вядомага пулу, і гэтае параўнанне стварае праўдападобную сувязь паміж запытаным імем і тунэлем, якая застаецца сувяззю паміж двума запісамі, а не запісам пра чалавека.
Шыфраваны DNS змяняе транспарт, а не бачнасць на канечнай кропцы. Рэзолвер па-ранейшаму атрымлівае пытанне, на якое адказвае, як RFC 8484 ясна паказвае, і захаванне ў гэтым рэзолверы — гэта рашэнне палітыкі, а не ўласцівасць пратакола.
Дзе раздзелены DNS і кэшы заблытваюць гісторыю
Некалькі рэзолвераў — гэта норма. Дызайн з раздзеленым DNS накіроўвае ўнутраныя імёны на ўнутраны сервер, а ўсё астатняе — на публічны, таму адно расследаванне можа закрануць два журналы, якія ніколі не меркавалася аб'ядноўваць, і два налады захавання, якія ніколі не меркавалася параўноўваць. Бачыць запыты ў абодвух — доказ таго, што дызайн працуе, а не доказ уцечкі.
Кэшы рэжуць у іншы бок. Папулярнае імя можа гадзінамі аддавацца з кэша, таму запіс рэзолвера паказвае першы запыт, а потым нічога, у той час як праграма карыстальніка спакойна працягвае вырашаць тое ж імя. Адсутнасць запісаў пасля пэўнага часу не азначае, што пасля гэтага часу імя ніхто не выкарыстоўваў.
Фонавы трафік — трэцяе скажэнне. Тэлефон, які пры загрузцы вырашае імя тэлеметрыі, браўзер, які вырашае дамен пошукавай падказкі, і абнаўляльнік, які штогадзіны выходзіць на сувязь, — усе яны з'яўляюцца ў журнале рэзолвера побач з імем, якое вам сапраўды важнае. Аб'ём у гэтым журнале — не ўвага, і падлік запытаў — не падлік наведванняў. Журнал рэзолвера — гэта запіс пытанняў, а пытанні танна генераваць.
Задавайце пытанні пра захаванне асобна
Для кожнай сістэмы задайце тры пытанні: хто збірае, што збіраецца і як доўга гэта захоўваецца. Затым спытайце, хто можа гэта чытаць і ў рамках якога працэсу. Абмеркаванне RFC 8484 пра DNS over HTTPS — добрае напамін пра тое, што шыфраваны транспарт не выдаляе канечную кропку, а ўласная дакументацыя аператара — адзінае надзейнае сцвярджэнне пра тое, што гэтая кропка захоўвае.
Калі сцвярджэнне пра прыватнасць робіцца пра «VPN», падзяліце яго на кампаненты, перш чым прыняць: аператар тунэля, рэзолвер, які выдае тунэль, любы вышэйшы рэзолвер, якога дасягаюць гэтыя запыты, і праграмы на прыладзе. У кожнага свой адказ, і сцвярджэнне, дакладнае для аднаго, звычайна паўтараюць так, быццам яно ахоплівае ўсе чатыры.
Для пошуку непаладак выкарыстоўвайце тое ж раздзяленне. Спытайце, якая праграма зрабіла запыт і які рэзолвер на яго адказаў, затым паглядзіце на журнал, які сапраўды валодае гэтай падзеяй. Здагадка з іншага журнала эканоміць хвіліну і каштуе паўдня.