Mites sobre l'MTU de la VPN: per què s'encongueixen els paquets i on va l'espai

Algú us diu que la VPN "perd paquets per culpa de l'MTU", poseu el túnel a 1400 i la transferència torna a funcionar. Aquest resultat sembla un diagnòstic. Normalment és una coincidència aritmètica: heu triat un número prou petit per cabre sota un límit que mai no heu identificat, i tornareu a trobar el mateix límit a la propera xarxa amb un pressupost diferent.

Dos mites causen la major part d'això. El primer és que l'MTU de la interfície del túnel és l'MTU del camí. El segon és que l'encapsulació costa "una capçalera" i que el PPPoE no costa res que valgui la pena comptar. Tots dos són falsos de maneres que fan que el número que trieu sembli arbitrari quan en realitat està determinat.

Mite u: l'MTU del túnel és l'MTU del camí

El valor que poseu en una interfície de túnel és una promesa local sobre el paquet intern més gran que la implementació lliurarà cap avall. La capacitat real del camí és una propietat de cada enllaç entre vós i l'extrem remot, i pot canviar quan canvia una ruta, quan una connexió mòbil fa un handover o quan el trànsit agafa un altre peering. Un 1500 configurat us diu què construirà el vostre amfitrió, no què portarà la xarxa.

El descobriment de l'MTU del camí existeix per reconciliar els dos i depèn de la retroalimentació. Amb IPv4, un encaminador que no pot reenviar un paquet de mida completa ha d'enviar un missatge ICMP "fragmentation needed", i l'emissor baixa la seva estimació. Amb IPv6, l'equivalent és un missatge Packet Too Big i els encaminadors no fragmenten gens en trànsit. Quan aquesta retroalimentació es filtra, l'emissor continua produint paquets que el camí no pot portar, i res no li diu per què.

Mite dos: l'encapsulació costa una capçalera

Compteu les capes externes amb honestedat. Una capçalera IP externa fa 20 bytes amb IPv4 o 40 amb IPv6. L'encapsulació UDP per travessar el NAT n'afegeix 8. El protocol del túnel afegeix la seva pròpia capçalera, un vector d'inicialització o nonce, farciment fins al bloc o l'alineació del xifratge, un tràiler i un valor de verificació d'integritat. Segons el protocol i el xifratge, el total se situa còmodament en desenes de bytes abans que el paquet intern comenci.

Després resteu de nou les capçaleres del propi paquet intern. Un segment TCP dins del túnel porta la seva capçalera IP de 20 bytes i la seva capçalera TCP de 20 bytes, i l'MSS del TCP es deriva de l'MTU, no de la càrrega nominal del túnel. Per això ping amb una càrrega més petita pot reeixir mentre una transferència de fitxers s'atura: les eines proven coses diferents i només una exerceix un segment TCP de mida completa.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

La primera ordre informa de l'MTU configurat del túnel. Les dues proves envien una càrrega de 1472 bytes, que amb 28 bytes de capçaleres IPv4 i ICMP és un paquet de 1500 bytes, i després una de més petita. Si la prova gran falla del tot i la petita reïx, teniu una fallada dependent de la mida i no un problema general d'encaminament.

Mite tres: el PPPoE encara us dona 1500 nets

Un enllaç d'accés PPPoE convencional no porta un paquet IP de 1500 bytes. La capçalera PPPoE més el camp de protocol PPP ocupen 8 bytes dins de la trama Ethernet, cosa que deixa 1492 per al paquet IP. Aquest és el límit tradicional descrit a l'RFC 2516. Si feu córrer una VPN sobre aquest enllaç, la sobrecàrrega del túnel surt d'aquests 1492, no de 1500.

L'RFC 4638 defineix una manera de negociar una càrrega PPP més gran quan tant el concentrador d'accés com l'equip del client ho admeten, i per això "aquesta connexió fa servir PPPoE" tot sol no demostra cap número concret. Un paràmetre local no pot fer que un dispositiu intermedi accepti un paquet per al qual mai no s'ha configurat, així que la pregunta útil és què ha negociat realment l'enllaç, no què diu l'etiqueta.

Per què la fallada sembla selectiva

Que les peticions petites reïxin i les transferències grans s'aturin és la signatura clàssica d'un forat negre d'MTU del camí. L'apretada de mans, la consulta DNS i la crida a l'API hi caben; la transferència massiva produeix segments de mida completa que moren en un enllaç, i el missatge ICMP que hauria d'haver informat del problema no arriba mai. La connexió sembla bé i la baixada es penja, cosa que fa que la gent miri el servidor en lloc del camí.

Un segon error relacionat és confondre tres números: l'MTU de la interfície, l'MSS del TCP i el paràmetre de fragmentació o farciment del propi protocol. El pinçament d'MSS en un encaminador reescriu l'MSS anunciat perquè l'emissor construeixi segments més petits; no canvia l'MTU del túnel ni ajuda el trànsit UDP. Posar el mateix número als tres perquè semblen relacionats és com una configuració que funciona es trenca per un canvi ben intencionat.

Què canviar i en quin ordre

Comenceu amb proves. Confirmeu amb les proves anteriors que la fallada depèn de la mida i després trobeu la mida més petita que passa i la més gran que falla. Comproveu l'MTU real de l'enllaç d'accés abans de culpar el túnel; un enllaç PPPoE limita el pressupost abans que la VPN hi arribi. Anoteu els valors originals perquè el canvi es pugui desfer.

Apliqueu després l'ajust més petit que el client documenti. Molts clients exposen un MTU de túnel més una opció d'arranjament de l'MSS, i l'opció MSS sovint és la palanca millor per a TCP perquè arriba a l'emissor sense reduir tots els paquets. Torneu a provar la mateixa destinació i la mateixa transferència, i anoteu els números amb què us heu quedat. Un valor de túnel que funciona en una xarxa d'accés no és una constant universal, i el proper lloc tindrà el seu propi pressupost.