Вы ўключылі кадры па 9000 байт у лакальнай сетцы і чакалі, што VPN стане хутчэйшым. Ён стаў павольнейшым або зусім перастаў прапускаць буйныя перадачы. Джамба-кадры — гэта лакальная дамова аб звяне; яны не павялічваюць шлях, які перасякае тунель.

Прыдатны бюджэт вызначаецца найменшай мяжой на маршруце, уключаючы інкапсуляцыю, якую дадае тунель.

Што джамба-кадры сапраўды змяняюць

MTU — уласцівасць аднаго інтэрфейса. Павышэнне яго на серверы і яго камутатары азначае, што гэтыя два могуць абменьвацца большымі кадрамі без фрагментацыі. Гэта нічога не кажа пра маршрутызатар за камутатарам, пра пастаўшчыка паслуг або пра іншы бок тунеля. У гэтых прылад свае межы, і пакет, які перавышае адну з іх, адкідаецца або фрагментуецца паводле правілаў, якія вы не ўсталёўвалі.

Лакальная дамова, глабальныя наступствы. Вось у чым уся блытаніна.

Падатак на інкапсуляцыю

Тунель заварочвае ваш пакет унутры іншага. WireGuard паверх IPv4 UDP дадае прыкладна 60 байт накладных выдаткаў; рэжым UDP у OpenVPN знаходзіцца ў тым жа дыяпазоне, а IPsec змяняецца ў залежнасці ад рэжыму і алгарытмаў. Гэтыя байты бяруцца з бюджэту знешняга шляху, а не з паветра.

Такім чынам, знешняе звяно ў 1500 байт не можа несці ўнутраны пакет у 1500 байт, калі дададзены загаловак тунеля.

Арыфметыку варта прарабіць адзін раз. На шляху ў 1500 байт інтэрфейс WireGuard хоча MTU каля 1420, каб інкапсуляваны пакет змясціўся. Усталюйце ўнутраны інтэрфейс на 9000, і кожны буйны пакет запатрабуе фрагментацыі, якую тунель не можа выканаць, або будзе адкінуты.

Знайдзіце найменшае звяно на шляху

Прайдзіце маршрут і знайдзіце найніжэйшы MTU. LAN звычайна 1500 або 9000, WAN звычайна 1500, а мабільнае або PPP-звяно можа быць яшчэ ніжэйшым. Затым адніміце накладныя выдаткі тунеля. Калі вынік меншы за MTU унутранага інтэрфейса, вось ваш адказ. Выяўленне MTU шляху можа знайсці гэта аўтаматычна, але толькі калі паведамленні ICMP, ад якіх яно залежыць, прапускаюцца.

Фільтраваны ICMP — класічная прычына, чаму буйная перадача завісае, пакуль дробныя запыты працуюць выдатна.

Праверце залежнасць ад памеру, не пашыраючы змяненне

Выкарыстайце рэпрэзентатыўную перадачу і захавайце зыходныя значэнні, каб потым вярнуць іх. ping -M do -s 1472 правярае пакет у 1500 байт з усталяваным бітам DF; паменшыце памер, пакуль ён не пройдзе. Калі няўдалыя толькі буйныя пакеты, у вас праблема памеру, а не маршрутызацыі.

Сцеражыцеся офлоада на баку хоста пры чытанні перахопаў. Сегментацыйны офлоад можа паказваць кадры, значна большыя за тое, што фактычна прайшло па дроце, і таму працоўны шлях выглядае зламаным, а зламаны — спакойным.

Калі вялікі MTU — правільны дызайн

Кіруемая прыватная сетка можа цалкам законна пускаць большыя кадры ад канца да канца, пры ўмове, што кожная прылада на шляху згодная і накладныя выдаткі тунеля ўлічаны. Гэта ўзгоднены дызайн з дакументаваным значэннем для кожнага звяна, а не адзін вялікі лік, набраны ў кліенце.

Для звычайнага публічнага выхаду меркавайце 1500 або менш і дазвольце тунелю выбраць бяспечны ўнутраны MTU. RFC 8201 ахоплівае выяўленне MTU шляху для выпадку IPv6 і з'яўляецца карыснай даведкай пра тое, як павінна працаваць зваротная сувязь.

Падобныя артыкулы