IPv4 фрагментує в дорозі; IPv6 натомість надсилає повідомлення про завеликий пакет

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

Що робить кожна родина

Таблиця — це механізм у чотирьох рядках, і один рядок пояснює більшу частину плутанини.

У IPv6 немає фрагментації в дорозі й немає прапорця DF, який треба скинути, тому нема на що спертися, коли пакет завеликий. Відправникові треба сказати, і відправник має в це повірити.

Тунель тихо звужує шлях

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

Накладні витрати ESP залежать від режиму й алгоритмів, тому правильний MTU тунелю — це розрахунок, а не звичай. Що б ви не обрали, воно має залишити місце для повного внутрішнього пакета IPv6 розміром 1280 байтів, бо кожна ланка IPv6 зобов'язана нести стільки. Тунель, який не може нести 1280 байтів IPv6, — це не проблема налаштування; це зламаний шлях для цієї родини. Саме це обмеження зникає, коли значення MTU копіюють із розгортання лише з IPv4.

Чому симптом виглядає як зависання

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

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

Не вимикайте повідомлення, від яких залежить ваш власний шлях, і потім не описуйте результат як збій IPv6. Той самий аргумент стосується повідомлень Fragmentation Needed в IPv4, які так само непопулярні в авторів брандмауерів і так само потрібні.

Виміряйте межу, потім виправте рівень

Перевіряйте, а не вгадуйте: використовуйте прапорець don't-fragment у IPv4 і фіксовані розміри корисного навантаження в IPv6 та записуйте, де відповіді припиняються. ping -M do -s 1472 і ping -6 -s 1400 достатньо, щоб визначити форму проблеми, а tracepath повідомляє виявлений MTU шляху дорогою.

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

Тестуйте ту родину, яку застосунок справді використовує, бо ім'я з подвійним стеком може відповідати в одній родині й не відповідати в іншій, а застосунок може перемкнутися після зміни мережі. Запишіть адресу, яку ви перевірили, бо результат щодо запису A нічого не каже про запис AAAA.

Ставтеся до межі розміру як до доказу

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

Запишіть у заявку виявлений MTU, налаштований MTU тунелю й тест, який довів різницю. Наступна людина зустріне ту саму арифметику на іншій ланці.