IPsec-overhead: tilstand, NAT-T og algoritmer ændrer det hele

Et eller andet sted i en guide står der et tal, som regel mellem tres og firs bytes, som nogen har trukket fra 1500 for at få en interface-MTU. Det tal beskriver én bestemt indkapsling på én bestemt vej. Ændr tilstanden, den ydre adressefamilie, krypteringsalgoritmen eller tilstedeværelsen af NAT, og regnestykket gælder ikke længere for din tunnel.

Tallet kom fra en anden tunnel

Overhead er ikke en egenskab ved IPsec i det abstrakte. Det er en egenskab ved den pakke, der faktisk bygges: en forhandlet tilstand, en ydre header, en beskyttelsesheader, padding, et integritetsfelt og muligvis en ekstra UDP-indpakning.

Et tal, der citeres for transporttilstand med IPv4 og uden NAT, beskriver en mindre pakke end tunneltilstand med IPv6 under NAT-traversering. Begge er korrekte for deres eget tilfælde. At kopiere en af dem til en anden udrulning er måden, hvorpå folk ender med en MTU, der ødelægger store overførsler. Fejlen er stille, fordi små anmodninger bliver ved med at virke.

Læg de lag sammen, der faktisk er der

Start ved den ydre IP-header og arbejd indad. I tunneltilstand er den oprindelige pakke indeni, så den ydre header er en tilføjelse og ikke en erstatning. RFC 4303 beskriver ESP-headeren, paddingen og de integritetsdata, der følger efter den.

Ingen af de rækker er konstante på tværs af udrulninger, og padding-rækken er ikke engang konstant inden for én udrulning. Det er hele grunden til, at et enkelt offentliggjort overheadtal skuffer.

To sites kan være uenige om den samme tunnel

Den beskyttede pakke skal stadig krydse den ydre vej, og den ydre vej er ikke den samme overalt. En PPPoE-adgangslinje bærer mindre end et rent Ethernet-segment. Et mobilnetværk kan krympe yderligere, og en udbyder, der tunnelerer sin egen trafik, tilføjer en indkapsling, som ingen nævnte. En tunnel, der virker på ét link og fejler på et andet, beskriver det andet link, ikke protokollen.

Begge retninger kan også være forskellige. En asymmetrisk rute kan give dig en fungerende upload og en fastlåst download, hvilket læses som et applikationsproblem, indtil du ser på pakkestørrelser i stedet for på nåbarhed. En lille ping, der lykkes, beviser meget lidt om et svar i fuld størrelse.

Mål i stedet for at trække fra

Find det største datagram, der overlever vejen. Sammenlign det derefter med den værdi, interfaceet 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, indtil svar ankommer, og behandl den største fungerende værdi som budgettet for den vej. xfrm-outputtet fortæller dig, hvilken tilstand og hvilke algoritmer der blev forhandlet, og det er inputtet til enhver ærlig beregning. Optagelsen bekræfter, om det er ESP eller UDP-indkapslet ESP, der er på ledningen, og det afgør NAT-spørgsmålet uden at gætte.

Afsæt også en værdi til kontrolplanet. IKE-håndtrykspakker har en anden struktur end datapakker, så en størrelse udledt af en håndtryksoptagelse er ikke en dataplane-MTU.

Sæt tallet, hvor det hører hjemme

For TCP gennem en tunnel er en MSS-clamp ofte den mindst indgribende kontrol, fordi den reducerer det, endepunkterne sender, uden at ændre selve tunnelen. For en rutebaseret tunnel skal du sætte tunnelinterfacets MTU bevidst og dokumentere hvorfor. At gøre begge dele på én gang og derefter måle giver dig ingen information om, hvilken der hjalp.

Hold den forhandlede tilstand, den ydre familie, NAT-tilstanden og symptomet, der kan genskabes, sammen i ticketen. Et registreret sæt af fire fakta slår en husket konstant, og det er den eneste version af dette, der overlever den næste klientopgradering.