توربین تقسیم‌شده برای کلاینت‌های هات‌اسپات مستثنی‌کردن هر برنامه نیست
مستثنی کردن یک برنامه از VPN فقط تلفن را تغییر می‌دهد. لپ‌تاپ متصل به قاعده ارسال خودش نیاز دارد که بر پایه مبدأ، مقصد و NAT تطبیق داده می‌شود.
دو خواسته که هم‌ارز به نظر می‌رسند هم‌ارز نیستند: «این برنامه را از VPN مستثنی کن» و «این یک مقصد را برای لپ‌تاپ روی هات‌اسپات من بیرون از VPN بفرست». اولی تغییر می‌دهد که یک سوکت روی تلفن چگونه شبکه‌ای را انتخاب می‌کند. دومی باید تصمیم ارسال را برای بسته‌ای تغییر دهد که پس از پذیرش آن توسط تلفن از دستگاه دیگری رسیده است. اشتباه گرفتن این دو همان چیزی است که باعث می‌شود کلاینت هات‌اسپات با استثنایی بماند که همیشه فقط برای مرورگر خود تلفن اعمال می‌شد.
دو زیرسیستم صاحب دو پرسش‌اند
اندروید شبکه‌بندی برنامه‌ها و اشتراک‌گذاری اتصال را جدا نگه می‌دارد. سوکت‌های برنامه توسط پشته اتصال به یک شبکه اختصاص می‌یابند و برنامه VPN تصمیم می‌گیرد کدام یک از سوکت‌های خودش وارد تونل شوند. بسته‌های ارسال‌شده از کلاینت متصل را زیرسیستم اشتراک‌گذاری اتصال مدیریت می‌کند که از netd مسیرها، قواعد سیاست و ترجمه روی رابط پایین‌دست را می‌خواهد.
استثنای هر برنامه زمانی ارزیابی می‌شود که برنامه‌ای سوکتی باز کند. بسته ارسال‌شده هرگز به این بررسی نمی‌رسد، چون از سوکت برنامه‌ای روی این دستگاه نشأت نگرفته است. این تمام دلیل ناتوانی این دو تنظیم در جایگزینی یکدیگر است و نقصی در هیچ‌کدام نیست.
استثنای هر برنامه در واقع چه چیزی را تغییر می‌دهد
سازنده VpnService می‌تواند بسته‌هایی را که بیرون از تونل می‌مانند با addDisallowedApplication نام ببرد، یا تنها بسته‌های مجاز درون را با addAllowedApplication نام ببرد. آن برنامه‌ها سپس سوکت‌هایی روی شبکه زیرین باز می‌کنند، در حالی که VPN همچنان مالک مسیر پیش‌فرض برای همه چیز دیگر است.
دامنه دقیق است: سوکت‌های خود بسته، روی این دستگاه، تا زمانی که تونل بالاست. درباره ترافیک ارسال‌شده چیزی نمی‌گوید، نه درباره دستگاه دوم و نه درباره بسته‌هایی که سیستم به نمایندگی از اشتراک‌گذاری اتصال می‌فرستد.
کنترل مقصد هم نیست. مستثنی کردن یک مرورگر هر نشانی را که آن مرورگر به آن می‌رسد مستثنی می‌کند، از جمله نشانی‌ای که می‌خواستید درون تونل بماند. وقتی خواسته به‌جای یک برنامه یک مقصد را نام می‌برد، انتخاب‌گر برنامه از نظر ساختار ابزار اشتباهی است.
بسته اشتراک‌گذاری‌شده از دید تلفن چگونه است
بسته کلاینت با نشانی مبدأ خصوصی که تلفن اختصاص داده است، مثلاً 192.168.43.20، و مقصدی عمومی به رابط هات‌اسپات می‌رسد. برای ارسال آن، تلفن به مسیری به سوی پیوند بالادست و قاعده‌ای برای ترجمه نیاز دارد تا پاسخ‌ها راه بازگشت را پیدا کنند، زیرا نشانی خصوصی کلاینت روی شبکه سلولی بی‌معناست.
اندروید این را با قواعد سیاستی بیان می‌کند که یک جدول مسیریابی را انتخاب می‌کنند و netd جدول‌ها و قواعد مربوط را هنگامی که شبکه‌ها و VPNها تغییر می‌کنند بازمی‌سازد. شماره جدول، اولویت قاعده یا نام رابطی که از یک پست انجمن یا از همان مدل در نسخه‌ای قدیمی‌تر کپی شده باشد، مالکیت پایدار ایجاد نمی‌کند. همین بازسازی دلیل آن است که یک قاعده دست‌نویس ممکن است یک ساعت کار کند و پس از اتصال دوباره بعدی از کار بیفتد.
سیاستی که یک استثنای هات‌اسپات واقعاً نیاز دارد
پیش از دست زدن به هر قاعده، تصمیم را به صورت مبدأ، مقصد و مسیر موردنظر بنویسید. کمینه شکل برای یک مقصد تأییدشده چنین است:
| Source | Destination | Intended path |
|---|---|---|
| One authorized hotspot client | One approved public service address | Ordinary cellular uplink |
| The same client | All other covered destinations | Shared VPN |
| The phone's own apps | Their existing destinations | Unchanged phone policy |
هر دو جهت باید کامل باشند. شاخه مستقیم به مسیری قابل استفاده از پیوند بالادست سلولی نیاز دارد که فعلاً جاری است؛ شاخه VPN به مسیر تونل به‌همراه اجازه ارسال نیاز دارد. هر ترجمه مبدأ باید با خروجی انتخابی شما بخواند، زیرا NAT اعمال‌شده روی رابط تونل نشانی تونل را نشان می‌دهد نه نشانی سلولی را، و آنگاه مسیر بازگشت با مسیر خروج هم‌خوان نیست.
پاسخ‌ها باید از طریق وضعیت ردیابی‌شده یا مسیری صریح به همان کلاینت پایین‌دست برسند و شمارنده بسته‌های خروجی هیچ‌یک از این‌ها را اثبات نمی‌کند. ترابری بیرونی خود VPN را هم بیرون از دامنه استثنا نگه دارید، وگرنه بسته‌های حامل تونل سیاستی را به ارث می‌برند که برای درخواست وب یک کلاینت نوشته شده است.
یک نشانی ثبت‌شده مقصد نیست
یک نشانی IPv4 خوانده‌شده از مرورگر یک عکس لحظه‌ای است. سرویس‌های بزرگ از anycast یا از مجموعه‌ای چرخان از نشانی‌های لبه پاسخ می‌دهند، بسیاری دوپشته‌اند و جریان ورود می‌تواند میزبان‌های احراز هویت و تله‌متری را لمس کند که صفحه هرگز نشانشان نمی‌دهد. استثنایی که پیرامون نشانی‌ای که تصادفاً دیدید ساخته شود، دفعه بعد که سرویس بار خود را بازتوزیع کند می‌شکند.
از نشانی‌های مستند مالک سرویس یا بازه‌ای که منتشر می‌کند استفاده کنید و هر دو خانواده نشانی را در نظر بگیرید. اگر خواسته را نمی‌توان به صورت مجموعه‌ای پایدار بیان کرد، احتمالاً پرسشی سیاستی برای سرویس است نه ترفندی مسیریابی روی تلفن.
از سمت پایین‌دست بررسی کنید
سه بررسی، به این ترتیب: سرویس انتخابی از لپ‌تاپ، مقصدی معمولی که باید درون VPN بماند و برنامه‌ای روی تلفن که باید بی‌تأثیر بماند. سپس پس از اتصال دوباره و پس از تغییر پیوند بالادست تکرار کنید، زیرا جدول‌های سیاست آنگاه بازسازی می‌شوند.
اگر پیاده‌سازی اشتراک‌گذاری تلفن نتواند این قرارداد را در یک اتصال دوباره نگه دارد، سیاست گزینشی را به مسیریاب پایین‌دست پشتیبانی‌شده منتقل کنید و قواعد ریشه را روی گوشی انبار نکنید. مسیریاب می‌تواند تطبیق مبدأ و مقصد را با مالکی پایدار بیان کند و مستندات ماژول اشتراک‌گذاری اتصال مرجع درست برای کاری است که تلفن واقعاً انجام می‌دهد.