IPIP a WireGuardon belül: a plusz 20 bájt, amire senki nem készített költségvetést

Kis pingek járják át az alagutat egész nap, megérkezik az SSH-banner, majd a fájlátvitel indulásának pillanatában megfagy a munkamenet. Ez a minta rossz rétegen számolt bájt-költségvetésre utal, ahol a külső alagutat a saját ráfordítása szerint méretezték, a belsőt pedig senki nem vonta le. Egy beágyazott IPIP-csomag a WireGuard számára csak egy újabb IP-csomag, és épp ezért fogyaszt olyan bájtokat, amelyeket soha nem foglalt le. A javítás aritmetika, és három parancsba meg egy táblázatba belefér.

A tünet, amely elárulja

A fragmentációs probléma mérettel jelzi magát, soha nem címekkel. A társa egy órán át válaszol egy 56 bájtos ping-re, majd 1400 bájtnál elhallgat, miközben az alagút állva marad, és egyetlen útvonal sem változott. A kézfogás belefér, az első teljes TCP-ablak nem, és az átvitel másodpercekkel azután akad el, hogy egészségesnek látszott.

Mérje meg a plafont, mielőtt bármit szerkesztene, mert a méretlen plafon az, amelyet kétszer fog üldözni. Küldjön egy próbát a gyanús méret alá a do-not-fragment bittel beállítva, ping -M do -s 1000 10.9.0.2, majd ismételje meg egy olyan méreten, amelyről már tudja, hogy túl nagy. Amikor a billenés a hasznos teher méretét követi, miközben a cél változatlan marad, az útválasztás végzi a dolgát, és egy fejléc hiányzik a költségvetésből.

Minden fejlécet egyszer számoljon, a megfelelő rétegen

Az útvonal legkisebb MTU-jából induljon ki, ne az alagút interfészéből, mert a fal mindkét végpont felett van. A WireGuard 60 bájtot költ egy IPv4-es külső szállításra: 20-at az IP-re, 8-at az UDP-re és 32-t a saját fejlécére, és 80 bájtot, amikor ez a szállítás IPv6. Egy 1420 bájtos wg0 20 bájt tartalékot hagy az 1440 alatt, amelyet egy 1500 bájtos útvonal valóban szállíthat, és ezért fér ide a wikiből másolt szám még mindig. Rajzolja fel a teljes vermet a diagramra, mert aki legközelebb módosítja az MTU-t, az különben új kerek számot választ, és örökli a hibáját.

Az ötödik sor az, ahol a költségvetések elromlanak, mert a beágyazott interfész által hordozott 1400 bájt már tartalmazza az eredeti csomag saját 40 bájtjának fejléceit. Ebből a bájtból csak 1360 ér el a fájlt olvasó folyamathoz. Tekintse az 1400-at alkalmazás-hasznos tehernek, ahogy minden ilyen oszlop nélküli diagram hívja, és a belső eszköz 40 bájttal túl bőkezűen végzi egy fal előtt, amely nem mozdult.

Két MTU-t külön állítson be

A hordozó és a beágyazott eszköz külön objektumok, ezért mindkettőnek saját érték kell. Ebben a sorrendben alkalmazza őket, mert a beágyazott eszköz semmit nem örököl a hordozótól:

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

A megjegyzésre érdemes szabály: belső MTU = külső MTU - 20, amikor az IPIP-alagút által hordozott csomag IPv4, és - 40, amint a belső csomag bármely oldala IPv6, mert a beágyazott fejléc 20 bájtról 40-re nő. Semmi más nem tartozik ehhez a kivonáshoz. A WireGuard ráfordítása már elköltődött, amikor a 1420-at választotta, és kétszeri felszámítása olyan alagutat ad, amely tökéletesen működik, és addig marad lassú, amíg senki nem méri. Az a telepítés, ahol mindkét eszköz kerek 1400-at hordoz, épp ennek a hibának az ujjlenyomata.

Az IPv6 a beágyazott csomag bármely oldalán érvénytelenít minden fenti számot, ezért számoljon újra ahelyett, hogy számot másolna egy hasonló oldalról. A kivont fejlécek egyenként 40 bájtosak, amint az IPv6 megjelenik a külső útvonalon vagy az eredeti datagramban, és a hasznos teher száma pontosan ennyivel csökken.

A tűzfalszabály, amelyre valószínűleg nincs szüksége

Két WireGuard-társ között az egyetlen dolog a vezetéken az UDP, ezért a 4-es protokollra, az RFC 2003 által az IPv4-az-IPv4-ben beágyazásnak adott számra vonatkozó bejövő szabály sem nem hozza létre a beágyazott útvonalat, sem nem tartja életben. Az IPIP-fejléc a titkosított hasznos teheren belül él, ahol egyetlen peremtűzfal sem látja. A 4-es protokoll megnyitása így sem vesz semmit azon kívül, hogy még egy engedélyezett utat ad a gazdagéphez.

Az eredeti csomag forrásait és céljait említő házirend a visszafejtés után, az alagút interfészein és az útválasztási táblában a helye. Tegye oda, és a peremszabály zárva maradhat.

Mit validál valójában a WireGuard

AllowedIPs a WireGuard által hordozott csomag forrását ítéli meg, és amit hordoz, az az IPIP-vel beágyazott csomag. Az engedélyezett IPIP-forrás akkor is elfogadható, ha a belső fejléc olyan gazdagépet nevez meg, amelyet inkább nem irányítana. Az eredeti forrás tehát nem az, amit a társ ön helyett ellenőrzött, és annak a belső címepárnak a visszafejtés után saját érvényesítésre van szüksége.

A burkoló útválasztási szerkezetet ad, nem második kriptográfiai réteget. Az IPIP-et extra védelemnek nevezni a WireGuardon belül másféle tervezést ír le.

Létrával ellenőrizze, ne egyetlen pinggel

Próbáljon ki a számított határt mindkét oldalról átfogó méreteket, majd erősítse meg, mit gondol a kernel mindkét eszközről. Ha 1360 bájt hasznos teher plusz 40 bájt fejléc 1400-at ad, az alábbi első visszhang belefér, a második pedig egy bájttal a plafonon túl ül:

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

A plafon alatti tiszta átjutás és a felette lévő első méreten bekövetkező hiba azt jelenti, hogy az aritmetika végig megáll. Utána futtassa újra az eredetileg elakadt átvitelt, mert a szintetikus próba bizonyítja a költségvetést, és semmit sem mond a küldő saját írási méreteiről. Ha a beágyazott útvonal továbbra is eltörik egy olyan méreten, amelyről bebizonyította, hogy belefér, vizsgálja meg a távoli végpont visszafejtését és útvonalait, mielőtt még tíz bájtot levágna az MTU-ból.