Завеликий пакет IPv6: чому великі передачі через VPN завмирають

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

Малі запити, великі зупинки

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

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

Packet Too Big — це зворотний зв'язок, а не трафік

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

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

Перевіряйте обидві родини адрес окремо

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

ping -6 -M do -s 1400 host.internal
ip -6 route get 2001:db8:2::10
sudo tcpdump -ni any 'icmp6 and ip6[40] == 2'

Зонд надсилає пакет із встановленим бітом do-not-fragment і повідомляє розмір, на якому він зазнає невдачі, — це число, яке тунель має вмістити. Запит маршруту називає інтерфейс, який поніс би адресата, тож ви знаєте, який MTU каналу діє. Захоплення фільтрує ICMPv6 типу 2, повідомлення Packet Too Big, і показує, чи доходить воно взагалі до цього вузла. Якщо повідомлення з'являється в захопленні, а передача все ще висить, відправник його ігнорує, що переносить розслідування в стек, а не в мережу.

Змінюйте розмір тунелю лише після доказів

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

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