IPIP vo vnútri WireGuardu: tých 20 bajtov navyše, s ktorými nikto nepočítal

Malé pingy prechádzajú tunelom celý deň, dorazí SSH banner a potom sa relácia zasekne v okamihu, keď sa začne prenos súboru. Tento vzor ukazuje na rozpočet bajtov počítaný v nesprávnej vrstve, kde bol vonkajší tunel dimenzovaný na vlastnú réžiu a nikto neodpočítal tú vnútornú. Vnorený paket IPIP je pre WireGuard len ďalší IP paket, a práve preto spotrebúva bajty, ktoré ste nikdy nerezervovali. Oprava je aritmetika a zmestí sa do troch príkazov a jednej tabuľky.

Príznak, ktorý to prezrádza

Problémy s fragmentáciou sa ohlasujú veľkosťou, nikdy adresami. Váš partner odpovedá na 56-bajtový ping celú hodinu a potom pri 1400 bajtoch stíchne, zatiaľ čo tunel zostáva hore a žiadna trasa sa nezmenila. Handshake sa zmestí, prvé plné TCP okno nie, a prenos sa zastaví pár sekúnd po tom, čo vyzeral zdravo.

Zmerajte strop, skôr než čokoľvek upravíte, pretože nemeraný strop je ten, ktorý budete naháňať dvakrát. Pošlite jednu sondu pod podozrivou veľkosťou s nastaveným bitom do-not-fragment, ping -M do -s 1000 10.9.0.2, a potom ju zopakujte pri veľkosti, o ktorej už viete, že je príliš veľká. Keď sa zvrat drží veľkosti užitočného zaťaženia, zatiaľ čo cieľ zostáva rovnaký, smerovanie robí svoju prácu a v rozpočte chýba jedna hlavička.

Počítajte každú hlavičku raz, v správnej vrstve

Začnite od najmenšieho MTU na ceste, nie od rozhrania tunela, pretože stena stojí nad oboma koncami. WireGuard minie 60 bajtov na vonkajší IPv4 transport: 20 na IP, 8 na UDP a 32 na vlastnú hlavičku, a 80 bajtov, keď je tým transportom IPv6. wg0 s veľkosťou 1420 bajtov drží 20 bajtov rezervy pod 1440, ktoré cesta s 1500 bajtmi naozaj doručí, a preto číslo skopírované z wiki sem stále pasuje. Nakreslite celý stack do diagramu, pretože kto nabudúce zmení MTU, inak zvolí nové okrúhle číslo a zdedí vašu chybu.

Piaty riadok je miesto, kde sa rozpočty pokazia, pretože 1400 bajtov, ktoré nesie vnorené rozhranie, už zahŕňa vlastných 40 bajtov hlavičiek pôvodného paketu. Do procesu, ktorý súbor číta, sa dostane len 1360 z týchto bajtov. Berte 1400 ako aplikačné užitočné zaťaženie, k čomu vás pozýva každý diagram bez tohto stĺpca, a vnútorné zariadenie skončí o 40 bajtov príliš štedré voči stene, ktorá sa nepohla.

Nastavte obe MTU zvlášť

Nosič a vnorené zariadenie sú samostatné objekty, takže každé potrebuje vlastnú hodnotu. Použite ich v tomto poradí, pretože vnorené zariadenie od nosiča nič nededia:

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, ktoré sa oplatí zapamätať: vnútorné MTU = vonkajšie MTU - 20, keď je paket, ktorý tunel IPIP nesie, IPv4, a - 40, hneď ako je ktorákoľvek strana vnútorného paketu IPv6, pretože vnorená hlavička rastie z 20 bajtov na 40. Do tohto odčítania nepatrí nič iné. Réžia WireGuardu už bola minutá, keď ste zvolili 1420, a jej účtovanie dvakrát vytvorí tunel, ktorý funguje dokonale a zostane pomalý, kým ho nikto nemeria. Nasadenie, kde obe zariadenia nesú okrúhlych 1400, je odtlačkom prstov práve tej chyby.

IPv6 na ktorejkoľvek strane vnoreného paketu zneplatní každé číslo vyššie, takže prepočítajte, namiesto toho, aby ste kopírovali číslo z podobnej stránky. Odpočítané hlavičky majú po 40 bajtov, hneď ako sa IPv6 objaví vo vonkajšej ceste alebo v pôvodnom datagrame, a číslo užitočného zaťaženia klesne presne o toľko.

Firewallové pravidlo, ktoré pravdepodobne nepotrebujete

Medzi dvoma partnermi WireGuardu je na drôte jediné UDP, takže prichádzajúce pravidlo pre protokol 4, číslo, ktoré RFC 2003 prideľuje zapuzdreniu IPv4-v-IPv4, vnorenú cestu ani nevytvára, ani neudržiava. Hlavička IPIP žije vnútri šifrovaného užitočného zaťaženia, kde ju žiadny hraničný firewall nevidí. Otvorenie protokolu 4 aj tak nekúpi nič okrem jednej ďalšej povolenej cesty do hostiteľa.

Politika, ktorá spomína zdroje a ciele pôvodného paketu, patrí za dekapsuláciu, na rozhrania tunela a do smerovacej tabuľky. Umiestnite ju tam a hraničné pravidlo môže zostať zatvorené.

Čo WireGuard skutočne validuje

AllowedIPs posudzuje zdroj paketu, ktorý WireGuard nesie, a nesie paket zapuzdrený v IPIP. Povolený zdroj IPIP sa prijme, aj keď hlavička vnútri pomenúva hostiteľa, ktorý by ste radšej nesmerovali. Pôvodný zdroj teda nie je to, čo za vás partner skontroloval, a táto vnútorná dvojica adries potrebuje vlastné vynútenie po dekapsulácii.

Obal poskytuje smerovaciu štruktúru, nie druhú vrstvu kryptografie. Nazývať IPIP dodatočnou ochranou vnútri WireGuardu opisuje iný dizajn.

Overujte rebríkom, nie jediným pingom

Otestujte veľkosti, ktoré obklopujú vypočítanú hranicu, a potom potvrďte, čo si jadro myslí o oboch zariadeniach. Keď 1360 bajtov užitočného zaťaženia plus 40 bajtov hlavičiek dáva 1400, prvé echo nižšie prejde a druhé sedí jeden bajt za stropom:

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ý prechod pod stropom a zlyhanie pri prvej veľkosti nad ním znamenajú, že aritmetika drží od začiatku do konca. Potom znova spustite prenos, ktorý sa pôvodne zasekol, pretože syntetická sonda dokazuje rozpočet a nič nehovorí o vlastných veľkostiach zápisu odosielateľa. Ak sa vnorená cesta stále láme pri veľkosti, o ktorej ste dokázali, že sa zmestí, preskúmajte dekapsuláciu a trasy vzdialeného konca, skôr než ukrojíte ďalších desať bajtov z MTU.