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 пути существует, чтобы конечные точки узнали реальный предел вместо догадок. Блокировка обратной связи и жёсткое задание малого размера обменивают работающую большую передачу на постоянные скрытые издержки при каждом соединении.
Что спросить у команды шлюза
Попросите три вещи: точное имя атрибута и его область действия, соблюдают ли его развёрнутые клиенты и какой транспорт согласовал сеанс. Изменение, применённое к одной групповой политике, проверяемо; глобальная правка — нет, и она переносит риск на пользователей, которые никогда не сообщали о проблеме. Попросите также ссылку на документ, потому что имена атрибутов меняются между версиями.
Затем измените одну вещь и повторно проверьте исходную неудачную операцию, а не загрузку из теста скорости. Храните запись до и после вместе с версией клиента и сетью доступа, чтобы следующий отчёт можно было сравнить, а не обсуждать заново.
Если операция по-прежнему не проходит при исходном размере, размер не был причиной. Запишите и этот вывод, чтобы следующий человек не открывал ту же гипотезу снова.