Откривање на MTU на патеката низ VPN: големина и ICMP празнина

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

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

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

Изберете вредност и запишете го образложението

Намалувањето на MTU-то на тунелот е и дијагностика и легитимно поправање откако ја знаете патеката. Тоа не е замена за знаењето која патека и кој механизам на повратна информација биле вклучени, зашто вредност прилагодена за мобилна врска ќе биде непотребно мала на оптичка врска. Запишете ја избраната големина, тестот што ја оправда и чекорот за враќање.

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