VPN اندروید نام میزبان کامل را حل می‌کند اما نام کوتاه را نه

شماfilesرا در یک شبیه‌ساز ترمینال تایپ می‌کنید و هیچ چیز برنمی‌گردد؛ تایپ می‌کنیدfiles.corp.exampleو همان سرور بی‌درنگ پاسخ می‌دهد. هیچ چیز در اعتبارنامه‌های VPN تغییر نکرده و سرور DNS خصوصی هرگز خراب نبوده است. در اندروید، برچسب کوتاه و نام کامل مسیرهای متفاوتی را از میان حل‌کننده طی می‌کنند و یکی از این مسیرها به تنظیمی وابسته است که مالک تونل باید فراهم کند. تصمیمی که پیش روی شماست این نیست که کدام سرور DNS را تغییر دهید، بلکه این است که چه کسی شبکه‌ای را که برنامه واقعاً استفاده می‌کند کنترل می‌کند.

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

پسوند جستجو و سرور DNS دو فیلد جداگانه‌اند

نشانی حل‌کننده به اندروید می‌گوید کجا بپرسد. پسوند جستجو می‌گوید وقتی فقط چپ‌ترین برچسب را می‌دهید چه چیزی بپرسد. هر دو روی یک شیء شبکه زندگی می‌کنند و هر کدام می‌توانند به‌تنهایی غایب باشند.

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

اندروید این تفکیک را از طریقLinkPropertiesآشکار می‌کند. فهرست سرورهای DNS و فهرست جستجوی دامنه روی یک شیء قرار دارند و دومی حتی وقتی اولی کاملاً پر است معمولاً خالی است. شبکه‌ای که حل‌کننده دارد اما دامنه ندارد شبکه‌ای است که پسوند هرگز در آن اعمال نشده — نه سروری که نام کوتاه را رد کرده باشد.

پیش از تغییر هر چیزی شبکه مؤثر را بخوانید

Wi-Fi، شبکه همراه و یک رابط VPN سه شبکه جداگانه‌اند و تونل به‌محض بالا آمدن پیش‌فرض می‌شود. بنابراین پسوندی که در Wi-Fi دفتر کار می‌کرد به‌طور خودکار پسوند معتبر هنگام فعال بودن تونل نیست. شبکه‌ای را که برنامه واقعاً روی آن انتخاب شده بررسی کنید، نه شبکه‌ای را که هفته گذشته پیکربندی کردید.

پوسته ترمینال روی دستگاه شاهد ضعیفی است، زیراresolv.confآن تنها یک دیدگاه از حل‌کننده را بازتاب می‌دهد و نه دیدگاه هر برنامه را.

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

اگر برنامه VPN را می‌سازید، پسوند را در سازنده پیوست کنید

وقتی برنامه شما رابط را از طریقVpnService،addSearchDomainبرپا می‌کند، ورودی پشتیبانی‌شده برای این کار است. یک رشته دامنه مانندcorp.exampleرا می‌گیرد و راه جایگزینی برای فرستادن نشانی سرور نیست.

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

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

اگر فقط از VPN استفاده می‌کنید، تنظیم این کار شما نیست

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

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

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

وقتی پسوند وجود دارد و نام‌های کوتاه باز هم شکست می‌خورند

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

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

گواهی‌ها سزاوار ذکر جداگانه‌اند. اعتبارسنجی HTTPS از نام میزبانی استفاده می‌کند که واقعاً تایپ کردید، پس یک نام کوتاه که درست گسترش می‌یابد باز همfilesرا در دست‌دهی ارائه می‌کند. گواهی‌ای که برایfiles.corp.exampleصادر شده باشد برای آن معتبر نخواهد بود، و این خطا رفتار درست است نه نشانه‌ای از مشکل DNS که با آن شروع کردید.

قدم بعدی چه باشد

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

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