Пінг через VPN працює, а сайт зависає: перевірте розмір

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

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

Відповідь відлуння відповідає на значно менше питання

Відповідь відлуння каже, що IP-стек призначення відповів на запит ICMP з вашого джерела. Вона нічого не каже про те, чи є TCP-слухач на потрібному вам порту, чи дозволяє політика цей порт або чи фільтрує хост призначення трафік незалежно від шлюзу. Шлюз, що дозволяє одну службу, може відкинути іншу, хоча обидві цілі відповідають на ping. Читайте відповідь як один факт про один пакет і один напрямок.

Підтвердьте призначення та порт служби, перш ніж тлумачити будь-що інше. Адреса, яку ви перевіряли, і адреса, яку використовує застосунок, іноді є різними записами, а ім'я, що розв'язується у дві адреси, робить це ймовірним.

З'ясуйте, чи почалося з'єднання

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

curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'

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

Виміряйте розмір зазначеним числом

Коли застрягання з'являється під навантаженням, перевірте один розмір пакета з уставленим бітом заборони фрагментації і зазначте арифметику, щоб результат щось означав. У Linux з iputils корисне навантаження 1392 байти плюс заголовок ICMP 8 байтів і заголовок IPv4 20 байтів дають внутрішній пакет рівно 1420 байтів. Зазначте цю арифметику в заявці, бо голий ping, що доходить до шлюзу, нічого не доводить про застосунок.

ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10

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

Врахуйте зовнішній шлях

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

Виявлення MTU шляху в IPv4 залежить від зворотного зв'язку про пакети, які не можна передати без фрагментації, а IPv6 використовує повідомлення Packet Too Big. Специфікація IPv4 описує цей механізм. Фільтрування зворотного зв'язку ламає здатність відправника вчитися і залишає його повторно надсилати пакети, які ніколи не вмістяться. Тому робочий малий запит і невдалий великий так затишно співіснують.

Змініть одне число і перевірте застосунок знову

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

Тримайте арифметику в записі про зміну: виміряний розмір, припущені накладні витрати і задане значення. Будь-хто, хто переглядатиме це пізніше, зможе перевірити припущення замість того, щоб виводити його заново зі знімка екрана ping.

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