VPN از طریق DNS با سرور DNS یک VPN یکی نیست

VPN از طریق DNS یک ایده انتقال را توصیف می‌کند و مترادف با نشانه‌رفتن یک دستگاه به resolver سفارشی نیست. پرسشی که ابهام را برطرف می‌کند ساده است: پیام‌های DNS در واقع چه چیزی را حمل می‌کنند؟ یک VPN معمولی ممکن است resolver نصب کند تا برنامه‌های پوشش‌داده‌شده نام‌های خصوصی را پیدا کنند، و تغییر آن resolver فقط تفکیک نام را تغییر می‌دهد. بررسی‌های زیر را به ترتیب اجرا کنید، چون سه آرایش واژگان را مشترک‌اند و تقریباً هیچ چیز دیگری.

سه آرایش را از هم جدا کنید

در آرایش اول، VPN یک resolver یا تنظیم سیاست نام فراهم می‌کند. داده‌های برنامه همچنان از اتصال‌های شبکه خودش عبور می‌کند و تونل فقط بر اینکه کدام سرور به پرس‌وجو پاسخ می‌دهد اثر می‌گذارد.

در دومی، DNS رمزگذاری‌شده خودِ تبادل DNS را محافظت می‌کند. DNS روی HTTPS و DNS روی TLS پرس‌وجوها را به resolver انتخابی می‌پیچند و بسته‌های هیچ برنامه دیگری را حمل نمی‌کنند. آن‌ها نام‌های پرس‌وجو را از resolverی که انتخاب کرده‌اید پنهان نمی‌کنند هم، که مرز اعتماد متفاوتی از پنهان‌کردن آن‌ها از شبکه محلی است.

در سومی، یک کلاینت همکار داده‌های دیگر را در پیام‌های DNS رمزگذاری می‌کند و یک نقطه پایانی همکار آن را بازسازی می‌کند. مسیر عادی resolver به انتقال تبدیل می‌شود و resolver اکنون جزئی از مسیر داده است نه یک سرویس نام.

بررسی کنید پیام‌های DNS چه چیزی را حمل می‌کنند

resolver را تغییر دهید و ببینید آیا مسیر ترافیک برنامه تغییر می‌کند. اگر برنامه هنوز از همان سوکت‌ها به همان نشانی‌ها متصل می‌شود، شما تفکیک نام را تغییر داده‌اید و نه چیز دیگری.

تونلی که از طریق DNS حمل می‌شود به آرایش متناظر در سمت سرور نیاز دارد. Iodine نمونه‌ای مستند است: مستندات پروژه یک تونل IP از طریق DNS را توصیف می‌کند و به مؤلفه سروری نیاز دارد که رمزگذاری را بفهمد. واردکردن نشانی resolver عمومی در Android آن نقطه پایانی را فراهم نمی‌کند، و اصطلاح بازاریابی مشترک میان دو محصول مشخصه یک پروتکل نیست.

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

پیش از تعهد، ظرفیت را بررسی کنید

DNS برای پرس‌وجو و پاسخ طراحی شده است، نه برای تحویل انبوه. سرباز رمزگذاری، محدودیت‌های اندازه پیام و رفتار resolver همه سهمی از مسیر اسمی می‌گیرند، پس ظرفیت مفید کمتر از آن است که پیوند زیرین نشان می‌دهد. هر رقم توان‌دهی را که در مسیر خودتان اندازه نگرفته‌اید به‌عنوان فرضیه ببینید نه بودجه. هر دو جهت را اندازه بگیرید، چون بارگذاری و بارگیری می‌توانند در یک حامل پرسش-پاسخ به محدودیت‌های متفاوتی برخورد کنند.

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

با همان ترافیکی که می‌خواهید حمل کنید اندازه بگیرید. تونلی که برای ضربان دوره‌ای خوب به نظر می‌رسد ممکن است برای یک نشست تعاملی بی‌استفاده باشد، و برعکسش هم درست است.

امنیت حامل را بررسی کنید

فرض نکنید که کپسوله‌سازی DNS محرمانگی یا احراز هویت قوی فراهم می‌کند. مسیر resolver و نقطه پایانی تونل آنچه پیاده‌سازی آشکار می‌کند را می‌بینند، و این آشکارسازی بسته به طراحی متفاوت است.

رمزگذاری و انتخاب حامل ویژگی‌های جداگانه‌اند. یک تونل می‌تواند روی مسیر IP ساده رمزگذاری شود، و یک تونل حمل‌شده در DNS می‌تواند با یا بدون محافظت از بار داده‌اش ساخته شود. در هر حال HTTPS برنامه را سر جایش نگه دارید و طراحی امنیتی واقعی تونل را ارزیابی کنید نه نامش را.

اگر نیاز، محرمانگی در برابر شبکه محلی است، DNS رمزگذاری‌شده و یک تونل داده بخش‌های متفاوتی از آن را پاسخ می‌دهند. پیش از انتخاب یکی، بنویسید از کدام ناظر دفاع می‌کنید.

راه‌حل را با خرابی واقعی تطبیق دهید

برای یک VPN کند معمولی، جایگزین‌کردن با تونل حمل‌شده در DNS یک انتقال محدود روی مشکل اضافه می‌کند. این کار کیفیت رادیو، ازدحام یا بار سرور را درست نمی‌کند و معمولاً آن‌ها را نمایان‌تر می‌کند.

برای خرابی نام‌های خصوصی، ابتدا سیاست resolver موردنظر را بررسی کنید: کدام سرور باید پاسخ دهد، کدام نام‌ها در دامنه‌اند و آیا کلاینت اجازه استفاده از آن را دارد. سپس یک انتقال مجاز را انتخاب کنید که با نیاز مطابقت دارد، و پیکربندی resolver را در سابقه تغییرات نگه دارید تا رخداد بعدی همان جست‌وجو را از نو شروع نکند.

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