DNS hal qiluvchi jurnallari va VPN ulanish jurnallari: har biri nimani saqlaydi
Hal qiluvchi o'zidan javob berish so'ralgan nomlarni yozib boradi; VPN tunnel hodisalarini o'z tatbiqidan yozadi. Bitta saqlash siyosati ikkinchisini qoplamaydi.
DNS hal qiluvchi jurnali va VPN ulanish jurnali ikkalasi ham tarmoq yozuvlari, ikkalasi ham foydali va bir-birini almashtirmaydi. Hal qiluvchi o'zidan javob berish so'ralgan nomlarni qabul qiladi. VPN oxirgi nuqtasi tunnel ulanishlarini boshqaradi va uning tatbiqi ular haqida yozishni tanlaganini yozadi. Ular bir binoda bo'lishi, bir jamoa boshqarishi va bir maxfiylik xabarnomasi qamrab olishi mumkin, shunga qaramay turli identifikatorlar va turli saqlash muddati bilan turli hodisalarni tavsiflaydi. Birini ikkinchisi sifatida o'qish — tekshiruvlar yo'ldan chiqadigan yo'l.
Ikki jurnal, ikki hodisa
Hal qiluvchi yozuvi nomlash haqidagi savolga javob beradi: bu mijoz shu vaqtda shu nomni so'radi va javob shu edi. VPN yozuvi ulanish haqidagi savolga javob beradi: bu hamkor tunnel o'rnatdi yoki yo'qotdi, unga shu manzil berildi va ketishdan oldin taxminan shuncha ma'lumot uzatdi. Ikkalasi ham HTTPS sessiyasi ichida foydalanuvchi nima qilganining yozuvi emas va hech biri ikkinchisini almashtirmaydi.
Bu farq va'dalar uchun amaliy natijaga ega. VPN provayderi tunnel faoliyatini yozmaydi degan bayonot uning taqdim etadigan hal qiluvchisi haqida hech narsa demaydi, hal qiluvchining saqlash siyosati esa tunnelga kim ulanganligi haqida hech narsa demaydi. Har bir da'vo o'z operatoriga va o'z tizimiga tegishli.
Istalgan jurnalni o'qishdan oldin so'rovni kuzatib boring
So'rov hal qiluvchiga faqat yo'l haqiqatan undan so'raganda yetib boradi. Ilova operatsion tizim hal qiluvchisidan foydalanishi, o'zining shifrlangan DNS mijozi ishlatishi yoki keshdagi javobni o'qib, hech narsa yubormasligi mumkin. Shuning uchun hech narsa ko'rsatmaydigan hal qiluvchi jurnali nom hech qachon ishlatilmaganligining dalili emas; bu hal qiluvchidan so'ralmaganligining dalili.
resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pagerOxirgi buyruq mahalliy hal qiluvchining o'z jurnalini o'qiydi, bu yuqori server jurnali bilan bir xil emas. Agar so'rovlaringiz DNS over HTTPS orqali provayderga chiqsa, mahalliy stub hech narsa ko'rsatmasligi mumkin, provayderda esa to'liq yozuv bo'ladi va provayder boshqa siyosatga ega boshqa operator.
Har bir yozuv nimani ko'rsata oladi va nimani ko'rsata olmaydi
| 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 |
Ularni bog'lash — asosiy ish, va bog'lash har doim ham mumkin emas. Mijoz manzillarini yozadigan hal qiluvchini ma'lum hovuzdan manzil beradigan VPN bilan solishtirish mumkin, va bu solishtirish so'ralgan nom bilan tunnel orasida ishonchli bog'lanish yaratadi, u ikki yozuv orasidagi bog'lanish bo'lib qoladi, shaxsning yozuvi emas.
Shifrlangan DNS tashishni o'zgartiradi, oxirgi nuqtadagi ko'rinishni emas. Hal qiluvchi o'zi javob beradigan savolni hanuz oladi, RFC 8484 aniq ko'rsatganidek, va o'sha hal qiluvchida saqlash protokol xususiyati emas, siyosat qarori.
Bo'lingan DNS va keshlar voqeani qayerda chalkashtiradi
Bir nechta hal qiluvchi odatiy hol. Bo'lingan DNS dizayni ichki nomlarni ichki serverga, qolganini ochiq serverga yuboradi, shuning uchun bitta tekshiruv hech qachon birlashtirish uchun mo'ljallanmagan ikki jurnalni va hech qachon solishtirish uchun mo'ljallanmagan ikki saqlash sozlamasini qamrab olishi mumkin. Ikkalasida ham so'rovlarni ko'rish dizayn ishlayotganining dalili, oqib chiqishning dalili emas.
Keshlar qarama-qarshi tomonga kesadi. Mashhur nomga soatlab keshdan javob berilishi mumkin, shuning uchun hal qiluvchining yozuvi birinchi so'rovni ko'rsatadi, keyin hech narsa ko'rsatmaydi, foydalanuvchi ilovasi esa o'sha nomni xursandchilik bilan hal qilishda davom etadi. Muayyan vaqtdan keyin yozuvlar yo'qligi o'sha vaqtdan keyin nom hech kim ishlatmaganligini bildirmaydi.
Fon trafigi — uchinchi buzilish. Yuklanishda telemetriya nomini hal qiladigan telefon, qidiruv taklifi domenini hal qiladigan brauzer va har soatda bog'lanadigan yangilagich — barchasi hal qiluvchi jurnalida sizga haqiqatan muhim nom yonida ko'rinadi. O'sha jurnaldagi hajm e'tibor emas, va so'rovlarni sanash tashriflarni sanash emas. Hal qiluvchi jurnali savollarning yozuvi, va savollarni yaratish arzon.
Saqlash haqidagi savollarni alohida bering
Har bir tizim uchun uchta savol bering: kim yig'adi, nima yig'iladi va qancha vaqt saqlanadi. Keyin uni kim o'qiy olishini va qanday tartibda ekanini so'rang. DNS over HTTPS haqidagi RFC 8484 muhokamasi shifrlangan tashish oxirgi nuqtani olib tashlamasligini yaxshi eslatadi, va operatorning o'z hujjatlari o'sha oxirgi nuqta nimani saqlashi haqidagi yagona ishonchli bayonot.
Maxfiylik haqida «VPN» to'g'risida da'vo qilinganda, uni qabul qilishdan oldin tarkibiy qismlarga bo'ling: tunnel operatori, tunnel taqdim etadigan hal qiluvchi, o'sha so'rovlar yetib boradigan har qanday yuqori hal qiluvchi va qurilmadagi ilovalar. Har birining o'z javobi bor, va bittasi uchun to'g'ri da'vo to'rttasini ham qamrab olgandek muntazam takrorlanadi.
Muammolarni hal qilish uchun o'sha bo'linishdan foydalaning. Qaysi ilova so'rov qilganini va qaysi hal qiluvchi javob berganini so'rang, keyin haqiqatan o'sha hodisaga egalik qiladigan jurnalga qarang. Boshqa jurnaldan taxmin qilish bir daqiqani tejaydi va bir tushdan keyinni sarflaydi.