IPIP унутры WireGuard: лішнія 20 байтаў, якія ніхто не заклаў у бюджэт

Дробныя пінгі ўвесь дзень ідуць праз тунель, з'яўляецца банер SSH, і ў момант пачатку пераносу файла сесія замірае. Гэтая карціна ўказвае на бюджэт байтаў, палічаны на няправільным узроўні: знешні тунель быў памераны пад уласныя накладныя выдаткі, а ўнутраны ніхто не адняў. Укладзены пакет IPIP для WireGuard — проста чарговы IP-пакет, менавіта таму ён спажывае байты, якія вы ніколі не рэзервавалі. Выпраўленне — арыфметыка, і яно ўкладаецца ў тры каманды і адну табліцу.

Сімптом, які гэта выдае

Праблема фрагментацыі заўсёды аб'яўляе сябе памерам, ніколі адрасамі. Ваш партнёр адказвае на 56-байтавы ping гадзіну, а потым змаўкае на 1400 байтах, пакуль тунель застаецца ўзнятым і ніводзін маршрут не змяніўся. Рукапоціск змяшчаецца, першае поўнае акно TCP не, і перанос спыняецца праз некалькі секунд пасля таго, як выглядаў здаровым.

Вымерайце столь да таго, як нешта рэдагаваць, бо невымераная столь — тая, якую вы будзеце даганяць двойчы. Дашліце адзін пробны пакет ніжэй за падазроны памер з усталяваным бітам do-not-fragment, ping -M do -s 1000 10.9.0.2, затым паўтарыце яго на памеры, пра які вы ўжо ведаеце, што ён занадта вялікі. Калі пераключэнне ідзе за памерам карыснай нагрузкі, а пункт прызначэння застаецца нязменным, маршрутызацыя робіць сваю справу, і ў бюджэце не хапае аднаго загалоўка.

Палічыце кожны загаловак адзін раз, на правільным узроўні

Пачынайце з найменшага MTU на шляху, а не з інтэрфейса тунеля, бо сцяна знаходзіцца вышэй за абодва канцы. WireGuard траціць 60 байтаў на знешні транспарт IPv4: 20 на IP, 8 на UDP і 32 на ўласны загаловак, а 80 байтаў, калі гэты транспарт — IPv6. wg0 на 1420 байтаў трымае 20 байтаў запасу ніжэй за 1440, якія шлях на 1500 байтаў можа рэальна даставіць, таму лічба, скапіяваная з вікі, тут таксама падыходзіць. Намалюйце ўвесь стек на схеме, бо той, хто наступным зменіць MTU, інакш выбера новы круглы лік і атрымае вашу памылку ў спадчыну.

Пяты радок — месца, дзе бюджэты ламаюцца, бо 1400 байтаў, якія нясе ўкладзены інтэрфейс, ужо ўключаюць уласныя 40 байтаў загалоўкаў зыходнага пакета. Толькі 1360 з гэтых байтаў даходзяць да працэса, які чытае файл. Калі лічыць 1400 карыснай нагрузкай прыкладання, да чаго схема без гэтай калонкі вас запрашае, унутраная прылада аказваецца на 40 байтаў занадта шчодрай перад сцяной, якая не рушыла.

Задайце два MTU асобна

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

ip link set wg0 mtu 1420
ip tunnel add ipip0 mode ipip remote 203.0.113.9 local 198.51.100.4
ip link set ipip0 mtu 1400

Правіла, вартае запомнівання: унутраны MTU = знешні MTU - 20, калі пакет, які нясе тунель IPIP, — IPv4, і - 40, як толькі любы бок унутранага пакета становіцца IPv6, бо ўкладзены загаловак расце з 20 байтаў да 40. Нішто іншае ў гэта адыманне не ўваходзіць. Накладныя выдаткі WireGuard ужо панесеныя, калі вы выбралі 1420, і спагнанне іх двойчы стварае тунель, які ідэальна працуе і застаецца павольным, пакуль ніхто яго не мерае. Разгортванне, дзе абедзве прылады нясуць круглыя 1400, — гэта адбітак менавіта такой памылкі.

IPv6 на любым баку ўкладзенага пакета абвяргае ўсе лічбы вышэй, таму пералічвайце, а не капіруйце лік з падобнага сайта. Адыманыя загалоўкі — па 40 байтаў кожны, як толькі IPv6 з'яўляецца ў знешнім шляху або ў зыходнай дэтаграме, і лік карыснай нагрузкі падае менавіта на столькі.

Правіла брандмаўэра, якое вам, верагодна, не патрэбна

Паміж двума партнёрамі WireGuard адзінае, што ідзе па дроце, — UDP, таму ўваходнае правіла для пратакола 4, нумара, які RFC 2003 прысвойвае інкапсуляцыі IPv4-у-IPv4, не стварае ўкладзены шлях і не падтрымлівае яго. Загаловак IPIP жыве ўнутры зашыфраванай нагрузкі, дзе яго не бачыць ніводзін памежны брандмаўэр. Адкрыццё пратакола 4 усё роўна не дае нічога, акрамя яшчэ аднаго дазволенага шляху на хост.

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

Што WireGuard насамрэч правярае

AllowedIPs вызначае крыніцу пакета, які нясе WireGuard, а нясе ён пакет, інкапсуляваны ў IPIP. Дазволеная крыніца IPIP прымаецца нават тады, калі загаловак унутры называе хост, куды вы б не хацелі маршрутызаваць. Такім чынам, зыходная крыніца — не тое, што партнёр праверыў за вас, і гэтая ўнутраная пара адрасоў патрабуе ўласнага кантролю пасля дэкапсуляцыі.

Абгортка дае структуру маршрутызацыі, а не другі пласт крыптаграфіі. Называць IPIP дадатковай абаронай унутры WireGuard — гэта апісанне іншага дызайну.

Правярайце лесвіцай, а не адным пінгам

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

ping -M do -s 1372 10.9.0.2
ping -M do -s 1373 10.9.0.2
wg show wg0
ip -d link show ipip0

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