آیا VPN شما DNS را رمزنگاری می‌کند یا فقط پرش بعدی را؟

فعال کردن DNS رمزنگاری‌شده روی سرور VPN اغلب به‌عنوان بستن یک نشتی توصیف می‌شود، و این توصیف پنهان می‌کند که کدام اتصال تغییر کرده است. پرش از کلاینت به حل‌کننده و پرش از حل‌کننده به بالادست دو اتصال جداگانه با دو مالک جداگانه‌اند. رمزنگاری یکی، دیگری را دقیقاً همان‌طور که بود باقی می‌گذارد.

پیش از دست زدن به فایل پیکربندی بنویسید چه کسی پرسش را در هر مرحله دریافت می‌کند.

دو چیدمان در صفحه تنظیمات یکسان به نظر می‌رسند

در چیدمان نخست، دستگاه خودش DNS over TLS را اجرا می‌کند و تونل فقط آن اتصال را به حل‌کننده‌ای که انتخاب کرده‌اید می‌رساند. نشست TLS در حل‌کننده پایان می‌یابد، یعنی حل‌کننده پرسش را می‌بیند و خروجی VPN متن رمزشده‌ای را می‌بیند که نمی‌تواند بخواند. در چیدمان دوم، دستگاه DNS معمولی را از تونل به یک ارسال‌کننده روی میزبان VPN می‌فرستد و آن ارسال‌کننده اتصال رمزنگاری‌شده خودش را به حل‌کننده بالادست باز می‌کند. هر دو در فهرست ویژگی‌ها مانند "DNS رمزنگاری‌شده همراه VPN" به نظر می‌رسند، اما پرسش خواندنی را در دو ساختمان متفاوت قرار می‌دهند.

تفاوت قابل اندازه‌گیری است نه فلسفی. نشست TLS را در کلاینت یا در سرور بجویید تا بدانید واقعاً کدام چیدمان را دارید.

پیش از تغییر، زنجیره حل‌کننده‌ها را ترسیم کنید

حل‌کننده‌های مسیر را بشمارید و نقش هر یک را نام ببرید. یک مؤلفه ارسال، درخواست را به حل‌کننده دیگری می‌سپارد، در حالی که حل‌کننده بازگشتی کار یافتن پاسخ را انجام می‌دهد و ممکن است مستقیماً با سرورهای مرجع گفت‌وگو کند. این نقش‌ها دقیقاً به همین دلیل جداگانه تعریف شده‌اند، و تعریف‌های حل‌کننده در RFC 9076 ارزش خواندن دارند پیش از آنکه فرض کنید یک مقصد بالادست یگانه وجود دارد. میزبانی که حل‌کننده بازگشتی خودش را اجرا می‌کند هیچ "بالادست" یگانه‌ای برای رمزنگاری ندارد، و این کل نقشه را بی‌اعتبار می‌کند.

سپس بپرسید کلاینت برای استفاده از کدام مؤلفه پیکربندی شده است. نشانی DNS که پروفایل VPN می‌فرستد می‌گوید پرسش‌ها کجا می‌روند، نه کدام فرایند به آن‌ها پاسخ می‌دهد.

رفتار هنگام شکست را هم بنگرید. اگر بالادست رمزنگاری‌شده دسترس‌ناپذیر شود، ارسال‌کننده بسته شکست می‌خورد، به متن ساده برمی‌گردد، یا به حل‌کننده دیگری برمی‌گردد؟ این تصمیم باید در سند ثبت شود، زیرا تضمین حریم خصوصی را در لحظه‌ای تغییر می‌دهد که تونل کمترین سلامت را دارد.

بررسی کنید کدام پرش رمزنگاری شده است

از کلاینت شروع کنید و تأیید کنید آیا نشست TLS به درگاه 853 دارد. پرسشی که از درگاه 53 درست حل می‌شود هیچ چیزی درباره رمزنگاری ثابت نمی‌کند.

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

سپس به میزبان VPN بروید و اتصال رمزنگاری‌شده خروجی را که ارسال‌کننده باز کرده است بجویید. جدول سوکت می‌گوید آیا نشست TLS بالادست وجود دارد و کدام فرایند مالک آن است:

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

اگر کلاینت نشست TLS نشان دهد و سرور هیچ، در چیدمان نخست هستید و سرور نمی‌تواند پرسش‌هایی را که در لایه IP ارسال می‌کند بخواند. اگر سرور نشست TLS را نشان دهد و کلاینت ترافیک معمولی درگاه 53 را درون تونل، در چیدمان دوم هستید: پرش بعدی محافظت می‌شود، اما ارسال‌کننده هنوز هر نامی را که دستگاه می‌خواهد می‌خواند. آن نتیجه دوم شکست نیست، اما نامیدنش رمزنگاری سرتاسری نادرست است.

مالک و رفتار هنگام شکست را ثبت کنید

مالکیت تعیین می‌کند چه چیزی را مجازید وعده دهید. مالک دستگاه اتصال رمزنگاری‌شده سمت کلاینت را کنترل می‌کند، در حالی که مدیر VPN اتصال بعدی را که ارسال‌کننده‌اش می‌سازد کنترل می‌کند. هر کس هیچ‌کدام را اداره نکند تنها می‌تواند مسیر را توصیف کند.

پیش از فعال کردن هر چیزی، نام‌گذاری داخلی را بررسی کنید. فرستادن نام‌های سازمانی به حل‌کننده عمومی طراحی هم‌ارز نیست، و ناحیه split-horizon که فقط درون شبکه وجود دارد هرگز در بالادست حل نخواهد شد. پس از تغییر یک نام داخلی و یک نام عمومی را بیازمایید و نتیجه را همراه با تغییر پیکربندی نگه دارید. اگر مسیر رمزنگاری‌شده حل نام میزبان‌های داخلی را بشکند، راه‌حل یک قاعده حل‌کننده با دامنه محدود است نه تونلی گسترده‌تر.

با نوشتن یک جمله برای هر پرش تمام کنید: کدام مؤلفه پرسش را دریافت کرد، آیا آن پرش رمزنگاری شده بود، و چه کسی می‌تواند نام را بخواند. وقتی جمله میزبان VPN هنوز می‌گوید که می‌تواند پرسش‌ها را بخواند، مستندات باید همین را بگوید، زیرا نموداری که خلاف آن را ادعا کند را کسی باور خواهد کرد که هرگز فرمان‌ها را اجرا نکرده است.