МТУ митови за 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 рамката, што остава 1492 за IP пакетот. Тоа е традиционалната граница опишана во RFC 2516. Ако возите VPN преку таква врска, трошокот на тунелот доаѓа од тие 1492, не од 1500.

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

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

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

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

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

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

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