IPIP uvnitř WireGuardu: těch 20 bajtů navíc, se kterými nikdo nepočítal

Drobné pingy procházejí tunelem celý den, dorazí SSH banner a ve chvíli, kdy začne přenos souboru, se relace zasekne. Ten vzorec ukazuje na rozpočet bajtů počítaný ve špatné vrstvě, kde byl vnější tunel dimenzován na vlastní režii a nikdo neodečetl tu vnitřní. Vnořený paket IPIP je pro WireGuard jen další IP paket, a právě proto spotřebovává bajty, které jste nikdy nerezervovali. Oprava je aritmetika a vejde se do tří příkazů a jedné tabulky.

Příznak, který to prozradí

Problém s fragmentací se ohlašuje velikostí, nikdy adresami. Váš protějšek odpovídá na 56bajtový ping celou hodinu a pak při 1400 bajtech ztichne, zatímco tunel zůstává nahoře a žádná trasa se nezměnila. Handshake se vejde, první plné TCP okno ne, a přenos se zastaví pár sekund poté, co vypadal zdravě.

Změřte strop, než cokoli upravíte, protože neměřený strop je ten, který budete honit dvakrát. Pošlete jednu sondu pod podezřelou velikostí s nastaveným bitem do-not-fragment, ping -M do -s 1000 10.9.0.2, a pak ji zopakujte na velikosti, o níž už víte, že je příliš velká. Když se zvrat drží velikosti užitečného zatížení, zatímco cíl zůstává stejný, směrování dělá svou práci a v rozpočtu chybí jedna hlavička.

Počítejte každou hlavičku jednou, ve správné vrstvě

Začněte od nejmenšího MTU na cestě, ne od rozhraní tunelu, protože zeď stojí výš než oba konce. WireGuard utratí 60 bajtů za vnější IPv4 transport: 20 za IP, 8 za UDP a 32 za svou vlastní hlavičku, a 80 bajtů, když je tím transportem IPv6. wg0 o 1420 bajtech drží 20 bajtů rezervy pod 1440, které cesta o 1500 bajtech skutečně doručí, a proto číslo zkopírované z wiki i sem pořád pasuje. Nakreslete celý stack do diagramu, protože kdo příště změní MTU, jinak zvolí nové kulaté číslo a zdědí vaši chybu.

Pátý řádek je místo, kde se rozpočty pokazí, protože 1400 bajtů, které nese vnořené rozhraní, už zahrnují vlastních 40 bajtů hlaviček původního paketu. Do procesu, který soubor čte, se dostane jen 1360 z těchto bajtů. Berte 1400 jako aplikační užitečné zatížení, k čemuž vás zve každý diagram bez onoho sloupce, a vnitřní zařízení skončí o 40 bajtů příliš štědré vůči zdi, která se nepohnula.

Nastavte obě MTU zvlášť

Nosič a vnořené zařízení jsou samostatné objekty, takže každý potřebuje vlastní hodnotu. Použijte je v tomto pořadí, protože vnořené zařízení od nosiče nic nedědí:

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

Pravidlo, které stojí za zapamatování: vnitřní MTU = vnější MTU - 20, když je paket, který tunel IPIP nese, IPv4, a - 40, jakmile je kterákoli strana vnitřního paketu IPv6, protože vnořená hlavička roste z 20 bajtů na 40. Do toho odčítání nic jiného nepatří. Režie WireGuardu už byla utracena, když jste zvolili 1420, a její účtování dvakrát vytvoří tunel, který funguje dokonale a zůstává pomalý, dokud ho nikdo neměří. Nasazení, kde obě zařízení nesou kulatých 1400, je otiskem právě té chyby.

IPv6 na kterékoli straně vnořeného paketu zneplatní každé číslo výše, takže přepočítejte, místo abyste opisovali číslo z podobného webu. Odečítané hlavičky mají po 40 bajtech, jakmile se IPv6 objeví ve vnější cestě nebo v původním datagramu, a číslo užitečného zatížení klesne přesně o tolik.

Firewallové pravidlo, které pravděpodobně nepotřebujete

Mezi dvěma protějšky WireGuardu je na drátě jediné UDP, takže příchozí pravidlo pro protokol 4, číslo, které RFC 2003 přiděluje zapouzdření IPv4-v-IPv4, vnořenou cestu ani nevytváří, ani neudržuje. Hlavička IPIP žije uvnitř šifrovaného užitečného zatížení, kde ji žádný hraniční firewall nevidí. Otevření protokolu 4 stejně nekoupí nic než jednu další povolenou cestu do hostitele.

Zásada, která zmiňuje zdroje a cíle původního paketu, patří za dekapsulaci, na rozhraní tunelu a do směrovací tabulky. Umístěte ji tam a hraniční pravidlo může zůstat zavřené.

Co WireGuard skutečně validuje

AllowedIPs posuzuje zdroj paketu, který WireGuard nese, a nese paket zapouzdřený v IPIP. Povolený zdroj IPIP se přijme, i když hlavička uvnitř jmenuje hostitele, který byste raději nesměrovali. Původní zdroj tedy není to, co za vás protějšek zkontroloval, a tato vnitřní dvojice adres potřebuje vlastní vynucení po dekapsulaci.

Obal dodává směrovací strukturu, ne druhou vrstvu kryptografie. Nazývat IPIP dodatečnou ochranou uvnitř WireGuardu popisuje jiný návrh.

Ověřujte žebříkem, ne jediným pingem

Otestujte velikosti, které obklopují vypočtenou hranici, a pak potvrďte, co si jádro myslí o obou zařízeních. Když 1360 bajtů užitečného zatížení plus 40 bajtů hlaviček dává 1400, první ozvěna níže projde a druhá sedí jeden bajt za stropem:

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

Čistý průchod pod stropem a selhání při první velikosti nad ním znamenají, že aritmetika drží od začátku do konce. Pak znovu spusťte přenos, který se původně zasekl, protože syntetická sonda dokazuje rozpočet a neříká nic o velikostech zápisu odesílatele. Pokud se vnořená cesta stále láme při velikosti, o níž jste dokázali, že se vejde, prohlédněte dekapsulaci a trasy vzdáleného konce, než ukrojíte dalších deset bajtů z MTU.