IPIP inne i WireGuard: dei ekstra 20 byta ingen hadde budsjettert med

Små ping går gjennom tunnelen heile dagen, SSH-banneret kjem, og så frys sesjonen i det augneblinken ei filoverføring startar. Mønsteret peikar på eit bytebudsjett talt på feil lag, der den ytre tunnelen vart dimensjonert for sin eigen overhead og ingen trekte frå den indre. Ein nest IPIP-pakke er berre nok ein IP-pakke sett frå WireGuard, og nettopp difor brukar han byte du aldri reserverte. Rettelsen er aritmetikk, og han passar i tre kommandoar og éin tabell.

Symptomet som avslører det

Fragmenteringsproblem kunngjer seg gjennom storleik, aldri gjennom adresser. Motparten din svarar på ein 56-byte ping i ein time og blir så stille ved 1400 byte medan tunnelen blir ståande og ingen rute er endra. Handtrykket passarar, det første fulle TCP-vindauget ikkje, og overføringa stoppar sekund etter at ho såg sunn ut.

Mål taket før du redigerer noko, for eit umålt tak er det du kjem til å jage to gonger. Send éin sonde under den mistenkte storleiken med do-not-fragment-biten sett, ping -M do -s 1000 10.9.0.2, og gjer ho så om att ved ein storleik du alt veit er for stor. Når vippet følgjer storleiken på nyttelasta medan destinasjonen blir uendra, gjer rutinga jobben sin, og det manglar éin header i budsjettet.

Tel kvar header éin gong, på rett lag

Start frå den minste MTU-en på vegen og ikkje frå tunnelgrensesnittet, fordi veggen sit oppstraums for båe endar. WireGuard brukar 60 byte på ytre IPv4-transport: 20 til IP, 8 til UDP og 32 til sin eigen header, og 80 byte når den transporten er IPv6. Ein 1420-byte wg0 held 20 byte med slakk under dei 1440 som ein 1500-byte veg verkeleg kan levere, og difor passar talet kopiert frå ein wiki framleis her. Teikn heile stakken på diagrammet, for den neste som endrar MTU-en vil elles velje eit nytt rundt tal og arve feilen din.

Den femte rada er der budsjetta går gale, fordi dei 1400 byta eit nest grensesnitt ber allereie inkluderer dei eigne 40 byta headere til den opphavlege pakken. Berre 1360 av desse byta når prosessen som les fila. Handsama 1400 som applikasjonsnyttelast, slik eitkvart diagram utan den kolonnen inviterer deg til, og den indre eininga endar 40 byte for gavmild mot ein vegg som ikkje har flytta seg.

Set dei to MTU-ane kvar for seg

Beraren og den nesta eininga er separate objekt, så kvar treng sin eigen verdi. Bruk dei i denne rekkjefølgja, fordi den nesta eininga arvar ingenting frå beraren:

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

Regelen som er verdt å hugse: indre MTU = ytre MTU - 20 når pakken IPIP-tunnelen ber er IPv4, og - 40 så snart ei av sidene i den indre pakken er IPv6, fordi den nesta headeren veks frå 20 byte til 40. Ingenting anna høyrer heime i den subtraksjonen. Overheaden til WireGuard vart alt brukt då du valde 1420, og å belaste han to gonger gjev ein tunnel som fungerer perfekt og blir verande treg så lenge ingen måler han. Ei utrulling der båe einingane ber ein rund 1400 er fingeravtrykket av nettopp den feilen.

IPv6 på kvar side av den nesta pakken gjer kvart tal ovanfor ugyldig, så rekn ut på nytt i staden for å kopiere eit tal frå ein liknande nettstad. Headerane som blir trekte frå er 40 byte kvar så snart IPv6 dukkar opp i den ytre vegen eller i det opphavlege datagrammet, og nyttelasttalet fell nøyaktig like mykje.

Brannmurregelen du sannsynlegvis ikkje treng

Mellom to WireGuard-peerar er det einaste på leiinga UDP, så ein innkomande regel for protokoll 4, nummeret RFC 2003 tildeler IPv4-i-IPv4-innkapsling, korkje skaper den nesta vegen eller held han i live. IPIP-headeren lever inne i den krypterte nyttelasta, der ingen kantbrannmur ser han. Å opne protokoll 4 likevel kjøper ingenting utover éin tillaten veg inn til verten.

Politikk som nemner kjeldene og destinasjonane til den opphavlege pakken høyrer heime etter avkapslinga, på tunnelgrensesnitta og i rutetabellen. Legg han der, og kantregelen kan halde fram med å vere lukka.

Kva WireGuard faktisk validerer

AllowedIPs dømmer kjelda til pakken WireGuard ber, og det han ber er den IPIP-innkapsla pakken. Ei tillaten IPIP-kjelde blir godteken sjølv når headeren inni nemner ein vert du helst ikkje vil rute til. Den opphavlege kjelda er difor ikkje det peer-en sjekka for deg, og det indre adresseparet treng si eiga handheving etter avkapslinga.

Innpakkinga gjev rutestruktur, ikkje eit andre kryptografilag. Å kalle IPIP ekstra vern inne i WireGuard skildrar eit anna design.

Verifiser med ein stige, ikkje éin ping

Prøv storleikar som omkransar grensa du rekna ut, og stadfest deretter kva kjernen meiner om båe einingane. Med 1360 byte nyttelast pluss 40 byte headere som gjev 1400, passar den første ekkoen nedanfor, og den andre sit éin byte forbi taket:

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

Ein rein passering under taket og ein feil ved den første storleiken over det betyr at aritmetikken held frå ende til ende. Køyr så overføringa som opphavleg stoppa på nytt, fordi ei syntetisk sonde beviser budsjettet og seier ingenting om skrivestorleikane til avsendararen sjølv. Viss den nesta vegen framleis bryt ved ein storleik du har bevist passar, undersøk avkapslinga og rutene til den fjerne enden før du skjer ti byte til av MTU-en.