MTU у VPN на iPhone: спершу визначте власника, потім змінюйте число
Три питання вирішують, чи може застосунок, профіль шлюзу або ніхто на телефоні змінити розмір. Дайте на них відповідь, перш ніж позичати число з Mac.
Кожне обговорення розміру пакетів VPN на iPhone зрештою пропонує ту саму команду 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 року, пройшов значно далі за умови, які робили його правильним. Мобільні клієнти не приймають для цього жодної команди оболонки, що б не стверджувало обговорення.
Ставтеся до скопійованого значення як до гіпотези про шлях, а не як до налаштування. Якщо менший розмір змушує передачу працювати, а більший надійно не проходить, у вас є докази про шлях; усе ще треба знайти компонент, якому дозволено на нього впливати. Цей пошук зазвичай закінчується на профілі шлюзу або в постачальника застосунку, і рідко на телефоні.
Транспорт змінює відповідь
Якщо сеанс іде через TLS, а не IPsec, налаштування сегментації TCP на шлюзі може допомогти, бо переписує оголошений розмір сегмента для потоків TCP. Для трафіку UDP воно нічого не робить, а він охоплює більшу частину сучасного вебу, ніж люди очікують. Перевірте узгоджений транспорт, перш ніж пропонувати зміну, і вкажіть у заявці, на який транспорт ви очікуєте впливу.
Виявлення MTU шляху існує, щоб кінцеві точки дізналися справжню межу замість здогадів. Блокування зворотного зв'язку та жорстке задання малого розміру обмінюють робочу велику передачу на постійні приховані витрати на кожному з'єднанні.
Що запитати в команди шлюзу
Попросіть три речі: точну назву атрибута та його межі, чи дотримуються його розгорнуті клієнти та який транспорт узгодив сеанс. Зміна, застосована до однієї групової політики, піддається перевірці; глобальне редагування — ні, і воно переносить ризик на користувачів, які ніколи не повідомляли про проблему. Попросіть також посилання на документ, бо назви атрибутів змінюються між випусками.
Далі змініть одну річ і повторно перевірте початкову невдалу операцію, а не завантаження з тесту швидкості. Зберігайте запис до і після разом із версією клієнта та мережею доступу, щоб наступний звіт можна було порівняти, а не обговорювати заново.
Якщо операція все ще не проходить за початкового розміру, розмір не був причиною. Запишіть і цей висновок, щоб наступна людина не відкривала ту саму гіпотезу знову.