OpenVPN در اندروید: افزودن یک مسیر خصوصی بدون روت کردن گوشی
یک مسیر را داخل همان پروفایلی که اندروید واقعاً بارگذاری می‌کند اضافه کنید و سپس بررسی کنید که سرور آن را مجاز می‌داند. راهنمای ویرایش، اتصال دوباره و چهار بررسی.
شما به یک زیرشبکه خصوصی دیگر نیاز دارید — مثلاً 10.60.0.0/24 — که پروفایل اکنون آن را ندارد. روی لپ‌تاپ یک مسیر اضافه می‌کردید و ادامه می‌دادید. در اندروید، VPN یک برنامه است، دستگاه tun متعلق به همان برنامه است و بدون روت جدول مسیریابی‌ای برای ویرایش وجود ندارد. مسیر باید وجود داشته باشد، اما داخل پروفایلی می‌رود که کلاینت بارگذاری می‌کند و تنها زمانی کار می‌کند که طرف مقابل موافق باشد. اینجا ویرایش، اتصال دوباره، سمت سرور و بازگردانی را داریم.
پیش از ویرایش: یک مسیر چه کاری می‌تواند بکند و چه کاری نه
یک مسیر به یک پرسش پاسخ می‌دهد: کدام رابط باید ترافیک این مقصد را حمل کند. این هیچ چیزی را مجاز نمی‌کند. اگر مالک شبکه موافقت نکرده باشد که این گوشی به آن زیرشبکه برسد، یک مسیر درست پیکربندی درست‌نما و یک افت بی‌صدا در دروازه تولید می‌کند و ساعت بعد را صرف ویرایش فایل اشتباه خواهید کرد.
اول آن توافق را بگیرید، اگر شبکه مالک دارد به‌صورت کتبی. سپس یادداشت کنید چه کاری نمی‌کنید: به گوشی آدرسی درون آن LAN نمی‌دهید، شنونده سرور را تغییر نمی‌دهید و سایتی را با نام میزبان انتخاب نمی‌کنید. اینها چهار تغییر متفاوت‌اند و فقط اولی مال شماست.
| The route gives you | The route does not give you |
|---|---|
| A destination prefix associated with the tunnel | Permission to forward at the gateway |
| A path for the phone's own traffic | A return route on the target host |
| A scope for the client's virtual interface | A name in DNS, or HTTPS identity |
همان پروفایلی را ویرایش کنید که کلاینت واقعاً بارگذاری می‌کند
برای کلاینتی سازگار که متن گزینه‌های معمول OpenVPN را وارد می‌کند، افزودن یک خط است:
route 10.60.0.0 255.255.255.0آن را به بدنه پروفایل، نزدیک دیگر دستورهای مسیریابی، اضافه کنید و endpoint، گواهی‌ها، مدیریت کلید و خطوط بررسی اپراتور را دقیقاً همان‌گونه که بودند نگه دارید. یک نمونه قدیمی کامل را برای قرض گرفتن یک خط نچسبانید: فشرده‌سازی، مسیرهای مطلق فایل و تنظیمات منسوخ cipher همراه آن می‌آیند و یک جلسه اشکال‌زدایی جداگانه برایتان هزینه می‌کنند.
گامی که مردم از دست می‌دهند مالکیت فایل است. اگر برنامه پروفایلی را وارد کرده باشد، نسخه‌ای که استفاده می‌کند مال برنامه است و ویرایش فایل اصلی دانلودشده چیزی را تغییر نمی‌دهد. از ویرایشگر پشتیبانی‌شده کلاینت استفاده کنید یا فایل ویرایش‌شده را از مسیر به‌روزرسانی دوباره وارد کنید، و وقتی چند نام مشابه وجود دارد نام پروفایل فعال را تأیید کنید. ثبت کنید کدام را تغییر دادید.
اگر پروفایل از قبل route-nopull داشته باشد، هیچ مسیری از سرور نصب نمی‌شود و هر پیشوندی که گوشی لازم دارد باید صریحاً فهرست شود. این طراحی مشروعی است، اما یعنی یک خط جاافتاده دقیقاً مانند رد شدن از سوی سرور به نظر می‌رسد.
اتصال دوباره و بررسی روی دستگاه
اول قطع کنید، سپس همان پروفایل مشخصی را که ویرایش کردید دوباره وصل کنید، نه اینکه برنامه آخرین نشست را بازیابی کند. گزارش اتصال را باز کنید و تأیید کنید کلاینت خط جدید را تجزیه کرده است؛ دستور مسیریابی‌ای که رابط کاربری نادیده می‌گیرد نتیجه رایج ویرایش نسخه اشتباه است.
مقصد را با آدرس آزمایش کنید، نه با نام. یک بررسی TCP به یک درگاه سرویس شناخته‌شده اطلاعات بیشتری از ping می‌دهد، چون بسیاری از میزبان‌ها به ICMP پاسخ می‌دهند در حالی که درگاه سرویس فیلتر شده است. اگر آدرس پاسخ دهد و نام پاسخ ندهد، مسئله resolver دارید نه مسیریابی، و بخش بعدی برای شما نیست.
دو بررسی دامنه هم اینجا جا دارند. VPN به‌ازای هر برنامه یعنی ممکن است مسیر آدرس وجود داشته باشد در حالی که برنامه‌ای که با آن آزمایش می‌کنید بیرون مجموعه شامل است، پس با برنامه‌ای آزمایش کنید که واقعاً درون آن است. و یک پیشوند IPv4 درباره مسیر IPv6 چیزی نمی‌گوید؛ اگر سرویس dual-stack است، مسیر IPv6 مربوطه را اضافه کنید یا انتظار داشته باشید کلاینت مسیری را ترجیح دهد که قصدش را نداشتید.
یک نتیجه منفی ارزش شناخت زودهنگام را دارد: اگر مسیر full-tunnel از قبل 0.0.0.0/0 را پوشش دهد، پیشوند گم نشده است و افزودن دوباره آن چیزی را تغییر نمی‌دهد. پوشش تکراری یک رد سمت سرور یا پاسخ گم‌شده را ترمیم نمی‌کند.
مسیر را روی سرور تمام کنید
سه چیز بیرون از گوشی باید درست باشد. دروازه به مسیری به مقصد و اجازه ارسال بسته‌های مبدأ گوشی به سمت آن نیاز دارد. مقصد باید آن مبدأ را بپذیرد و پاسخ‌ها را از طریق دروازه برگرداند، وگرنه طراحی به ترجمه آگاهانه در خروجی نیاز دارد. گزینه route در راهنمای OpenVPN دستور سمت کلاینت را پوشش می‌دهد؛ ارسال و مسیریابی برگشت تنظیمات جداگانه‌ای روی ماشین‌های جداگانه‌اند.
اگر مقصد پشت کلاینت VPN دیگری باشد نه مستقیماً پشت دروازه، سرور به یک iroute برای زیرشبکه آن همتا نیاز دارد. آن دستور متعلق به سرور است و توضیح می‌دهد کدام کلاینت مالک یک پیشوند است؛ گوشی نمی‌تواند آن را از پروفایل خودش تأمین کند و هیچ مقدار ویرایش سمت کلاینت جای آن را نمی‌گیرد.
مسیر برگشت را صریحاً بررسی کنید. پاسخی که به‌جای تونل از مسیر پیش‌فرض خارج شود نشانه کلاسیک نیمه‌باز را تولید می‌کند: اتصال در یک جهت برقرار است و چیزی برنمی‌گردد. ترجمه مبدأ روی دروازه وقتی مقصد نمی‌تواند برگردد اصلاح مشروعی است، اما تصمیمی سیاستی با پیامدهای خودش است.
بازگردانی و پذیرش
پروفایل قبلی را پیش از ویرایش نگه دارید. اگر تغییر وضع را بدتر کرد، همان نسخه را از همان مسیر وارد‌کردن دوباره بازگردانید، دوباره وصل شوید و تأیید کنید رفتار قدیمی برمی‌گردد — این تأیید می‌کند چیزی را که فکر می‌کردید تغییر داده‌اید واقعاً تغییر کرده است. بازگردانی‌ای که وضعیت قدیمی را برنگرداند یعنی برنامه نسخه سومی را نگه داشته که پیدا نکرده‌اید.
تغییر را وقتی چهار چیز برقرار باشد بپذیرید، که پس از یک اتصال تازه به این ترتیب آزمایش می‌شوند: مقصد روی درگاه سرویسش پاسخ می‌دهد، نام خصوصی در صورت انتظار حل می‌شود، HTTPS هنوز نام میزبان موردنظر را معتبر می‌داند، و همه‌چیز پس از راه‌اندازی مجدد یا تغییر از Wi-Fi به شبکه همراه همچنان کار می‌کند. آخرین بررسی همان است که مسیری را می‌گیرد که فقط تا زمانی وجود دارد که اندروید تونل را دوباره برقرار کند.
- پیش از هر ویرایشی تأیید کنید که مالک شبکه مقصد را مجاز می‌داند.
- مسیر را در پروفایلی که کلاینت بارگذاری می‌کند بگذارید، سپس دوباره وارد کنید و وصل شوید.
- از طریق درگاه سرویس، درون دامنه هر برنامه، برای خانواده آدرس درست بررسی کنید.
- ارسال، مسیریابی برگشت و iroute را روی سرور درست کنید، نه روی گوشی.
- یک نسخه بازگردانی نگه دارید و پس از راه‌اندازی مجدد دوباره آزمایش کنید.