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