Завантаження через 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 для шляху, що застрягає. Тримайте кожну зміну оборотною і обмеженою одним навантаженням. Залиште в спокої те, що вимірювання називає справним, включно зі швидкістю скачування, яка вже відповідає лінії.

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