IPsec-overhead: modus, NAT-T og algoritmar endrar det heile

Ein eller annan stad i ein rettleiar står det eit tal, vanlegvis mellom seksti og åtti byte, som nokon trekte frå 1500 for å få ein grensesnitt-MTU. Det talet skildrar éi bestemd innkapsling på éin bestemd veg. Endre modusen, den ytre adressefamilien, chifferet eller om NAT er til stades, og reknestykket gjeld ikkje lenger for tunnelen din.

Talet kom frå ein annan tunnel

Overhead er ikkje ein eigenskap ved IPsec i det abstrakte. Det er ein eigenskap ved pakken som faktisk blir bygd: ein forhandla modus, eit ytre hovud, eit vernande hovud, utfylling, eit integritetsfelt og moglegvis ei ekstra UDP-innpakning.

Eit tal som blir sitert for transportmodus med IPv4 og utan NAT, skildrar ein mindre pakke enn tunnelmodus med IPv6 under NAT-traversering. Begge er rette for sitt eige tilfelle. Å kopiere eitt av dei til ein annan utrulling er måten folk endar opp med ein MTU som øydelegg store overføringar. Feilen er stille, fordi små førespurnader held fram med å verke.

Legg saman laga som faktisk er der

Start ved det ytre IP-hovudet og arbeid innover. I tunnelmodus er den opphavlege pakken inni, så det ytre hovudet er eit tillegg og ikkje ei erstatning. RFC 4303 skildrar ESP-hovudet, utfyllinga og integritetsdataa som følgjer etter det.

Ingen av dei radene er konstante på tvers av utrullingar, og utfyllingsrada er ikkje ein gong konstant innanfor éin utrulling. Det er heile grunnen til at eitt publisert overheadtal skuffar.

To nettstader kan vere usamde om den same tunnelen

Den verna pakken må framleis krysse den ytre vegen, og den ytre vegen er ikkje den same overalt. Ei PPPoE-tilgangslinje ber mindre enn eit reint Ethernet-segment. Eit mobilnett kan krympe ytterlegare, og ein leverandør som tunnelerer sin eigen trafikk legg til ei innkapsling som ingen nemnde. Ein tunnel som verkar på éi linje og feilar på ei anna, skildrar den andre linja, ikkje protokollen.

Begge retningane kan òg vere ulike. Ei asymmetrisk rute kan gje deg ein opplasting som verkar og ein nedlasting som stoppar, noko som blir lese som eit applikasjonsproblem til du ser på pakkestorleikar i staden for på nåbarheit. Ein vellukka liten ping beviser svært lite om eit svar i full storleik.

Mål i staden for å trekkje frå

Finn det største datagrammet som overlever vegen. Samanlikn 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-storleik til svar kjem, og handsam den største verdien som verkar som budsjettet for den vegen. xfrm-utskrifta fortel deg kva modus og kva algoritmar som vart forhandla, og det er inngangsverdien for kvar ærleg berekning. Opptaket stadfestar om det er ESP eller UDP-innkapsla ESP på leidninga, og det avgjer NAT-spørsmålet utan å gjette.

Set av éin verdi til kontrollplanet òg. IKE-handtrykkpakkar har ein annan struktur enn datapakkar, så ein storleik utleidd frå eit handtrykkopptak er ikkje ein dataplane-MTU.

Set talet der det høyrer heime

For TCP gjennom ein tunnel er ei MSS-klemme ofte den minst inngripande kontrollen, fordi ho reduserer det endepunkta sender utan å endre sjølve tunnelen. For ein rutebasert tunnel set du MTU-en til tunnelgrensesnittet medvite og dokumenterer kvifor. Å gjere begge delar samtidig og deretter måle gjev deg ingen informasjon om kva som hjelpte.

Hald den forhandla modusen, den ytre familien, NAT-tilstanden og symptomet som kan attskapt saman i saka. Eit nedskrive sett med fire fakta slår ein hugsa konstant, og det er den einaste versjonen av dette som overlever neste klientoppgradering.