Тунел завршава руковање, мали захтеви се враћају, а први велики пренос застаје. Тај образац указује на MTU путање много пре него на пропусност. Свака веза дуж руте ограничава величину пакета, а инкапсулација троши део тог дозвољеног на спољашње заглавља, па унутрашњи пакет мора бити мањи него што би сирова путања сугерисала. Отказ је тих, и то га чини скупим за дијагностику.

Шта MTU путање заправо мери

MTU путање је најмањи MTU везе на рути између два хоста, а не MTU одштампан на вашем локалном интерфејсу. Локална вредност је тачка од које почиње процена, а путања одлучује где она мора да се заврши. Зато исти тунел може да ради на једној приступној мрежи, а да застане на другој: променила се рута, а не конфигурација. Измерити једном и претпоставити свуда је грешка која одржава овај проблем живим.

За тунел је важан број унутрашњи MTU, односно дозвола спољашње путање минус оно што инкапсулација троши. WireGuard додаје спољашње IP заглавље и UDP заглавље; други транспорти додају своја. Поставите унутрашњу величину превисоко и сваки пакет пуне величине ће захтевати фрагментацију која се можда никада неће догодити.

Зашто тунел смањује употребљиви пакет

Ако интерфејс тунела задржи MTU физичке везе, сваки велики пакет зависи од тога да ли ће неко ниже на путањи бити вољан да га фрагментира. IPv4 то у принципу дозвољава, али рутер коме је речено да не фрагментира враћа грешку. IPv6 рутери никада не фрагментирају у транзиту, па се исто подешавање понаша другачије према породици адреса. У сваком случају пошиљалац не сазнаје ништа док нешто не извести назад.

Практична последица је величина која стаје у руковање, али не у корисни терет. TLS ClientHello или DNS упит су довољно мали да неометано прођу кроз смањену путању, док масовни пренос није. Зато се симптоми групишу око одређених операција, а не одређених хостова.

Откривање ради само када стигне повратна информација

Откривање IPv4 ослања се на don't-fragment бит: рутер који не може да проследи пакет враћа ICMP fragmentation-needed са MTU-ом следећег скока, а пошиљалац снижава своју процену. IPv6 уместо тога користи поруке Packet Too Big, јер рутери не фрагментирају у транзиту. Оба механизма претпостављају да ће порука наћи пут назад до пошиљаоца, кроз тунел и поред сваког заштитног зида на повратном путу. Када та претпоставка падне, пошиљалац наставља да изнова покушава величину коју путања не може да пренесе.

Заштитни зид који дозвољава echo request и echo reply није нужно дозволио те типове грешака. ICMP је породица, и чланови који су овде важни су грешке, а не пар одјека. Проверите политику контролног саобраћаја на оба краја тунела и на путањи између њих, и следите подржане смернице платформе уместо да свуда дозволите сваки ICMP тип.

Исто филтрирање може да седи унутар тунела. Ако унутрашња путања одбаци грешку, али је спољашња пренесе, пошиљалац може да се прилагоди граници коју инкапсулирани саобраћај никада заправо не види.

Тестирајте путању уместо да погађате број

Држите одредиште, приступну мрежу и тунел фиксним, а мењајте само величину пакета. Тест don't-fragment који не успе са MTU назнаком даје вам границу следећег скока; понављајте док нека величина не прође, и забележите и величину и породицу адреса.

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

Ping који стаје не доказује да стају сегменти пуне величине стварне апликације, па поновите тест са преносом који је заиста отказао. Упоредите највећи тест који је радио са MTU-ом тунела који сте конфигурисали, и држите та два броја одвојено у својим белешкама. Ако се разликују за око једно заглавље, пронашли сте додатак за инкапсулацију, а не квар.

PLPMTUD, описан у RFC 4821, тестира нагоре и користи транспортне потврде уместо да верује достављеним грешкама. Помаже на путањама које филтрирају ICMP, али подршка варира по стек-у и по апликацији. TCP ток може сам да се опорави, док UDP апликација са фиксном величином датаграма наставља да отказује.

Изаберите вредност и забележите образложење

Снижавање MTU-а тунела је и дијагностика и легитимна поправка када већ познајете путању. Оно није замена за знање о томе која путања и који механизам повратне информације су били укључени, јер ће вредност подешена за мобилну везу бити непотребно мала на оптичкој вези. Забележите изабрану величину, тест који ју је оправдао и корак враћања.

IPv4 механизам је описан у RFC 1191, а смернице за IPv6 пакетизацију у RFC 8201; навођење оба спречава следећег инжењера да поново изведе претпоставку. Ако пренос и даље застаје на величини коју сте изабрали, престаните да снижавате број и погледајте следећи слој. Путања која отказује при свакој величини није MTU проблем.

Повезани чланци