Міфы пра MTU у VPN: чаму вашыя пакеты памяншаюцца і куды знікае месца

Хтосьці кажа вам, што VPN "губіць пакеты праз MTU", вы ставіце тунель на 1400, і перадача зноў працуе. Такі вынік здаецца дыягназам. Звычайна гэта арыфметычнае супадзенне: вы выбралі лік, дастаткова малы, каб змясціцца пад мяжой, якую так і не вызначылі, і зноў сустрэнеце тую ж мяжу ў наступнай сетцы з іншым бюджэтам.

Большасць гэтага ствараюць два міфы. Першы — што MTU інтэрфейса тунеля гэта MTU шляху. Другі — што інкапсуляцыя каштуе "адзін загаловак", а PPPoE не каштуе нічога, вартага ўліку. Абодва памылковыя так, што выбраны вамі лік выглядае адвольным, хоць насамрэч вызначаны.

Міф першы: MTU тунеля гэта MTU шляху

Значэнне, якое вы задаяце на інтэрфейсе тунеля, — гэта лакальнае абяцанне пра найбольшы ўнутраны пакет, які рэалізацыя аддасць уніз. Сапраўдная ёмістасць шляху — уласцівасць кожнага звяна паміж вамі і далёкім канцом, і яна можа змяняцца, калі мяняецца маршрут, калі мабільнае злучэнне перадае эстафету або калі трафік ідзе іншым пірынгам. Зададзены 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, бо дасягае адпраўніка, не памяншаючы кожны пакет. Пераправерце тую ж мэту і тую ж перадачу і запішыце лікі, на якіх спыніліся. Значэнне тунеля, якое працуе ў адной сетцы доступу, не ўніверсальная канстанта, і наступная пляцоўка будзе мець свой бюджэт.