قاعدهٔ تک-VPN اندروید سرور SSH میزبانی‌شده را مسدود نمی‌کند

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

قاعدهٔ تک-VPN واقعاً چه چیزی را محدود می‌کند

VpnService یک منبع تک‌جایگاهی است. وقتی برنامه‌ای تونل برقرار می‌کند، VPN دستگاه می‌شود و برنامهٔ دومی که بخواهد تونلی برقرار کند تا زمانی که اولی از میان نرود رد می‌شود. این قاعده‌ای دربارهٔ مالکیت تونل است و توضیح می‌دهد چرا دو اپلیکیشن VPN نمی‌توانند همزمان اجرا شوند.

دربارهٔ سوکت‌های شنونده چیزی نمی‌گوید. سرور SSH VpnService را صدا نمی‌زند، بسته‌ها را رهگیری نمی‌کند و برای آن جایگاه رقابت نمی‌کند. یک پورت را مقید می‌کند و اتصال‌ها را می‌پذیرد، همان کاری که اگر هیچ VPN نصب نبود انجام می‌داد. پس افسانه محدودیت ارائه‌دهندگان تونل را با محدودیت اتصال‌های شبکه اشتباه می‌گیرد و این دو هیچ رابطه‌ای با هم ندارند.

شنونده یک مقصد است، نه بخشی از تونل

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

قواعد مقیدسازی پیکربندی معمولی SSH هستند: نشانی و پورت شنود، و اینکه چه کسی می‌تواند احراز هویت کند. در اندروید این تنظیمات در پیکربندی خود برنامه قرار دارند و ممکن است مالک فرایند برنامه اجازهٔ استفاده از پورت‌های ممتاز را نداشته باشد، بنابراین عادت دسکتاپی مقید کردن پورت 22 به‌عنوان root بدون تغییر منتقل نمی‌شود.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

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

مسیر پاسخ جایی است که معمولاً می‌شکند

فرض کنید همتا به نشانی تونل گوشی می‌رسد و SYN می‌آید. حالا پاسخ باید از همان مسیر خارج شود و این یک تصمیم مسیریابی درون گوشی است. اگر پاسخ به این دلیل که شبکهٔ پیش‌فرض است از Wi-Fi خارج شود، همتا اتصالی را می‌بیند که هرگز کامل نمی‌شود، که دقیقاً شبیه فایروال است.

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

یک برنامه همچنین می‌تواند سوکت‌های خودش را به شبکهٔ مشخصی مقید کند، که پیش‌فرض را نادیده می‌گیرد. وقتی گزارشی می‌خوانید که سرویسی از یک نشانی قابل دسترسی است و از نشانی دیگر نه، معمولاً همین سازوکار پشت آن است.

دور زدن VPN یک سرویس ورودی را تعمیر نمی‌کند

راه‌حل محبوب، کنار گذاشتن برنامهٔ SSH از VPN تا ترافیکش دیگر تغییر مسیر نیابد، درمانی برای مشکل عکس است. زمانی کمک می‌کند که انتقال یک اپلیکیشن SSH خروجی به‌خاطر تونل پیوسته می‌شکند. برای یک سرور میزبانی‌شده می‌تواند پاسخ‌ها را از تونلی که همتا استفاده می‌کند بیرون ببرد، که یک شکست جزئی را به شکستی کامل تبدیل می‌کند.

همین دربارهٔ باز کردن یک پورت عمومی روی روتر صدق می‌کند. اگر الزام این است که یک دستگاه مجاز از طریق VPN به گوشی برسد، در معرض گذاشتن SSH در اینترنت مدل تهدید دیگری است و تعمیر نیست.

اول نشانی سرویس را تعیین کنید: نشانی LAN گوشی، نشانی تونلش، یا نقطهٔ پایانی‌ای که عامدانه فوروارد شده است. هر یک قرارداد دسترسی‌پذیری و در معرض بودن خودش را دارد و مخلوط کردن آن‌ها راهی است که یک مشکل دسترسی کوچک به یک حفرهٔ دائمی تبدیل شود.

هر بار یک جهت را تشخیص دهید

پیش از تغییر پیکربندی چهار واقعیت را بنویسید: نشانی‌ای که همتا به آن متصل می‌شود، وضعیت شنونده روی گوشی، بستر برنامه و کاربری که آن را دارد، و مسیری که در هر جهت مشاهده می‌شود. گزارشی که می‌گوید VPN اتصال SSH را قطع می‌کند هیچ‌یک از این‌ها را ندارد و نمی‌تواند مشکل انتقال برنامه را از سرور دسترسی‌ناپذیر تشخیص دهد.

adb shell ip -br addr
adb shell ip route get 10.90.0.9
nc -vz 10.90.0.4 2222

بررسی پورت را از همتا اجرا کنید، نه از گوشی، و خروجی مشروح برنامهٔ SSH را بخوانید تا ببینید پیش از دست‌دهی TCP شکست می‌خورد یا پس از آن. سوکتی که هرگز متصل نمی‌شود و ورودی که رد می‌شود دو مرحلهٔ متفاوت با دو مسئول متفاوت هستند.

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