IPIP inne i WireGuard: de ekstra 20 bytene ingen hadde budsjettert med

Små ping går gjennom tunnelen hele dagen, SSH-banneret kommer, og så fryser sesjonen i det øyeblikket en filoverføring starter. Mønsteret peker på et bytebudsjett talt på feil lag, der den ytre tunnelen ble dimensjonert for sin egen overhead og ingen trakk fra den indre. En nestet IPIP-pakke er bare nok en IP-pakke sett fra WireGuard, og nettopp derfor bruker den byte du aldri reserverte. Rettelsen er aritmetikk, og den passer i tre kommandoer og én tabell.

Symptomet som avslører det

Fragmenteringsproblemer kunngjør seg gjennom størrelse, aldri gjennom adresser. Motparten din svarer på en 56-byte ping i en time og blir så stille ved 1400 byte mens tunnelen blir stående og ingen rute er endret. Håndtrykket passerer, det første fulle TCP-vinduet ikke, og overføringen stopper sekunder etter at den så sunn ut.

Mål taket før du redigerer noe, for et umålt tak er det du kommer til å jage to ganger. Send én sonde under den mistenkte størrelsen med do-not-fragment-biten satt, ping -M do -s 1000 10.9.0.2, og gjenta den så ved en størrelse du allerede vet er for stor. Når vippet følger nyttelastens størrelse mens destinasjonen forblir uendret, gjør rutingen jobben sin, og det mangler én header i budsjettet.

Tell hver header én gang, på riktig lag

Start fra den minste MTU-en på veien og ikke fra tunnelgrensesnittet, fordi veggen sitter oppstrøms for begge ender. WireGuard bruker 60 byte på ytre IPv4-transport: 20 til IP, 8 til UDP og 32 til sin egen header, og 80 byte når den transporten er IPv6. En 1420-byte wg0 holder 20 byte med slakk under de 1440 som en 1500-byte vei virkelig kan levere, og derfor passer tallet kopiert fra en wiki fortsatt her. Tegn hele stakken på diagrammet, for den neste som endrer MTU-en vil ellers velge et nytt rundt tall og arve feilen din.

Den femte raden er der budsjettene går galt, fordi de 1400 bytene et nestet grensesnitt bærer allerede inkluderer den opprinnelige pakkens egne 40 byte headere. Bare 1360 av disse bytene når prosessen som leser filen. Behandle 1400 som applikasjonsnyttelast, slik ethvert diagram uten den kolonnen inviterer deg til, og den indre enheten ender 40 byte for gavmild mot en vegg som ikke har flyttet seg.

Sett de to MTU-ene hver for seg

Bæreren og den nestede enheten er separate objekter, så hver trenger sin egen verdi. Bruk dem i denne rekkefølgen, fordi den nestede enheten ikke arver noe fra bæreren:

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 å huske: indre MTU = ytre MTU - 20 når pakken IPIP-tunnelen bærer er IPv4, og - 40 så snart en av sidene av den indre pakken er IPv6, fordi den nestede headeren vokser fra 20 byte til 40. Ingenting annet hører hjemme i den subtraksjonen. WireGuards overhead ble allerede brukt da du valgte 1420, og å belaste den to ganger gir en tunnel som fungerer perfekt og forblir treg så lenge ingen måler den. En utrulling der begge enhetene bærer en rund 1400 er fingeravtrykket av nettopp den feilen.

IPv6 på hver side av den nestede pakken ugyldiggjør hvert tall ovenfor, så regn ut på nytt i stedet for å kopiere et tall fra et lignende nettsted. Headerne som trekkes fra er 40 byte hver så snart IPv6 dukker opp i den ytre veien eller i det opprinnelige datagrammet, og nyttelasttallet faller nøyaktig like mye.

Brannmurregelen du sannsynligvis ikke trenger

Mellom to WireGuard-peers er det eneste på ledningen UDP, så en innkommende regel for protokoll 4, nummeret RFC 2003 tildeler IPv4-i-IPv4-innkapsling, verken skaper den nestede veien eller holder den i live. IPIP-headeren lever inne i den krypterte nyttelasten, der ingen kantbrannmur ser den. Å åpne protokoll 4 likevel kjøper ingenting utover én tillatt vei inn til verten.

Politikk som nevner kildene og destinasjonene til den opprinnelige pakken hører hjemme etter avkapslingen, på tunnelgrensesnittene og i rutetabellen. Legg den der, og kantregelen kan forbli lukket.

Hva WireGuard faktisk validerer

AllowedIPs bedømmer kilden til pakken WireGuard bærer, og det den bærer er den IPIP-innkapslede pakken. En tillatt IPIP-kilde godtas selv når headeren inni navngir en vert du helst ikke vil rute til. Den opprinnelige kilden er derfor ikke det peer-en sjekket for deg, og det indre adresseparet trenger sin egen håndhevelse etter avkapslingen.

Innpakningen gir rutestruktur, ikke et andre kryptografilag. Å kalle IPIP ekstra beskyttelse inne i WireGuard beskriver et annet design.

Verifiser med en stige, ikke én ping

Prøv størrelser som omkranser grensen du regnet ut, og bekreft deretter hva kjernen mener om begge enhetene. Med 1360 byte nyttelast pluss 40 byte headere som gir 1400, passer den første ekkoen nedenfor, og den andre sitter én 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

En ren passering under taket og en feil ved den første størrelsen over det betyr at aritmetikken holder fra ende til ende. Kjør så overføringen som opprinnelig stoppet på nytt, fordi en syntetisk sonde beviser budsjettet og ikke sier noe om avsenderens egne skrivestørrelser. Hvis den nestede veien fortsatt bryter ved en størrelse du har bevist passer, undersøk avkapslingen og rutene til den fjerne enden før du skjærer ti byte til av MTU-en.