IPIP WireGuardin sisällä: ne 20 ylimääräistä tavua, joita kukaan ei budjetoinut

Pienet pingit kulkevat tunnelin läpi koko päivän, SSH-banneri saapuu, ja sitten istunto jäätyy hetkellä, jolloin tiedostonsiirto alkaa. Tämä kuvio viittaa väärällä kerroksella laskettuun tavubudjettiin, jossa ulompi tunneli mitoitettiin omalle yläkuluilleen eikä kukaan vähentänyt sisempää. Sisäkkäinen IPIP-paketti on WireGuardille vain yksi IP-paketti muiden joukossa, ja juuri siksi se kuluttaa tavuja, joita et koskaan varannut. Korjaus on aritmetiikkaa, ja se mahtuu kolmeen komentoon ja yhteen taulukkoon.

Oire, joka paljastaa sen

Pirstoutumisongelmat ilmoittavat itsestään koon kautta, eivät koskaan osoitteiden. Vastapuolesi vastaa 56-tavuiseen ping-pakettiin tunnin ajan ja vaikenee sitten 1400 tavussa, kun tunneli pysyy pystyssä eikä mikään reitti muuttunut. Kättely mahtuu, ensimmäinen täysi TCP-ikkuna ei, ja siirto pysähtyy sekunteja sen jälkeen, kun se näytti terveeltä.

Mittaa katto ennen kuin muokkaat mitään, sillä mittaamaton katto on se, jota jahtaat kahdesti. Lähetä yksi luotain epäillyn koon alapuolelle do-not-fragment-bitti asetettuna, ping -M do -s 1000 10.9.0.2, ja toista se sitten koolla, jonka jo tiedät liian suureksi. Kun käänne seuraa hyötykuorman kokoa kohteen pysyessä muuttumattomana, reititys tekee työnsä ja budjetista puuttuu yksi otsake.

Laske jokainen otsake kerran, oikealla kerroksella

Aloita polun pienimmästä MTU:sta, älä tunnelin rajapinnasta, koska seinä on molempien päiden yläpuolella. WireGuard kuluttaa 60 tavua IPv4-ulkokuljetukseen: 20 IP:lle, 8 UDP:lle ja 32 omalle otsakkeelleen, ja 80 tavua, kun tuo kuljetus on IPv6. 1420-tavuinen wg0 pitää 20 tavua pelivaraa sen 1440:n alla, jonka 1500-tavuinen polku voi todella toimittaa, ja siksi wikistä kopioitu luku sopii tähän edelleen. Piirrä koko pino kaavioon, sillä seuraava MTU:n muuttaja valitsee muuten uuden pyöreän luvun ja perii virheesi.

Viides rivi on paikka, jossa budjetit menevät pieleen, koska sisäkkäisen rajapinnan kantamat 1400 tavua sisältävät jo alkuperäisen paketin omat 40 tavua otsakkeita. Vain 1360 noista tavuista saavuttaa tiedostoa lukevan prosessin. Kohtele 1400:tä sovelluksen hyötykuormana, mihin jokainen ilman tuota saraketta oleva kaavio sinua kutsuu, ja sisempi laite päätyy 40 tavua liian anteliaaksi seinää vasten, joka ei ole liikahtanut.

Aseta kaksi MTU:ta erikseen

Kantaja ja sisäkkäinen laite ovat erillisiä olioita, joten kumpikin tarvitsee oman arvonsa. Käytä niitä tässä järjestyksessä, koska sisäkkäinen laite ei peri kantajalta mitään:

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

Sääntö, joka kannattaa painaa mieleen: sisempi MTU = ulompi MTU - 20, kun IPIP-tunnelin kantama paketti on IPv4, ja - 40 heti kun sisemmän paketin kumpi tahansa puoli on IPv6, koska sisäkkäinen otsake kasvaa 20 tavusta 40:een. Mitään muuta ei tuohon vähennykseen kuulu. WireGuardin yläkulu on jo kulutettu, kun valitsit 1420, ja sen veloittaminen kahdesti tuottaa tunnelin, joka toimii täydellisesti ja pysyy hitaana niin kauan kuin kukaan ei mittaa sitä. Käyttöönotto, jossa molemmat laitteet kantavat pyöreää 1400:tä, on juuri tuon virheen sormenjälki.

IPv6 sisäkkäisen paketin kummalla tahansa puolella mitätöi jokaisen yllä olevan luvun, joten laske uudelleen sen sijaan että kopioisit luvun vastaavalta sivustolta. Vähennettävät otsakkeet ovat 40 tavua kukin heti, kun IPv6 ilmestyy ulompaan polkuun tai alkuperäiseen datagrammiin, ja hyötykuorman luku putoaa täsmälleen niin paljon.

Palomuurisääntö, jota et todennäköisesti tarvitse

Kahden WireGuard-vastapuolen välillä ainoa johdolla kulkeva asia on UDP, joten saapuva sääntö protokollalle 4, numerolle, jonka RFC 2003 antaa IPv4-in-IPv4-kapseloinnille, ei luo sisäkkäistä polkua eikä pidä sitä elossa. IPIP-otsake elää salatun hyötykuorman sisällä, missä mikään reunapalomuuri ei näe sitä. Protokollan 4 avaaminen ei silti osta mitään muuta kuin yhden sallitun reitin lisää isäntään.

Käytäntö, joka mainitsee alkuperäisen paketin lähteet ja kohteet, kuuluu kapseloinnin purkamisen jälkeen, tunnelin rajapinnoille ja reititystauluun. Laita se sinne, niin reunasääntö voi pysyä kiinni.

Mitä WireGuard oikeastaan validoi

AllowedIPs arvioi WireGuardin kantaman paketin lähteen, ja se mitä se kantaa on IPIP-kapseloitu paketti. Sallittu IPIP-lähde hyväksytään, vaikka sisempi otsake nimeäisi isännän, jota et mieluiten reitittäisi. Alkuperäinen lähde ei siis ole se, minkä vastapuoli tarkisti puolestasi, ja tuo sisempi osoitepari tarvitsee oman valvontansa kapseloinnin purkamisen jälkeen.

Kääre tarjoaa reititysrakenteen, ei toista salauskerrosta. IPIP:n kutsuminen lisäsuojaksi WireGuardin sisällä kuvaa erilaista suunnittelua.

Varmista tikkailla, älä yksittäisellä pingillä

Kokeile kokoja, jotka rajaavat laskemasi rajan molemmin puolin, ja vahvista sitten, mitä ydin uskoo molemmista laitteista. Kun 1360 tavua hyötykuormaa plus 40 tavua otsakkeita tekee 1400, alla oleva ensimmäinen kaiku mahtuu ja toinen istuu tavun katon tuolla puolen:

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

Puhdas läpimeno katon alapuolella ja epäonnistuminen ensimmäisellä sen yläpuolella olevalla koolla tarkoittaa, että aritmetiikka pitää päästä päähän. Aja sitten uudelleen siirto, joka alun perin jumiutui, koska synteettinen luotain todistaa budjetin eikä kerro mitään lähettäjän omista kirjoituskooista. Jos sisäkkäinen polku yhä katkeaa koolla, jonka todistit mahtuvan, tutki kauemman päätepisteen kapseloinnin purku ja reitit ennen kuin leikkaat vielä kymmenen tavua MTU:sta.