IPsec-overhead: modus, NAT-T og algoritmer endrer det hele

Et eller annet sted i en veiledning står det et tall, vanligvis mellom seksti og åtti byte, som noen trakk fra 1500 for å få en grensesnitt-MTU. Det tallet beskriver én bestemt innkapsling på én bestemt vei. Endre modusen, den ytre adressefamilien, chifferet eller tilstedeværelsen av NAT, og regnestykket gjelder ikke lenger for tunnelen din.

Tallet kom fra en annen tunnel

Overhead er ikke en egenskap ved IPsec i det abstrakte. Det er en egenskap ved pakken som faktisk bygges: en forhandlet modus, et ytre hode, et beskyttelseshode, utfylling, et integritetsfelt og muligens en ekstra UDP-innpakning.

Et tall som siteres for transportmodus med IPv4 og uten NAT, beskriver en mindre pakke enn tunnelmodus med IPv6 under NAT-traversering. Begge er riktige for sitt eget tilfelle. Å kopiere ett av dem til en annen utrulling er måten folk ender opp med en MTU som ødelegger store overføringer. Feilen er stille, fordi små forespørsler fortsetter å virke.

Legg sammen lagene som faktisk er der

Start ved det ytre IP-hodet og arbeid innover. I tunnelmodus er den opprinnelige pakken inni, så det ytre hodet er et tillegg og ikke en erstatning. RFC 4303 beskriver ESP-hodet, utfyllingen og integritetsdataene som følger etter det.

Ingen av de radene er konstante på tvers av utrullinger, og utfyllingsraden er ikke engang konstant innenfor én utrulling. Det er hele grunnen til at ett publisert overheadtall skuffer.

To nettsteder kan være uenige om den samme tunnelen

Den beskyttede pakken må fortsatt krysse den ytre veien, og den ytre veien er ikke den samme overalt. En PPPoE-tilgangslinje bærer mindre enn et rent Ethernet-segment. Et mobilnett kan krympe ytterligere, og en leverandør som tunnelerer sin egen trafikk legger til en innkapsling som ingen nevnte. En tunnel som virker på én linje og feiler på en annen, beskriver den andre linjen, ikke protokollen.

Begge retningene kan også være forskjellige. En asymmetrisk rute kan gi deg en opplasting som virker og en nedlasting som stopper, noe som leses som et applikasjonsproblem til du ser på pakkestørrelser i stedet for på nåbarhet. En vellykket liten ping beviser svært lite om et svar i full størrelse.

Mål i stedet for å trekke fra

Finn det største datagrammet som overlever veien. Sammenlign det deretter med verdien grensesnittet rapporterer:

ip link show eth0 | grep -o 'mtu [0-9]*'
ip xfrm state list
ping -M do -s 1400 198.51.100.7
ping -M do -s 1372 198.51.100.7
tcpdump -ni any -c 20 'esp or udp port 4500'

Gå ned i ping-størrelse til svar ankommer, og behandle den største verdien som virker som budsjettet for den veien. xfrm-utskriften forteller deg hvilken modus og hvilke algoritmer som ble forhandlet, og det er inngangsverdien for enhver ærlig beregning. Opptaket bekrefter om det er ESP eller UDP-innkapslet ESP på ledningen, og det avgjør NAT-spørsmålet uten å gjette.

Sett av én verdi til kontrollplanet også. IKE-håndtrykkpakker har en annen struktur enn datapakker, så en størrelse utledet fra et håndtrykkopptak er ikke en dataplane-MTU.

Sett tallet der det hører hjemme

For TCP gjennom en tunnel er en MSS-klemme ofte den minst inngripende kontrollen, fordi den reduserer det endepunktene sender uten å endre selve tunnelen. For en rutebasert tunnel setter du MTU-en til tunnelgrensesnittet bevisst og dokumenterer hvorfor. Å gjøre begge deler samtidig og deretter måle gir deg ingen informasjon om hvilken som hjalp.

Hold den forhandlede modusen, den ytre familien, NAT-tilstanden og symptomet som kan gjenskapes sammen i saken. Et nedskrevet sett med fire fakta slår en husket konstant, og det er den eneste versjonen av dette som overlever neste klientoppgradering.