IPsec-overhead: läge, NAT-T och algoritmer ändrar allt

Någonstans i en guide finns en siffra, oftast mellan sextio och åttio byte, som någon drog av från 1500 för att få en gränssnitts-MTU. Den siffran beskriver en specifik inkapsling på en specifik väg. Ändra läge, yttre adressfamilj, chiffer eller förekomsten av NAT, och räkneexemplet gäller inte längre för din tunnel.

Siffran kom från en annan tunnel

Overhead är inte en egenskap hos IPsec i abstrakt mening. Det är en egenskap hos paketet som faktiskt byggs: ett förhandlat läge, ett yttre huvud, ett skyddshuvud, utfyllnad, ett integritetsfält och möjligen ett extra UDP-hölje.

En siffra som anges för transportläge med IPv4 och utan NAT beskriver ett mindre paket än tunnelläge med IPv6 under NAT-traversering. Båda är korrekta för sitt eget fall. Att kopiera någon av dem till en annan utrullning är hur folk hamnar med en MTU som bryter stora överföringar. Felet är tyst, eftersom små förfrågningar fortsätter att fungera.

Summera lagren som faktiskt finns där

Börja vid det yttre IP-huvudet och arbeta inåt. I tunnelläge ligger det ursprungliga paketet inuti, så det yttre huvudet är ett tillägg och inte en ersättning. RFC 4303 beskriver ESP-huvudet, utfyllnaden och de integritetsdata som följer efter det.

Ingen av de raderna är konstant mellan utrullningar, och utfyllnadsraden är inte ens konstant inom en och samma utrullning. Det är hela anledningen till att en enda publicerad overheadsiffra gör en besviken.

Två platser kan vara oense om samma tunnel

Det skyddade paketet måste fortfarande korsa den yttre vägen, och den yttre vägen är inte densamma överallt. En PPPoE-anslutningslänk bär mindre än ett rent Ethernet-segment. Ett mobilnät kan krympa ytterligare, och en leverantör som tunnlar sin egen trafik lägger till en inkapsling som ingen nämnde. En tunnel som fungerar på en länk och misslyckas på en annan beskriver den andra länken, inte protokollet.

Båda riktningarna kan också skilja sig. En asymmetrisk väg kan ge dig en uppladdning som fungerar och en nedladdning som stannar, vilket läses som ett applikationsproblem tills du tittar på paketstorlekar i stället för på nåbarhet. En lyckad liten ping bevisar väldigt lite om ett svar i full storlek.

Mät i stället för att dra av

Hitta det största datagram som överlever vägen. Jämför det sedan med det värde som gränssnittet rapporterar:

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'

Sänk ping-storleken tills svar anländer, och behandla det största fungerande värdet som budgeten för den vägen. xfrm-utskriften berättar vilket läge och vilka algoritmer som förhandlades, och det är indata för varje ärlig beräkning. Avlyssningen bekräftar om det är ESP eller UDP-inkapslad ESP på tråden, och det avgör NAT-frågan utan gissningar.

Avsätt ett värde även för kontrollplanet. IKE-handskakningspaket har en annan struktur än datapaket, så en storlek som härletts från en handskakningsavlyssning är inte en dataplane-MTU.

Sätt siffran där den hör hemma

För TCP genom en tunnel är en MSS-klämma ofta den minst ingripande kontrollen, eftersom den minskar vad ändpunkterna skickar utan att ändra själva tunneln. För en ruttbaserad tunnel sätter du tunnelgränssnittets MTU medvetet och dokumenterar varför. Att göra båda samtidigt och sedan mäta ger dig ingen information om vilken som hjälpte.

Håll det förhandlade läget, den yttre familjen, NAT-tillståndet och symptomet som går att återskapa tillsammans i ärendet. En nedskriven uppsättning av fyra fakta slår en ihågkommen konstant, och det är den enda versionen av detta som överlever nästa klientuppdatering.