MTU در VPN آیفون: پیش از تغییر یک عدد، مالک را مشخص کنید
سه پرسش تعیین می‌کند که اپلیکیشن، پروفایل دروازه یا هیچ‌کس روی گوشی می‌تواند اندازه را تغییر دهد. پیش از قرض گرفتن یک عدد از Mac به آن‌ها پاسخ دهید.
هر بحثی درباره اندازه بسته‌های VPN در آیفون سرانجام همان فرمان Mac را در برابر رابطی به نام ppp0 پیشنهاد می‌کند، معمولاً با عددی در کنارش. این فرمان منتقل نمی‌شود و حتی روی Mac هم کنترل درست نبود، مگر اینکه آن رابط به همان اتصال مربوط باشد. روی گوشی، عدد متعلق به کسی است که تونل را پیاده‌سازی می‌کند: سیستم‌عامل برای پروفایل داخلی، ارائه‌دهنده تونل بسته برای یک اپلیکیشن، یا دروازه وقتی یک ویژگی مستند مذاکره می‌شود. سه پرسش روشن می‌کند با کدام‌یک از این حالت‌ها روبه‌رو هستید.
پرسش یکم: کدام کلاینت در حال اجراست
پروفایل داخلی IKEv2، پروفایل داخلی Cisco IPsec و کلاینت Cisco شخص ثالث سه پیاده‌سازی متفاوت با سه مجموعه متفاوت از ویژگی‌های پشتیبانی‌شده هستند. نوع پروفایل در تنظیمات می‌گوید کدام‌یک را گوشی واقعاً اجرا کرده و فهرست اپلیکیشن‌ها می‌گوید اصلاً ارائه‌دهنده‌ای در مسیر هست یا نه. از همان‌جا شروع کنید، چون بقیه تصمیم از آن نتیجه می‌شود. اگر هیچ ارائه‌دهنده‌ای در فهرست اپلیکیشن‌ها پیدا نشود، تونل از آنِ سیستم‌عامل است.
پیاده‌سازی را از فروشنده دروازه استنتاج نکنید. یک سرور مرکزی Cisco می‌تواند اتصال کلاینت‌هایی را پایان دهد که چیزی جز نام فروشنده مشترک ندارند. تصویر یک نسخه قدیمی روی انتشار قدیمی می‌گوید آن جفت چه چیزی را پشتیبانی می‌کرد، نه اینکه گوشی در دست شما چه می‌کند.
پرسش دوم: چه کسی مالک مقدار است
Apple ویژگی MTU را از طریق شیء تنظیمات افزونه شبکه در اختیار توسعه‌دهندگان تونل بسته می‌گذارد. این یک API برای ارائه‌دهنده‌ای است که تونل خودش را پیکربندی می‌کند، نه کلیدی که کاربر یا مدیر بتواند روی کلاینت نصب‌شده دیگری بزند. یک اپلیکیشن شخص ثالث می‌تواند آن را آشکار کند، نادیده بگیرد یا مقداری را سخت‌کد کند.
برای پروفایل داخلی، سیستم‌عامل اندازه رابط را انتخاب می‌کند و گوشی هیچ ویرایشگری برای آن ارائه نمی‌دهد. برای دروازه دسترسی از راه دور Cisco یک ویژگی مستند برای پروفایل اتصال وجود دارد و اعمال آن به کلاینت، انتشار و انتقال مذاکره‌شده بستگی دارد. همان شکاف میان مستند و رعایت‌شده جایی است که عدد کپی‌شده خراب می‌شود.
| Owner | Who can change it | Reachable from the phone |
|---|---|---|
| Packet-tunnel provider | The app vendor through its API | Only if the app exposes a setting |
| Native IKEv2 or Cisco IPsec profile | The operating system | No user control |
| Gateway group policy attribute | The gateway administrator | If the client honours it |
پرسش سوم: آیا نشانه اصلاً به اندازه بستگی دارد
مشکل‌های اندازه یک امضای مشخص دارند: درخواست‌های کوچک موفق می‌شوند، بارگذاری‌های بزرگ یا پاسخ‌های بزرگ معلق می‌مانند و همان سرویس روی شبکه دسترسی دیگری کار می‌کند. فیلتر کردن، محدودیت بار مفید اپلیکیشن و سرور متوقف‌شده می‌توانند شکایت مشابهی بسازند، پس عملیاتی را که شکست می‌خورد در کنار یکی که کار می‌کند ثبت کنید. اگر اپلیکیشن گزارش می‌دهد، هر دو را با زمان و اندازه بنویسید. بدون این جفت، هر تغییر بعدی حدس است.
همان آزمون را روی Wi-Fi و شبکه همراه اجرا کنید. خطایی که شبکه را دنبال می‌کند به مسیر اشاره دارد؛ خطایی که دستگاه را دنبال می‌کند به کلاینت یا پروفایل، و این دو به مالکان متفاوتی نیاز دارند. برای هر دو اجرا از همان سرویس و همان حساب استفاده کنید، وگرنه مقایسه چیزی به شما نمی‌گوید.
چرا دستور Mac مدام برمی‌گردد
سال‌ها VPN رومیزی مبتنی بر PPP تغییر اندازه رابط را به یک راه‌حل محلی مشروع تبدیل کرد و آن دستورها به بحث‌های موبایل کپی شد. روی گوشی نه پوسته‌ای هست، نه چنین نام رابطی و نه تداومی پس از اتصال دوباره. دستوری که در سال 2011 مشکلی رومیزی را حل کرد، بسیار دورتر از شرایطی که آن را درست می‌کرد سفر کرد. کلاینت‌های موبایل هیچ فرمان پوسته‌ای برای این کار نمی‌پذیرند، هرچه بحث ادعا کند.
مقدار کپی‌شده را فرضیه‌ای درباره مسیر بدانید، نه تنظیم. اگر اندازه کوچک‌تر انتقالی را به کار بیندازد و اندازه بزرگ‌تر به‌طور قابل‌اعتماد شکست بخورد، درباره مسیر شواهدی دارید؛ هنوز باید مؤلفه‌ای را پیدا کنید که اجازه دارد بر آن اثر بگذارد. آن جست‌وجو معمولاً به پروفایل دروازه یا فروشنده اپلیکیشن می‌رسد و به‌ندرت به گوشی.
انتقال پاسخ را تغییر می‌دهد
اگر نشست به‌جای IPsec روی TLS اجرا شود، تنظیم تقسیم‌بندی TCP روی دروازه می‌تواند کمک کند، چون اندازه قطعه اعلام‌شده برای جریان‌های TCP را بازنویسی می‌کند. برای ترافیک UDP کاری نمی‌کند و آن سهم بیشتری از وب مدرن را در بر می‌گیرد از آنچه مردم انتظار دارند. پیش از پیشنهاد تغییر، انتقال مذاکره‌شده را بررسی کنید و در تیکت بنویسید انتظار دارید کدام انتقال اثر بپذیرد.
کشف MTU مسیر وجود دارد تا دو سر مسیر حد واقعی را بیاموزند نه اینکه حدس بزنند. مسدود کردن بازخورد و سخت‌کد کردن اندازه کوچک، یک انتقال بزرگ کارآمد را با هزینه‌ای دائمی و پنهان در هر اتصال معاوضه می‌کند.
از تیم دروازه چه بپرسیم
سه چیز بخواهید: نام دقیق ویژگی و دامنه آن، اینکه کلاینت‌های مستقر آن را رعایت می‌کنند یا نه، و اینکه نشست روی کدام انتقال مذاکره کرده است. تغییری که روی یک سیاست گروهی اعمال شود قابل آزمون است؛ ویرایش سراسری نیست و ریسک را به کاربرانی منتقل می‌کند که هرگز مشکلی گزارش نکرده‌اند. ارجاع سند را هم بخواهید، چون نام ویژگی‌ها میان انتشارها جابه‌جا می‌شود.
سپس یک چیز را تغییر دهید و همان عملیات اولیه شکست‌خورده را دوباره بیازمایید، نه یک دانلود آزمون سرعت. سابقه پیش و پس را همراه با نسخه کلاینت و شبکه دسترسی نگه دارید تا گزارش بعدی قابل مقایسه باشد نه اینکه دوباره بحث شود.
اگر عملیات در اندازه اولیه هنوز شکست می‌خورد، اندازه علت نبود. آن نتیجه را هم ثبت کنید تا نفر بعد همان فرضیه را دوباره باز نکند.