سرور VPN اندروید: روت گوشی را قابل‌دسترس نمی‌کند
سه مسئلهٔ جدا تعیین می‌کند آیا گوشی می‌تواند به مشتریان VPN خدمت دهد: مسیر ورودی، مدل دسترسی و فورواردینگ. روت فقط به وسطی دست می‌زند.
روت تغییر می‌دهد که یک فرایند مجاز به تلاش برای کدام عملیات شبکه باشد. اما به گوشی یک نشانی عمومی قابل‌دسترس نمی‌دهد، نگاشت ورودی نزد اپراتور رزرو نمی‌کند و دیمن را پس از راه‌اندازی مجدد زنده نگه نمی‌دارد. اگر می‌خواهید تصمیم بگیرید آیا گوشی اندروید می‌تواند نقش سرور VPN را بازی کند، سه پرسش را جدا کنید: آیا مشتری موردنظر اصلاً به شنونده می‌رسد، پیاده‌سازی سرور به کدام مدل دسترسی نیاز دارد، و پس از بالا آمدن تونل چه چیزی باید فوروارد شود.
چه کسی و از کجا باید به گوشی برسد
مشتری در همان LAN مجاز و مشتری روی دادهٔ همراه دو شبکهٔ متفاوت را می‌آزمایند. اول مشخص کنید کدام موردنظر است، چون پاسخ‌ها به هم منتقل نمی‌شوند. در Wi-Fi ترافیک ورودی ناخواسته معمولاً به نگاشت روی روتر بالادست و مسیر عمومی قابل‌استفاده‌ای فراتر از آن نیاز دارد. در شبکهٔ سلولی، NAT در سطح اپراتور یعنی IPv4 ورودی غالباً در دسترس نیست، هرچه گوشی اجازه دهد.
همین نکتهٔ آخر همان چیزی است که روت به آن دست نمی‌زند. فایروال محلی گوشی و NAT اپراتور دو سامانهٔ متفاوت‌اند و تغییر اولی بر دومی اثری ندارد. نشانی خصوصی واسط، نماد دادهٔ همراه یا سوکت شنونده هیچ‌کدام شاهد دسترس‌پذیری نیستند. اگر مسیر اپراتور واقعاً IPv6 قابل‌مسیریابی جهانی ارائه می‌دهد، باز هم به سیاست شنونده و فایروال آگاهانه برای آن نیاز دارید؛ داشتن نشانی با پذیرفتن اتصال‌ها یکی نیست.
| Client path | What actually decides reachability |
|---|---|
| Same LAN | The phone's listener and its local firewall |
| Wi-Fi, from the internet | A mapping on the upstream router plus a usable public path beyond it |
| Cellular IPv4 | The carrier's NAT, which the handset does not control |
| Cellular IPv6 | Address, listener and firewall policy together |
خدمت‌دهی و فورواردینگ دو موفقیت متفاوت‌اند
دست‌دهی کامل‌شدهٔ VPN ثابت می‌کند تونل وجود دارد. ثابت نمی‌کند مشتری می‌تواند به LAN پشت گوشی برسد، و ثابت نمی‌کند گوشی می‌تواند خروجی اینترنت باشد. این‌ها پیکربندی‌های جدایی هستند که بر طرح نشانی درونی، مسیرها، رفتار بازگشت و سیاست فورواردینگ باریک برای کاری که واقعاً می‌خواهید بنا می‌شوند.
الگوی شکست قابل‌پیش‌بینی است: دست‌دهی موفق می‌شود، مشتری متصل نشان داده می‌شود و هیچ چیز بارگذاری نمی‌شود. پیش از اشکال‌زدایی مشتری، تصمیم بگیرید کدام یک از دو نقش را می‌سازید. دسترسی از راه دور به دستگاهی در شبکهٔ گوشی و خروجی اینترنت با تونل کامل به قواعد فورواردینگ متفاوتی نیاز دارند، و دادن هر دو وقتی یکی را می‌خواستید، سطح مواجهه را گسترش می‌دهد بدون افزودن توانایی‌ای که خواسته بودید.
مدل دسترسی یک انتخاب است، نه روت یا هیچ
دیمن متعارف OpenVPN که از دستگاه TUN هسته استفاده می‌کند به توانایی‌های متناظر، دسترسی به گرهٔ دستگاه و همکاری سیاست امنیتی اندروید نیاز دارد. روت معافیت فراگیر از SELinux نیست؛ فرایند دارای امتیاز همچنان با سیاست پلتفرم محدود است. به همین دلیل باینری‌ای که روی سرور Linux راحت اجرا می‌شود، می‌تواند روی گوشی بدون خطای آشکار دربارهٔ مجوزها شکست بخورد.
پیاده‌سازی دروازه در فضای کاربر می‌تواند مدل دسترسی کاملاً متفاوتی داشته باشد، پس این ادعای رایج که هر سرور VPN روی اندروید به روت نیاز دارد بیش از حد گسترده است. روت به شما توان تلاش برای عملیات بیشتر می‌دهد، نه تضمین اینکه مجاز باشند یا نتیجه دسترس‌پذیر باشد.
ثبت سرویس VPN خود اندروید هم سازوکار جداگانهٔ دیگری است. به اپ یک واسط مشتری مدیریت‌شده با چرخهٔ عمر مشخص می‌دهد؛ نصب‌کنندهٔ عمومی سرور نیست، و اجرای یک دیمن از ترمینال به آن مدیریت همیشه‌روشن، سیاست به‌ازای هر اپ یا مسیر بازیابی اختصاصی نمی‌دهد.
اگر نقطهٔ خروج می‌خواهید، معماری را عوض کنید
وقتی هدف صرفاً خروج اینترنت از راه دور از طریق گوشی است و نه سازگاری با پروفایل موجود OpenVPN، گرهٔ خروج پشتیبانی‌شده در شبکهٔ پوششی طراحی مناسب‌تری است. Tailscale نقش گرهٔ خروج اندروید را با گام‌های ثبت، مجوزدهی و انتخاب مشتری خود مستند می‌کند.
این معاوضه واقعی است و ارزش دارد صریح گفته شود: پروتکل متفاوت، مدل اعتماد متفاوت و وابستگی به آن حساب و سرویس هماهنگی را می‌پذیرید. این کار مشتری OpenVPN بدون تغییر را به شبکهٔ پوششی وارد نمی‌کند و شنوندهٔ OpenVPN روی نشانی عمومی به شما نمی‌دهد.
آنچه استقرار هنوز نیاز دارد
هر مسیری را که انتخاب کنید، مبانی عملیاتی تعیین می‌کند آیا یک هفته دوام می‌آورد. اعتبارنامهٔ سرور را خصوصی نگه دارید، هویت‌های مشتری متمایز صادر کنید و پیش از نیاز، ابطال را برنامه‌ریزی کنید. تصمیم بگیرید به‌روزرسانی‌ها چگونه می‌رسند، چه چیزی سرویس را در پس‌زمینه فعال نگه می‌دارد و پس از راه‌اندازی مجدد یا تغییر شبکه چگونه بازیابی می‌شود.
از میان‌برهای راحتی که آسان به نظر می‌رسند پرهیز کنید: باینری استاتیک منسوخ، نام‌های واسط سخت‌کدشده و اسکریپت شروعی که سیاست فایروال موجود را پاک می‌کند. سپس نتیجه را فقط با یک آزمون مشخص بپذیرید: مشتری از راه دور مجاز به منبع موردنظر می‌رسد، مقصدهای ممنوعه در دسترس نمی‌مانند، و دستگاه پس از رویداد پشتیبانی‌شدهٔ چرخهٔ عمر خودبه‌خود برمی‌گردد. دسترسی روت یکی از اجزای ممکن در این نتیجه است و به‌ندرت جزء تعیین‌کننده.