Descoberta de l'MTU del camí a través d'una VPN: dimensionament i el buit d'ICMP

Un túnel completa l'aplec de mans, les peticions petites tornen i la primera transferència gran s'encalla. Aquest patró apunta a l'MTU del camí molt abans que al rendiment. Cada enllaç de la ruta limita la mida del paquet, i l'encapsulament gasta part d'aquest marge en capçaleres externes, de manera que el paquet intern ha de ser més petit del que suggeriria el camí cru. La fallada és silenciosa, i això és el que la fa cara de diagnosticar.

Què mesura realment l'MTU del camí

L'MTU del camí és l'MTU d'enllaç més petit de la ruta entre dos hosts, no l'MTU imprès a la vostra interfície local. El valor local és on comença l'estimació, i el camí decideix on ha d'acabar. Per això un túnel idèntic pot funcionar en una xarxa d'accés i encallar-se en una altra: ha canviat la ruta, no la configuració. Mesurar un cop i suposar-ho a tot arreu és l'error que manté viu aquest problema.

Per a un túnel, el nombre que importa és l'MTU intern, és a dir, el marge del camí extern menys tot el que consumeix l'encapsulament. WireGuard afegeix una capçalera IP externa i una capçalera UDP; altres transports afegeixen les seves. Poseu la mida interna massa alta i cada paquet de mida completa necessitarà una fragmentació que potser no arribarà mai.

Per què un túnel redueix el paquet útil

Si la interfície del túnel conserva l'MTU de l'enllaç físic, cada paquet gran depèn que algú més avall estigui disposat a fragmentar-lo. IPv4 ho permet en principi, però un encaminador a qui s'ha dit que no fragmenti retorna un error. Els encaminadors IPv6 no fragmenten mai en trànsit, així que la mateixa configuració es comporta de manera diferent segons la família d'adreces. En tots dos casos l'emissor no aprèn res fins que alguna cosa li informa.

La conseqüència pràctica és una mida que encaixa amb l'aplec de mans i no amb la càrrega útil. Un TLS ClientHello o una consulta DNS són prou petits per travessar un camí reduït sense tocar, mentre que una transferència massiva no ho és. Per tant, els símptomes s'agrupen al voltant d'operacions concretes i no d'hosts concrets.

La descoberta només funciona quan arriba la retroalimentació

La descoberta IPv4 es basa en el bit de no fragmentar: un encaminador que no pot reenviar el paquet retorna ICMP fragmentation-needed amb l'MTU del següent salt, i l'emissor baixa la seva estimació. IPv6 fa servir missatges Packet Too Big, perquè els encaminadors no fragmenten en trànsit. Tots dos mecanismes assumeixen que el missatge troba el camí de tornada a l'emissor, a través del túnel i més enllà de qualsevol tallafoc del camí de retorn. Quan aquesta suposició falla, l'emissor continua reintentant una mida que el camí no pot portar.

Un tallafoc que permet echo request i echo reply no ha permès necessàriament aquests tipus d'error. ICMP és una família, i els membres que importen aquí són els errors, no la parella d'echo. Comproveu la política de trànsit de control als dos extrems del túnel i al camí entre ells, i seguiu les indicacions compatibles de la plataforma en lloc de permetre tots els tipus d'ICMP a tot arreu.

El mateix filtratge pot ser dins del túnel. Si el camí intern descarta l'error però el camí extern el transporta, l'emissor pot adaptar-se a un límit que el trànsit encapsulat no veu mai realment.

Proveu el camí en lloc d'endevinar un nombre

Mantingueu fixos la destinació, la xarxa d'accés i el túnel, i canvieu només la mida del paquet. Una sonda de no fragmentar que falla amb un indici d'MTU us dona el límit del següent salt; repetiu fins que passi una mida, i anoteu tant la mida com la família d'adreces.

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

Un ping que passa no demostra que els segments de mida completa d'una aplicació real passin, així que repetiu la prova amb la transferència que va fallar de debò. Compareu la sonda més gran que funciona amb l'MTU del túnel que heu configurat, i mantingueu els dos nombres separats a les notes. Si difereixen aproximadament pel que val una capçalera, heu trobat la sobrecàrrega de l'encapsulament, no un defecte.

PLPMTUD, descrit a l'RFC 4821, sondeja cap amunt i utilitza les confirmacions del transport en lloc de confiar en els errors lliurats. Ajuda en camins que filtren ICMP, però el suport varia segons la pila i l'aplicació. Un flux TCP pot recuperar-se sol mentre una aplicació UDP amb una mida de datagrama fixa continua fallant.

Trieu un valor i anoteu el raonament

Baixar l'MTU del túnel és alhora un diagnòstic i una correcció legítima un cop coneixeu el camí. No substitueix saber quin camí i quin mecanisme de retroalimentació hi van intervenir, perquè un valor ajustat per a un enllaç mòbil serà innecessàriament petit en una connexió de fibra. Anoteu la mida triada, la sonda que la justifica i el pas de reversió.

El mecanisme IPv4 es descriu a RFC 1191 i les indicacions d'empaquetament IPv6 a l'RFC 8201; nomenar tots dos evita que el següent enginyer hagi de tornar a deduir la suposició. Si la transferència encara s'encalla amb la mida que heu triat, deixeu de baixar el nombre i mireu la capa següent. Un camí que falla a qualsevol mida no és un problema d'MTU.