آیا DNS VPN شما واقعاً استفاده می‌شود؟ پورت 53 را ضبط کنید و ببینید

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

گزینه هل‌شده یک پرس‌وجو نیست

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

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

بررسی کنید رابط واقعاً چه چیزی نگه می‌دارد

در Linux resolver سیستم می‌تواند فایل ساده، NetworkManager یا systemd-resolved باشد، و اینکه کدام‌یک مالک آن است تعیین می‌کند یک سرور هل‌شده کجا فرود می‌آید. فرایند OpenVPN از خط فرمان خودبه‌خود resolver سیستم را به‌روز نمی‌کند، پس یکپارچه‌سازی مستندشده یک اسکریپت up/down یا یک مدیر اتصال است که از پیش می‌داند تنظیمات را چگونه اعمال کند. اجرای هر دو راهی کارآمد برای ساختن یک مسابقه است.

resolvectl status
cat /etc/resolv.conf

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

یک پرس‌وجو را از دستگاه بیرون دنبال کنید

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

sudo tcpdump -ni tun0 port 53
sudo tcpdump -ni any port 53

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

دیوار آتشی که فقط DNS خودش را می‌پذیرد

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

sudo iptables -S OUTPUT
sudo iptables -S | grep -i -E 'dns|53'

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

sudo iptables -I OUTPUT 1 -p udp --dport 53 -d 172.20.8.1 -j ACCEPT

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

چرا یک صفحه نشت کمتر از آنچه به نظر می‌رسد اثبات می‌کند

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

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