Страницы загружаются, но загрузки на VPN замирают: какая причина побеждает
Замирание, зависящее от размера, соответствует неисправности MTU пути, а также DNS, ограничению приложения или нестабильному туннелю. Четыре наблюдения решают, какая именно.
Страницы загружаются, VPN сообщает о подключении, а загрузка файла каждый раз замирает в одном и том же месте. Этому описанию соответствуют четыре объяснения: проблема размера пакета, проблема разрешения имён, ограничение приложения и туннель, который постоянно перезапускается. Каждое из них можно подтвердить или исключить другим наблюдением, поэтому решение — это выбор правильной проверки, а не догадка о причине.
Четыре кандидата и одна форма
Начните с формы сбоя, потому что она отсекает большую часть списка ещё до того, как открыт любой инструмент. Замирание при постоянном размере — это проблема размера, пока не доказано обратное. Замирание в случайных местах — это проблема потерь или стабильности. Сбой до открытия соединения — это проблема имён.
Четвёртый кандидат — само приложение. Ограничения загрузки, тайм-ауты запросов и пределы размера тела у прокси создают сбои, которые из браузера выглядят как сетевые неполадки, и обычно приходят как отказ, а не как зависание.
Запишите наблюдаемую форму до любых проверок. «Останавливается примерно на одном и том же числе байт, каждый раз, при поднятом туннеле» — гораздо более сильная отправная точка, чем «загрузки не работают».
Затем держите путь неизменным во время проверок. Одновременное изменение выхода, протокола и сервера даёт результат, который нельзя отнести ни к одному из них. Одна переменная за запуск, и запишите её.
Разделите размер пополам, прежде чем трогать политику
Самый дешёвый различитель — это проба, меняющая одно число. Отправьте на адресат пинги возрастающего размера с запретом фрагментации, загрузите контролируемый вами файл в тот же сервис и сравните, где останавливается каждый.
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadПервая команда сообщает, проходит ли пакет полного размера по пути вообще. При MTU 1500 байт наибольшая не фрагментируемая полезная нагрузка ICMP — 1472 байта, а туннель забирает ещё больше из этого бюджета до начала внутреннего пакета. Вторая даёт размер и длительность для передачи на уровне приложения, и это то число, которое действительно важно.
| Candidate | Observation that confirms it | Observation that rules it out |
|---|---|---|
| Path MTU or blocked ICMP feedback | Stall at a consistent size; large do-not-fragment probes fail | Small and large transfers both complete |
| Name resolution | The connection never opens for that name | The connection opens and then stalls mid-transfer |
| Application or proxy limit | A clean rejection at a documented size | No log entry on the server at all |
| Tunnel instability | Reconnects or rekeying during the transfer | The tunnel uptime is unchanged across the failure |
Читайте пару вместе. Пробы, которые срываются выше порога, и загрузка, которая останавливается около того же порога, — это связная история. Пробы, которые все проходят, а загрузка замирает на числе байт, которое путь явно несёт, указывают на приложение или сервер, и никакая работа с MTU это не изменит. Такой отрицательный результат ценен не меньше положительного. Он убирает самую дорогую ветвь расследования.
Затем проверьте стабильность во время передачи, потому что туннель, обновляющий ключ посреди большой загрузки, создаёт сбой, который выглядит зависимым от размера, не будучи таким. Показатель времени работы — самый дешёвый способ это подтвердить.
Выберите между исправлением и обходным решением
Если доказательства указывают на размер, есть два честных ответа и один нечестный. Честные — восстановить обнаружение MTU пути, разрешив необходимую обратную связь ICMP, или ограничить объявляемый размер сегмента, чтобы партнёры отправляли меньшие сегменты. Нечестный — понизить MTU интерфейса до значения, скопированного с форума, и ни разу не проверить, что оно изменило.
Выбор зависит от того, что вы контролируете. В сети, которой вы управляете, разрешение сообщений ICMP — более чистое исправление, потому что механизм продолжает работать для каждого протокола. На пути, который вы не контролируете, ограничение — практический вариант, и применять его следует узко, а не на всём сервере.
Если доказательства указывают на приложение, исправьте приложение или его конфигурацию прокси. Ответ 413 и зависшее соединение — разные сбои, и второй обычно является тайм-аутом где-то в цепочке, включающей прокси со своими пределами.
В любом случае сохраните исходные значения и повторите проверку после отката. Изменение, совпавшее с успешной передачей, не доказывает, что оно её вызвало, а возможность отменить — это то, что отделяет диагноз от совпадения.
Запишите решение, чтобы оно пережило следующий инцидент
Достаточно четырёх фактов: наблюдаемая форма сбоя, результаты проб, сделанное изменение и результат повторной проверки. С ними следующий человек сможет сказать, та же это проблема или новая с тем же симптомом.
Отметьте и контекст пути, потому что вывод об MTU относится к конкретному каналу. Ноутбук, который работает дома и срывается в отеле, имеет два пути, и исправление, применённое к одному из них, ничего не говорит о другом.
Наконец, сопротивляйтесь выводу «VPN сломал загрузки». Туннель присутствовал и в рабочем, и в сбойном случае; изменился размер пакета, который путь должен был нести, или место, где передача была остановлена. Именно называние реального механизма делает заметку полезной.