IPIP внатре во WireGuard: тие дополнителни 20 бајти што никој не ги стави во буџет

Мали 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 инаку ќе избере нов круг број и ќе ја наследи вашата грешка.

Петтиот ред е каде што буџетите се расипуваат, зашто 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.