هدایت پورت در نقطه اتصال اندروید: سه نقطه ورود

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

از جایی شروع کنید که سرویس واقعاً اجرا می‌شود

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

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

در نسخه‌ای که قابل اشکال‌زدایی است، adb shell سوکت‌ها را از طریق /proc/net/tcp فهرست می‌کند، اما برای بیشتر مردم وضعیت خود برنامه منبع صادق است.

نخستین نقطه ورود: دستگاه دیگری روی نقطه اتصال

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

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

اگر سرویس روی رایانه متصل اجرا شود، نشانی نقطه اتصال گوشی به هیچ وجه مقصد نیست؛ نشانی رایانه روی رابط نقطه اتصال و یک شنونده آنجا لازم است.

دومین نقطه ورود: مسیر اپراتور

رسیدن به گوشی از شبکه موبایل مسئله دیگری است و برای IPv4 بیشتر وقت‌ها کار نمی‌کند. اپراتورها دستگاه‌ها را پشت ترجمه اشتراکی می‌گذارند و به همین دلیل RFC 6598 دقیقاً برای چنین چیدمانی یک محدوده نشانی اشتراکی کنار گذاشته است. اتصال ورودی ناخواسته هیچ نگاشتی برای رسیدن ندارد و هیچ پیکربندی محلی یکی نمی‌سازد، چون مترجم دستگاه شما نیست.

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

سومین نقطه ورود: خروجی VPN

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

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

یک مسیر را سرتاسر آزمایش کنید، سپس مالک را نام ببرید

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

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

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

• شنونده روی نشانی‌ای است که طرف مقابل می‌تواند برسد، نه روی loopback.
• طرف مقابل نشانی همان نقطه ورود را به کار می‌برد، نه نشانی خروجی یک صفحه وضعیت.
• هر نگاشتی در سمت اپراتور یا ارائه‌دهنده ویژگی پشتیبانی‌شده است، نه قاعده‌ای که محلی افزوده‌اید.
• درخواست و پاسخ از بافت شبکه یکسانی می‌گذرند و احراز هویت هنوز موفق می‌شود.