Перевірка підозрілої проблеми з MTU у VPN без угадування значень

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

Зафіксуйте шлях, перш ніж змінити число

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

Почніть із найвужчої перевірки, яку вам дозволено виконати. Зміна на боці сервера зачіпає кожного користувача цієї кінцевої точки, тому вона належить до кінця розслідування, а не до початку.

Перевіряйте розміром, який ви контролюєте

У Linux перевірка виглядає як ping -M do -s 1400 host, а у Windows — як ping -f -l 1400 host. В обох випадках ви задаєте корисне навантаження, а не розмір пакета, бо заголовки IP і ICMP додаються зверху.

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

Невдала перевірка не доводить межу MTU

Відкинута перевірка може означати фільтрацію ICMP, а не межу розміру, і ця помилка змушує людей підлаштовувати значення, яке ніколи не було проблемою. Порівняйте перевірку з реальним застосунком, а також із повідомленням про помилку, пов'язаним із розміром, або з обмеженим перехопленням, перш ніж щось змінювати. Успішні маленькі пінги теж нічого не доводять, бо можуть спокійно лежати нижче межі. Два незалежні спостереження — це мінімум, перш ніж конфігурація зрушить.

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

Налаштуйте один параметр, який клієнт уже підтримує

Змініть налаштування, яке клієнт документує для цього протоколу, і залиште кінцеву точку й пункт призначення недоторканими, інакше ви змінили дві речі одразу. Обмеження MSS для TCP не покриває будь-яке навантаження UDP, тому браузер, який почав працювати, може залишити протокол тунелю точно таким самим зламаним. IPv4 і IPv6 тут окремі шляхи, бо заголовки різняться ще до того, як це зробить будь-яка маршрутизація.

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

Скасувати, перевірити й записати

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

Зберігайте цей запис разом із запитом на зміну, перш ніж хтось розширить зміну. Механізм виявлення MTU шляху у RFC 1191 пояснює, чому менше значення може врятувати один шлях і нічого не зробити для іншого, і список чисел не замінює цю модель. Перевірка завершена, коли ви можете назвати шлях, розмір, спостереження й значення, яке ви відновили.