Мали ping-ови пролазе кроз тунел цео дан, SSH банер стиже, а затим се сесија замрзне у тренутку када почне пренос датотеке. Овај образац указује на буџет бајтова израчунат на погрешном слоју, где је спољни тунел димензионисан за сопствени overhead, а нико није одузео унутрашњи. Угнежђени 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 иначе изабрати нови округли број и наследити вашу грешку.

LayerBytesRemaining
Path MTU on the wired linknone yet1500
WireGuard outer: IP, UDP, WG header601440
Slack kept for safety201420 (wg0)
IPIP header inside the tunnel201400 (ipip0)
Original IPv4 and TCP headers401360 payload

Пети ред је место где буџети попусте, јер 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. Ништа друго не припада том одузимању. Overhead WireGuard-а је већ потрошен када сте изабрали 1420, а његово наплаћивање двапут ствара тунел који савршено ради и остаје спор док год га нико не мери. Поставка у којој оба уређаја носе округлих 1400 је отисак управо те грешке.

IPv6 на било којој страни угнежђеног пакета поништава сваки број горе, па прерачунајте уместо да копирате број са сличног сајта. Одузета заглавља су по 40 бајтова када се IPv6 појави у спољном путу или у оригиналној датаграми, а бројка носивог терета пада тачно за толико.

Правило заштитног зида које вам вероватно не треба

Између два WireGuard партнера једино што иде жицом је UDP, па улазно правило за протокол 4, број који RFC 2003 додељује инкапсулацији IPv4-у-IPv4, нити ствара угнежђени пут нити га одржава живим. Заглавље IPIP живи унутар шифрованог носивог терета, где га ниједан рубни заштитни зид не види. Отварање протокола 4 ипак не купује ништа осим још једног дозвољеног пута ка хосту.

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

Шта WireGuard заиста валидира

AllowedIPs просуђује извор пакета који WireGuard носи, а носи IPIP-инкапсулирани пакет. Дозвољени IPIP извор се прихвата чак и када заглавље унутра именује хост ка коме радије не бисте рутирали. Оригинални извор дакле није оно што је партнер проверио за вас, и том унутрашњем пару адреса потребно је сопствено спровођење после декапсулације.

Омот пружа структуру рутирања, а не други слој криптографије. Називати IPIP додатном заштитом унутар WireGuard-а описује другачији дизајн.

Проверите лествицом, не једним ping-ом

Проверите величине које обухватају израчунату границу, затим потврдите шта језгро мисли о оба уређаја. Када 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-а.

Повезани чланци