DNS اندروید را درست بخوانید: بر اساس شبکه، نه resolv.conf

پوسته‌ای روی دستگاه می‌گیرید، /etc/resolv.conf را می‌خوانید یا مقدار قدیمی net.dns1 را بیرون می‌کشید، و یک نشانی می‌گیرید. اپی که پیش روی شماست از چیز کاملاً دیگری حل می‌کند. در نسخه کنونی اندروید resolver بر اساس شبکه است: سیستم برای هر Network سیاستی نگه می‌دارد و آن را روی socket‌ی اعمال می‌کند که درخواست را فرستاده است. فایل و ویژگی قدیمی بازمانده‌اند و هیچ‌کدام مسیری را که پرس‌وجوی شما واقعاً طی کرده توصیف نمی‌کند.

این شکاف هنگام راه‌اندازی split-tunnel و Private DNS دیده می‌شود، جایی که دو اپ روی یک گوشی می‌توانند به‌طور مشروع پاسخ‌های متفاوت ببینند. این راهنما از حل نادرست یا غایب آغاز می‌شود و به پیکربندی‌ای که مالک آن است بازمی‌گردد.

resolver به یک شبکه تعلق دارد، نه به دستگاه

حل نام در Android 9 و بالاتر از resolver سیستمی می‌گذرد که بر پایه Network‌ی است که socket به آن بسته شده است. هر شبکه LinkProperties خودش را دارد و این ویژگی‌ها فهرست سرورهای DNS، دامنه‌های جست‌وجو و وضعیت Private DNS را فقط برای همان شبکه نگه می‌دارند. هیچ‌چیز در این مدل با یک فهرست سراسری دستگاه که از فایل بخوانید مطابقت ندارد.

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

تصویر لحظه‌ای را از درون اپ آسیب‌دیده بخوانید

از خود اپ بپرسید. متدی که Context و مجوز معمول android.permission.ACCESS_NETWORK_STATE را دارد می‌تواند تصویر لحظه‌ای را بدون دست‌زدن به ویژگی‌های سیستم بخواند:

val cm = getSystemService(ConnectivityManager::class.java) ?: return
val network = cm.activeNetwork
val links = network?.let { cm.getLinkProperties(it) }

val dnsServers = links?.dnsServers
val privateDnsActive = links?.isPrivateDnsActive
val privateDnsName = links?.privateDnsServerName

activeNetwork شبکه پیش‌فرض فرایند شماست، نه تنها شبکه دستگاه، و می‌تواند null باشد وقتی فراخواننده پیش‌فرض قابل‌استفاده‌ای ندارد. VPN پیش‌فرض مسدود دلیل معمول است. isPrivateDnsActive می‌گوید آیا پرس‌وجوهای آن شبکه از TLS به resolver نام‌دار می‌روند، که تغییر می‌دهد کاوش ساده UDP 53 چه نشان می‌دهد. سطح API زیر LinkProperties مستند شده است و هر مقدار در آن تصویر لحظه‌ای پیکربندی است، نه اثبات اینکه پرس‌وجوی خاصی به سرور خاصی رسیده باشد.

وقتی شبکه پیش‌فرض آن نیست که کار را انجام می‌دهد

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

یکپارچگی VPN نیمه دیگر است. دریافت خط dhcp-option DNS در نمایه OpenVPN و ثبت آن نشانی روی شبکه VPN اندروید دو گام جداست، و مسیر گم‌شده به سرور همان‌قدر بی‌صدا شکست می‌خورد که نشانی نادرست. از ماشین توسعه، adb shell dumpsys connectivity همان ویژگی‌های پیوند را بر اساس شبکه چاپ می‌کند وقتی build اجازه دهد، که فهرست را بدون نوشتن کد تأیید می‌کند.

پیکربندی را با یک حلی که مجاز به انجامش هستید مقایسه کنید

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

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

لایه‌ای را که مالک ناسازگاری است درست کنید

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

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

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