VPN همیشه فعال اندروید: چگونه نام نقطه پایانی ابتدا حل می شود

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

سازنده VPN در واقع چه می خواهد

یک برنامه VPN اندروید آدرس سرور را به پلتفرم نمی دهد. یک رابط محلی می سازد: آدرس ها و مسیرها برای تونل، حل کننده هایی که برنامه ها باید در داخل استفاده کنند، و سپس establish() یک توصیفگر فایل برمی گرداند که برنامه آن را به عنوان بسته های خام IP می خواند و می نویسد. نقطه پایانی دور هرگز در آن سازنده ظاهر نمی شود.

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

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

دو پرسش DNS، نه یکی

پرسش اول این است: برنامه ها پس از بالا آمدن تونل پرسش های خود را کجا می فرستند؟ پاسخ یک آدرس حل کننده درون تونل است که از طریق رابط tun در دسترس است و به طور طبیعی عددی است.

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

سه مرحله، سه نشانه متفاوت. یک پیام خطای واحد مثل نمی توان متصل شد آن ها را یکی می کند و به همین دلیل مردم فیلد سرور DNS را ویرایش می کنند تا مشکلی را درست کنند که پیش از خوانده شدن آن فیلد رخ می دهد.

چرا راه اندازی می تواند به بن بست برسد

همیشه فعال با مسدودسازی روشن یعنی ترافیکی که درون VPN نیست دور ریخته می شود، از جمله ترافیک برنامه ای که صاحب VPN است. راه خروج صریح است: برنامه protect() را روی یک سوکت صدا می زند که آن را به شبکه زیرین می بندد تا تونل را دور بزند و اجازه خروج بگیرد. هر کلاینت VPN باید این کار را برای انتقال خود انجام دهد وگرنه هرگز به سروری نمی رسد.

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

زمان همان وابستگی را به شکل های ملایم تر نشان می دهد. هنگام راه اندازی پیش از اولین باز کردن قفل، دستگاه ممکن است هنوز شبکه قابل استفاده ای نداشته باشد؛ در یک دروازه اسیر شبکه وجود دارد اما همه چیز جز دروازه را مسدود می کند؛ در گذار از Wi-Fi به شبکه همراه، شبکه زیرین سوکت محافظت شده تغییر می کند و کلاینت باید آن را ببیند و دوباره حل کند. هر یک از این ها یک رویداد راه اندازی است و ارزش آزمون آگاهانه دارد، نه کشف آن در ساعت 3 بامداد.

چرا ثابت کردن پاسخ راه حل نیست

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

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

ثابت کردن معمولا با عادت بد دومی همراه است: سست کردن بررسی های هویت چون اتصال اکنون به شکل دیگری شکست می خورد. بررسی هویت سرور بخشی از مسئله راه اندازی نیست و تضعیف آن یک دردسر DNS را با خطر شنود عوض می کند.

طراحی هایی که از راه اندازی دوباره جان سالم به در می برند

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

جایی که نقطه پایانی باید خصوصی بماند، مسیر راه اندازی صریحی فراهم کنید که پلتفرم بتواند استفاده کند، مانند حل کننده ای که بدون تونل در دسترس است یا اتصال مدیریتی که اپراتور نگه می دارد، و آن استثنا را باریک و تحت سیاست نگه دارید نه تحت کلید کاربر. مستندات Android VpnService مرجع آن چیزی است که پلتفرم درباره حفاظت و چرخه عمر تضمین می کند و مرجع VpnService.Builder تایید می کند که فیلد DNS آدرس های عددی می گیرد.

سپس در سه مرحله به ترتیب روی یک اتصال تازه پس از راه اندازی دوباره بررسی کنید: نام نقطه پایانی حل می شود، تونل برقرار و همتا احراز می شود و یک نام خصوصی از طریق حل کننده تونل حل می شود. اگر مرحله اول شکست بخورد هیچ چیز بعدی نمی تواند کار کند.

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