Загрузка через VPN медленнее скачивания? Определите, в какой предел вы упираетесь

Большинство линий доступа асимметричны, поэтому туннель обычно загружает медленнее, чем скачивает, и это ожидаемый ответ, а не неисправность. Интересный вопрос: ограничена ли ваша загрузка линией, чем-то ещё, что уже её использует, или потоком, который зависает вместо ровной работы. Эти три дают одну и ту же жалобу и требуют разной работы.

Три предела, которые из строки прогресса выглядят одинаково

Пропускная способность — первый, и это свойство продукта доступа, а не туннеля. Исходящий канал в несколько мегабит нормален для домашнего оптического интернета и многих мобильных тарифов, а накладные расходы шифрования малы по сравнению с этим разрывом. Инкапсуляция тоже добавляет байты к каждому пакету, что снижает полезную пропускную способность в обе стороны, а не только в одну, поэтому сама по себе она не может объяснить большую асимметрию.

Конкуренция — второй. Облачная синхронизация, фото библиотеки и агенты обновлений загружают, пока машина кажется бездействующей, и второе устройство на той же линии делает то же самое. Очередь — третий: насыщенный исходящий канал вытесняет интерактивный трафик за объёмными данными, поэтому звонки прерываются, хотя сама передача сообщает о здоровом прогрессе.

Измеряйте одно направление за раз

Используйте одно и то же устройство, один и тот же профиль и один и тот же пункт назначения и никогда не запускайте оба направления одновременно, если только конкуренция не то, что вы хотите наблюдать. Приостановите собственные необязательные передачи перед первым запуском. Два запуска с одним флагом между ними решают большую часть.

iperf3 по умолчанию отправляет от клиента, поэтому обычный запуск измеряет ваш исходящий путь; -R меняет направление и измеряет скачивание. Запустите их с интервалом в несколько минут и запишите оба числа вместо усреднения:

iperf3 -c speed.example.net -t 30 -P 4
iperf3 -c speed.example.net -t 30 -P 4 -R

Если число загрузки — небольшая доля числа скачивания и остаётся стабильным от запуска к запуску, форма соответствует асимметричной линии доступа и туннель здесь ни при чём. Если загрузка колеблется между запусками или обваливается через десять секунд, читайте дальше.

Решайте по тому, где меняется загрузка

Меняйте по одной переменной за раз и смотрите, какое направление движется. Второй узел VPN, который загружает лучше, указывает на этот узел или маршрут к нему. Та же медленная загрузка со второго устройства на той же линии указывает на линию. Другое устройство на другой линии, которое тоже медленное, указывает на политику входа пункта назначения, и её нельзя исправить локально.

Записывайте байты в секунду и прошедшее время для одной и той же нагрузки, а не одну оценку скорости. Клиент резервного копирования и тест скорости используют разные пункты назначения и разную параллельность, поэтому сравнение их чисел ничего не отвечает. Если небольшие запросы в порядке и ползут только крупные передачи, предел, вероятно, вовсе не пропускная способность.

Для повседневного использования ограничение фоновой загрузки или её планирование вне часов совещаний часто помогает больше, чем любая настройка туннеля. Оценивайте это изменение по совокупной нагрузке: резервная копия, которая завершается позже, но больше не портит звонки, обычно лучший обмен.

Когда зависание побеждает медленность

Передача, которая замирает в повторяющейся точке, а затем продолжается, ведёт себя как проблема MTU пути, а не как ограничение скорости. Туннель уменьшает полезную нагрузку на пакет, а устройство, отбрасывающее получившееся сообщение ICMP, оставляет отправителя гадать. Этот шаблон заслуживает отдельного теста, потому что исправление отличается от настройки скорости. Стабильно низкое число указывает на пропускную способность, а всплеск, за которым следует тишина, — на нагрузку, которую путь не может пронести.

Проверьте путь нагрузкой, которая не должна фрагментироваться, затем сравните MTU интерфейса туннеля со значением, которое проходит:

ping -M do -s 1400 -c 3 203.0.113.10
ip link show dev tun0 | grep -o "mtu [0-9]*"

Если большой зонд исчезает, а меньший проходит, зажмите TCP MSS на туннеле вместо снижения MTU интерфейса для каждого протокола. Устойчивые зависания после этой точки относятся к хранилищу или темпу принимающего приложения, а не к сетевому пути.

Что менять, а что оставить

Меняйте то, что вы контролируете: расписания фоновых передач, выбор узла и MSS для зависающего пути. Держите каждое изменение обратимым и ограниченным одной нагрузкой. Оставьте в покое то, что измерение называет исправным, включая скорость скачивания, которая уже соответствует линии.

Запишите числа до и после вместе с профилем, узлом и временем суток, потому что проблема загрузки, которая перемещается вместе с узлом, — это вопрос маршрутизации, а та, что перемещается вместе с устройством, локальна. Именно эта запись превращает расплывчатую жалобу в решение, и она стоит двух запусков одной и той же команды.