Митови о MTU-у у VPN-у: зашто се ваши пакети смањују и где одлази простор

Неко вам каже да VPN "губи пакете због MTU-а", ви поставите тунел на 1400 и пренос поново ради. Тај резултат изгледа као дијагноза. Обично је то аритметичка случајност: изабрали сте број довољно мали да стане испод границе коју никада нисте утврдили, и поново ћете срести исту границу на следећој мрежи са другим буџетом.

Два мита узрокују већину овога. Први је да је MTU интерфејса тунела MTU путање. Други је да инкапсулација кошта "једно заглавље", а PPPoE ништа што вреди бројати. Оба су погрешна на начин који чини изабрани број произвољним, иако је он заправо одређен.

Први мит: MTU тунела је MTU путање

Вредност коју поставите на интерфејсу тунела локално је обећање о највећем унутрашњем пакету који ће имплементација предати ниже. Стварни капацитет путање је својство сваке везе између вас и далеког краја и може се променити када се промени рута, када се мобилна веза преда другој мрежи или када саобраћај крене другим peering-ом. Постављених 1500 говори шта ће ваш хост саставити, а не шта ће мрежа пренети.

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

Други мит: инкапсулација кошта једно заглавље

Поштено пребројте спољашње слојеве. Спољашње IP заглавље има 20 бајтова у IPv4 или 40 у IPv6. UDP инкапсулација за NAT пролаз додаје 8. Протокол тунела додаје своје заглавље, иницијализациони вектор или nonce, попуњавање до границе блока или поравнања шифре, завршни део и вредност провере интегритета. У зависности од протокола и шифре, укупан износ је удобно у десетинама бајтова пре него што унутрашњи пакет уопште почне.

Затим поново одузмите заглавља самог унутрашњег пакета. TCP сегмент унутар тунела носи своје 20-бајтно IP заглавље и 20-бајтно TCP заглавље, а MSS у TCP-у изводи се из MTU-а, не из номиналног корисног терета тунела. Зато ping са мањим теретом може успети док пренос датотеке застаје: алати испитују различите ствари и само један од њих изводи TCP сегмент пуне величине.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

Прва команда приказује постављени MTU тунела. Две пробе шаљу терет од 1472 бајта, што је уз 28 бајтова IPv4 и ICMP заглавља пакет од 1500 бајтова, а затим мањи. Ако велика проба потпуно не успе, а мала успе, имате квар који зависи од величине, а не општи проблем са рутирањем.

Трећи мит: PPPoE вам још даје чистих 1500

Уобичајена PPPoE приступна веза не преноси IP пакет од 1500 бајтова. PPPoE заглавље плус поље PPP протокола заузимају 8 бајтова унутар Ethernet оквира, што за IP пакет оставља 1492. То је традиционална граница описана у RFC 2516. Ако возите VPN преко такве везе, трошак тунела долази из тих 1492, не из 1500.

RFC 4638 дефинише начин да се преговара о већем PPP корисном терету када то подржавају и приступни концентратор и опрема корисника, зато сама тврдња "ова веза користи PPPoE" не доказује одређени број. Локална поставка не може натерати међууређај да прихвати пакет за који никада није конфигурисан, па је корисно питање шта је веза заиста преговарала, а не шта каже ознака.

Зашто квар изгледа селективно

Мали захтеви који пролазе и велики преноси који застају класичан су потпис црне рупе MTU-а путање. Руковање, DNS упит и API позив сви стану; групни пренос ствара сегменте пуне величине који умиру на једној вези, а ICMP порука која је требало да пријави проблем никада не стигне. Веза изгледа исправно, а преузимање виси, што људе шаље да гледају сервер уместо путању.

Друга, повезана грешка је мешање три броја: MTU-а интерфејса, TCP MSS-а и сопствене поставке фрагментације или попуњавања протокола. Стезање MSS-а на рутеру преписује оглашени MSS како би пошиљалац састављао мање сегменте; оно не мења MTU тунела и не помаже UDP саобраћају. Давање истог броја свима трима јер изгледају повезани је начин на који добронамерна измена поквари исправну поставку.

Шта променити и којим редом

Почните од доказа. Потврдите пробама горе да квар зависи од величине, а затим пронађите најмању величину која пролази и највећу која не пролази. Проверите стварни MTU приступне везе пре него што окривите тунел; PPPoE веза ограничава буџет пре него што је VPN дотакне. Забележите изворне вредности да измена може да се врати.

Затим примените најмању прилагодбу коју клијент документује. Многи клијенти нуде MTU тунела уз опцију исправке MSS-а, а MSS је често боља полуга за TCP јер стиже до пошиљаоца без смањивања сваког пакета. Поново испитајте исти циљ и исти пренос и запишите бројеве на којима сте се зауставили. Вредност тунела која ради на једној приступној мрежи није универзална константа, а следећа локација ће имати свој буџет.