IPsec-overhead: modus, NAT-T en algoritmen veranderen het allemaal

Ergens in een gids staat een getal, meestal tussen zestig en tachtig bytes, dat iemand van 1500 heeft afgetrokken om een interface-MTU te krijgen. Dat getal beschrijft één specifieke inkapseling op één specifiek pad. Verander de modus, de buitenste adresfamilie, de versleuteling of de aanwezigheid van NAT, en de rekensom geldt niet meer voor jouw tunnel.

Het getal kwam uit een andere tunnel

Overhead is geen eigenschap van IPsec in het algemeen. Het is een eigenschap van het pakket dat echt wordt gebouwd: een onderhandelde modus, een buitenste header, een beschermingsheader, opvulling, een integriteitsveld en mogelijk een extra UDP-omhulsel.

Een getal dat wordt genoemd voor transportmodus met IPv4 en zonder NAT beschrijft een kleiner pakket dan tunnelmodus met IPv6 onder NAT-traversal. Beide zijn correct voor hun eigen geval. Eén ervan kopiëren naar een andere uitrol is hoe mensen uiteindelijk een MTU krijgen die grote overdrachten breekt. De fout is stil, omdat kleine verzoeken blijven werken.

Tel de lagen op die er echt zijn

Begin bij de buitenste IP-header en werk naar binnen. In tunnelmodus zit het oorspronkelijke pakket binnen, dus de buitenste header is een toevoeging en geen vervanging. RFC 4303 beschrijft de ESP-header, de opvulling en de integriteitsgegevens die erop volgen.

Geen van die rijen is constant tussen uitrollen, en de opvulrij is zelfs binnen één uitrol niet constant. Dat is de hele reden waarom één gepubliceerd overheadgetal teleurstelt.

Twee locaties kunnen het oneens zijn over dezelfde tunnel

Het beschermde pakket moet nog steeds het buitenste pad oversteken, en het buitenste pad is niet overal hetzelfde. Een PPPoE-toegangslink draagt minder dan een schoon Ethernet-segment. Een mobiel netwerk kan verder krimpen, en een provider die zijn eigen verkeer tunnelt, voegt nog een inkapseling toe die niemand noemde. Een tunnel die op de ene link werkt en op de andere faalt, beschrijft de tweede link, niet het protocol.

Beide richtingen kunnen ook verschillen. Een asymmetrische route kan je een werkende upload en een vastgelopen download geven, wat als een applicatieprobleem leest tot je naar pakketgroottes kijkt in plaats van naar bereikbaarheid. Een kleine ping die slaagt, bewijst heel weinig over een antwoord op volle grootte.

Meet in plaats van af te trekken

Zoek het grootste datagram dat het pad overleeft. Vergelijk het dan met de waarde die de interface rapporteert:

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'

Ga met de ping-grootte omlaag tot antwoorden aankomen, en behandel de grootste werkende waarde als het budget voor dat pad. De xfrm-uitvoer vertelt je welke modus en welke algoritmen zijn onderhandeld, en dat is de invoer voor elke eerlijke berekening. De opname bevestigt of er ESP of UDP-ingekapselde ESP op de draad zit, en dat beslecht de NAT-vraag zonder giswerk.

Houd ook één waarde vrij voor het controleplan. IKE-handshakepakketten hebben een andere structuur dan datapakketten, dus een grootte die uit een handshake-opname is afgeleid, is geen dataplane-MTU.

Zet het getal waar het hoort

Voor TCP door een tunnel is een MSS-clamp vaak de minst ingrijpende controle, omdat die vermindert wat de eindpunten sturen zonder de tunnel zelf te veranderen. Voor een routegebaseerde tunnel stel je de MTU van de tunnelinterface bewust in en documenteer je waarom. Beide tegelijk doen en dan meten zegt je niets over welke hielp.

Houd de onderhandelde modus, de buitenste familie, de NAT-toestand en het reproduceerbare symptoom samen in het ticket. Een vastgelegde set van vier feiten verslaat een onthouden constante, en het is de enige versie hiervan die de volgende clientupdate overleeft.