Премногу голем 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 на тунелот може да скрие филтрирана порака и да го отстрани симптомот, но по цена на поголем товар за секој пакет. Тоа е заобиколно решение, а не дијагноза, и треба да следи по снимањето наместо да го замени. Произволно ниската вредност исто така не крши ништо видливо, и затоа преживува со години во конфигурациите. Менувајте ја свесно, запишете ја вредноста и забележете кое мерење ја оправда.

Кога управувате со портата, проверете го правилото што ја отфрла пораката наместо да го исклучите огнениот ѕид. Едно поправено правило е потесно од исклучок во политиката и многу полесно се брани подоцна. Истата логика важи и за временските ограничувања: не секое застанување е проблем со големина, а снимањето е она што ги раздвојува двете.